С отдалением России от западного мира возникла необходимость переосмыслить, что есть ТРЕБОВАНИЕ?

Очевидный смысл требования заключается во фразе "хочу, чтобы так было". То есть это о намерениях, осознанных и не очень.

Давайте рассмотрим такую шкалу:

• Мечта - хочу чтобы так было, но не имею средств или сил на реализацию. Бездействую.
• Желание (хотелка) - хочу чтобы так было, кто и как это сделает пока не знаю, не имею понятия о нужных средствах для реализации. Рассуждаю.
• Пожелание - хочу, чтобы так было, но не уверен, что это возможно, и не уверен, что готов за это заплатить. Рассуждаю, коммуницирую. 
• Потребность - осознаю, что это нужно, готов выделить на это средства и действовать. Коммуницирую, убеждаю, изыскиваю ресурсы.
• Требование - осознаю, что это нужно, имею средства на реализацию, осознаю необходимость и могу ее объяснить. Коммуницирую, торгуюсь.
• Требование-самодурство - хочу, чтобы так было, имею полномочия заставить кого-то реализовать. Слабо осознаю необходимость, объяснить не могу.
• Принуждение - осознаю, что это нужно, имею полномочия заставить кого-то реализовать. Осознаю необходимость, имею средства, приказываю.

Сведем это в таблицу для большей ясности.

Итак, за словом "требование" может скрываться разная степень осознанности и детальности. Но никто не будет подбирать правильное слово, большинство из нас фразу на тему "хочу, чтобы было так" назовет именно "требованием". И поэтому возникают сложности с тем, что поступает на вход в проектирование.

Наиболее часто встречаются два вида ТЗ:

1. ТЗ, выставленные на конкурс. Обычно в них отражены потребности, то есть степерь детальности их средненькая.
2. ТЗ, сформулированные для закупки чего-то конкретного. Обычно в них включают именно требования, так как предмет закупки уже точно известен.

Таким образом, требование - это предикт или основание для действия или побуждение к действию, причем побуждение исходит от одного лица (лиц), а действовать или воплощать требование будет другое лицо (лица).

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

• бизнес-требование - требование, происходящее от бизнеса, от понимания бизнесом своих задач или функций. Например, для увеличения объема продаж в 2 раза, нам нужна CRM-система, способная вести учет клиентов (существующих и потенциальных) и сделок по клиентам, включая все стадии сделки.
• пользовательское требование - требование, исходящие от пользователя системы. Например, сотрудник отдела продаж должен регистрировать сделки по клиентам и их статусы в CRM-системе, используя возможности мобильного приложения.
• системное требование - требование к программной системе. Например, в CRM-системе должен быть объект "клиент", экранная форма которого должна быть адапатирована под мобильный телефон на ОС "Андроид" и содержать такие поля, как ФИО, контакты,  ИНН, предпочтительный канал обращения. Каждое поле должно подвергаться форматному контролю со стороны приложения.

Посмотрим на сравнительную таблицу. Далее под проектируемой системой, к которой выдвигаются требования, мы будет понимать программу для ЭВМ (программный продукт). Поэтому будем стараться использовать слово "программа" вместо слово "система". Читатель должен отнестись к этим словам, как к синонинам.

Важно отличать бизнес-требования от пользовательских и системных. В общем случае они всегда существуют раздельно и в отношении многие-ко-многим. То есть не бывает системного требования без бизнес-требования или пользовательского.  Бизнес-требование имеет целью прояснить потребность бизнеса (что именно хочется достичь и зачем). Системное требование имеет целью прояснить, что нужно изменить или создать в системе. Зачастую сложно отделить бизнес-требование от пользовательского или системного. Мы же все торопимся... Поэтому в ТЗ включают микс формулировок из нечетких потребностей и весьма детальных указаний на тему, как должна работать будущая программа.

В любом случае после того, как ТЗ утверждено и подписано, начинается уточнение или даже формирование именно системных (программных) требований. И здесь системное (программное) требование  трансформируется. Системное (программное) требование порождает формулировку будущей функции (функций) программы. Функций программы прежде всего! Функция программы - это то, что будет делать программа и как пользователь с этой функцией программы будет взаимодействовать.  Не стоит путать функции программы (CRUD) с бизнес-функциями, выполнение которых опирается на программные функции.

Дальнейшая работа с требованиями к программным функциям невозможна без формулировки самих программных функций! Контейнером для таких функций являются фичи (features). Помещение функций в контейнеры может показаться излишним методологическим шагом, но это необходимо, так как не все, что мы разрабатываем, есть именно функции. Фичу можно трактовать как дельту той полезности, которую мы проектируем и отгружаем. Это может быть все, что угодно: от полноценной функции системы до изменение цвета и расположения кнопок на экране. Касательно фич см. источники 3 и 4. А вот что такое "функция"... - едва ли 1 из 10 человек может объяснить - смотрим здесь: источник 6. 

Разработка программы (да и вообще любое проектирование) - это понижение уровня абстракции от требований до строчек программного кода. То есть требование - это всегда абстрация будущего кода. Поэтому следует держать в голове два полезных определения² :

• Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically to retain only information that is relevant for a particular purpose. It is an act of Representing essential features without including the background details or explanations.
• Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function (то есть системного требования, примечание В.Рудь) in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts.

Далее мы будет разбираться, как происходит этот refinement. Частью этого процесса является "спецификация требований"⁵. Здесь следует обратить внимание на это устойчивое сочетание двух слов "спецификация требований". На мой взгляд это есть большое заблуждение. Специфируем мы не требования. Специфицируем мы именно фичи! Провокация: получив на вход "требование", забудьте о нем! - проектируйте фичу, которая будет реализовывать это требование (а может быть и несколько требований, а чаще всего - фрагменты из нескольких требований). Как минимум это стоит сделать по той причине, что качество поступивших на вход требований всегда низкое!

Существует два вида специфицирования:

1. контекстное (это для архитекторов).
2. сущностное или алгоритмическое (для программистов).

Продолжение следует...

При цитировании данной статьи ссылка на статью - обязательна. Давайте повышать культуру совместного производства знаний.

Полезные ссылки:

1. что есть спецификация? - The word specification is broadly defined as "to state explicitly or in detail". Спека is often used to guide fabrication/production.
2. см здесь design concepts  
3. Software feature
4. Feature-oriented programming
5. Правила составления Software requirements specification
6. Что есть функция? - кому некогда читать, возьмите мое синтетическое определение: “функция есть некое соответствие между тем, что поступило нам на вход, с тем что мы получили на выходе, причем безразлично каким образом установлено это соответствие - аналитической формулой, графиком, таблицей либо даже просто словами. В программировании функция реализуется алгоритмом. Поэтому очевидно, что не всякая фича есть функция.

Итоговая схема по статье: