Нет смысла

Ок, ты прав

Когда нет требований, нет и понятия корректности. В такой ситуации все приплясывания вокруг верификации будут культом карго, не более

Мне недавно подумалось, что желание троллить проходит с возрастом – по-видимому, я был неправ. 🙂

В пост-эпоху желание троллить неотличимо от желания общаться

обычно же верифицируют дизайн, который пишут по тем же требованиям, по которым в иных местах пишут тест кейсы и сценарии.. но сейчас кажется, что я что-то не понимаю

А вы по-прежнему требования понимаете, как некий документ из процесса RUP, с печатями, с подписями?

Требования есть всегда, но не всегда они обдуманы, приведены в непротиворечивый вид, и оформлены. Тесты помогают, в том числе, прояснить требования

ну я помню как в энтерпрайзе фазу анализа закрывали документом под названием Функциональные требования, факт подписи этого документа переводил проект в фазу дизайна, одна компания другой переводила транш, проект двигался дальше

Александр всё прекрасно понимает, но для остальных напишу.
С дной стороны, да, абсолютно, 100% – без требований о корректности говорить невозможно.
Но с другой стороны, есть разные уровни требований и корректности. Как правило, отсутствие креший подразумевается, и в требованиях вообще явно не фигурирует. И типы и прочие методы статического анализа как минимум помогают гарантировать корректность на уровне отсутствия креший и прочих явных ляпов. Системы эффектов позволяют убрать ещё некоторое количество менее явных ляпов.

А можно не абстрактную теорию обсуждать, а практику?
Я хочу в clojure/script сделать что-то вроде интерпретатора эффектов.
Т.е. разделить логику от интерпретации эффектов.
Если кому haskell ближе, то это free monad.
Если кому ближе js, то это генераторы.



У меня есть вопросы и рассуждения, они вот тут.
https://gist.github.com/darkleaf/f0cbfe38eaad82cb44758aef1228287f

Собственно там первая ссылка на уже существующую мою библиотеку
и там есть rationale https://github.com/darkleaf/effect/blob/doc-2/README.md#rationale

Так вот, требования и документ с требованиями - вещи разные. Документ - это артефакт, а требования - это явление, свойство, если хотите

без артифакта нельзя считать требования требованиями

О фри монадах я всегда рад пообщаиься! Только кложи не знаю

Артефакты - дело наживное. Требования могут быть даже устными

Это договоренности, по сути

"Обычно" не верифицируют ничего. 😄
Особо упоротые верифицируют код.
Верифицировать дизайн – вообще плохо определённая задача...

Может я когда-нибудь куплю книжку. Но пока я не пишу на haskell, а надергать идей пока так получается.

могу лично тебе объяснить мои вопросы голосом, врядли тебе тут понадобится какое-то знание кложи

устные договоренности, не фиксированные - это простор для трактовок и причина всех девиаций.

как вы вообще что-то делаете, не фиксируя требования на бумаге/в документе?