Без заголовка

Никакой неопределённости IMHO нет, мы на практике применяем следующие модальности: - по умолчанию - система должна удовлетворять требование; - как только требование реализовано и проверено в определённом релизе, и об этом есть запись - определённый релиз системы удовлетворяет требование; - реже - для системы допустимо иметь ограничение. Причём даже если требования пишем в утвердительной форме Use Case или User Story - все договорились, что это "система должна", просто повторять в каждом пункте "система должна" никому не нужно. Точно так же, если требование выражается в форме моделей UML, mindmap, макета GUI - всё равно "система должна". "Спецификация требований" - IMHO оксюморон. Бизнес-требования описывают существенные потребности пользователей и других ЗЛ, системные требования описывают существенные предположения о свойствах и функциональности будущей системы. Абсолютно всех свойств и функций системы, и даже (!) проблем и потребностей пользователя заранее описать нельзя, по крайней мере, до того, как система будет готова. Да и не нужно, как бы ни хотели этого тестировщики. Потому что разработка ПО - это не дословный перевод с одного языка на другой, а перевод творческий, с доработкой, а то и с написанием своего собственного рассказа "по мотивам". И это нормально: нужно дать возможность думать и творить каждому. Если же кто-то хочет абсолютной определённости сразу - значит, боится, хочет прикрыть бумагой 5-ю точку, или даже устраивает итальянскую забастовку. В некоторых случаях это оправданно (медицина, вооружение, опасные производства), но чаще нет, и является совсем другой проблемой. Тем более, что всё описывать - очень долго и дорого, требования успевают устареть (опять же, где-то, наверное, не успевают, а у нас успевают). По крайней мере, это моё мнение и наш подход. Точно так же никакой проблемы с применением стандартов нет - по форме требования должны соответствовать принципу разумного минимализма, KISS и гибкости - как удобно конкретным читателям, так и опишем. А по принципам ведения - нужно, чтобы у каждого требования был источник, автор, статус, релиз, история и источники изменений. Концепция продукта - не более 30 страниц, раздел требований - не более 3, общий объём требований на проект - не более 300 страниц, если непременно нужно больше - нужно разбивать на подпроекты. Кроме того, мы выработали для себя некоторые семантические каркасы, планы того, что нужно не забыть описать, ну или понимать, почему не описываем: - для нефункциональных требований URPS+; - для функциональных: -- настройка (локальная, централизованная); -- работа (по событиям, по задачам); -- отчётность.