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

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

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

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

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

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

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

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

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

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

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

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

Примечание 2: в каждой формулировке может быть пересечение точек зрения, вносящее дополнительный сумбур в ходе проектирования.

Примечание 3: системное требование может полноценно возникнуть только тогда, когда у вас уже есть модель (образ, проект) или прототип будущей системы. Или система уже существует, но вам нужно ее доработать.

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

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

Так как рассмотренные три типа требований связаны друг с другом причинно-следственными связями, то зачастую сложно отделить бизнес-требование от пользовательского или системного. Очень часто даже в одной формулировке с требованием могут быть замешаны все три аспекта: бизнесовый, пользовательский, системный. Мы же все торопимся... Поэтому в ТЗ включают все подряд или, иными словами, микс формулировок из [нечетких] потребностей и весьма детальных указаний на тему, как должна работать будущая программа.  Чтобы справиться с этой путанницей, аналитики классифицируют требования на верхнеуровневые и детальные, где верхнее - это то, что ближе к бизнесу, а детальное - то, что ближе к системе.

Однако умение видеть в миксе требований то, что относится к бизнесу вообще или к пользователю в частности, весьма ценно, так как позволяет в дальнейшем скорректировать системные требования не нарушая цели/ограничения бизнеса и пользователей. По этой причине требования лучше сортировать на три группы. 

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

Замечание. А что такое "функция"?... - едва ли 1 из 10 человек может объяснить - смотрим здесь: источник 6.

Дальнейшая работа с требованиями к программным функциям невозможна без формулировки самих программных функций! Первоначальным контейером (яичной скорлупой) для таких функций являются фичи (features). Помещение функций в контейнеры может показаться излишним методологическим шагом, но это необходимо, так как не все, что мы разрабатываем, есть именно функции. Фичу можно трактовать как дельту той полезности, которую мы проектируем, пестуем, растим и отгружаем. Это может быть все, что угодно: от полноценной функции системы до изменение цвета и расположения кнопок на экране. Таким образом, бизнес- и пользовательские требования свободятся к набору проектируемых фич, вместе образующих модель будущей системы, и контуры этих фич должны быть описаны как раз в виде системных требований. Почему так? - чтобы заручиться поддержкой заказчика, который системные требования должен утвердить. В западной практике проектирования набор проектируемых фич описывается в виде HLD.

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

• 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. Частью этого процесса является "спецификация требований"⁵ и software design. Здесь следует обратить внимание на это устойчивое сочетание двух слов "спецификация требований". На мой взгляд это есть большое заблуждение. Специфицируем мы не требования. Специфицируем мы именно фичи! Провокация: получив на вход "требование", забудьте о нем! - проектируйте фичу, которая будет реализовывать это требование (а может быть и несколько требований, а чаще всего - фрагменты из нескольких требований). Как минимум это стоит сделать по той причине, что качество поступивших на вход требований всегда низкое!

Справедливости ради, следует отменить, что существует три вида специфицирования:

1. контекстное (это для архитекторов) специфицирование требований. На эту тему читаем по ссылке >>>
2. спецификация требований - в сущности детальные пояснения касательно того, как бизнес или пользователь видит удовлетворение своей потребности >>>.
3. сущностное или алгоритмическое специфировование фичи или всей совокупности фич - это уже работа конструкторов ПО (software design).

По пунктам 2 и 3 можно почитать SWEBOK (доступна v 2.4, смотри главы Requirements Specification и Software Design) или Виггерса. Отдельно я бы еще отметил, что установление взаимосвязей между требованиями [через функции и объекты данных] есть не менее важный аспект их специфицирования, чем попытка детализировать лишь каждое требование в отдельности. 

Сущностая спецификация - это уже дизайн ПО. Системное требование, которое явно указывает или предопределяет функцию системы или данные, которые функция получает/выдает, переживает еще одну магию: рождаются решения по структурам данных и алгоритмам системы, которые должны удовлетворять:

• конкретным системных требованиям
• произвольной группе или всем системным требованиям сразу
• общесистемным требованиям, таким как безопасность, надежность и т.п.

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

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

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. Что есть функция? - кому некогда читать, возьмите мое синтетическое определение: “функция есть некое соответствие между тем, что поступило нам на вход, с тем что мы получили на выходе, причем безразлично каким образом установлено это соответствие - аналитической формулой, графиком, таблицей либо даже просто словами. Поэтому очевидно, что не всякая фича есть функция. В программировании функция реализуется алгоритмом.
7. См. определение функции у Декарта.

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

Магия проектирования на примере сырников

Историческая справка:

Изначально создание какого-либо здания или изделия проходило несколько другие стадии:

1. Предпроектные изыскания. Целью таких изысканий являлось попытка обосновать, что будем создавать, зачем будем создавать, с какими характеристиками и т.п. На выходе этой стадии были потребности, так как говорить о требованиях здесь еще весьма рано. Потребности включали в ТЗ. Но это было задание на проектирование (!!!), а не задание на создание конечного изделия или здания. Поэтому уместно заключить, что на выходе были [не совсем четкие] потребности и это было естественно и нормально.

2. Проектирование. На этой стадии создавался проект, как совокупность решений, чертежей, смет. К проектированию привекались конструкторы, за создание проекта отвечал архитектор или главный инженер проекта.  Результатом проекирования был набор документации (проект или тех.проект), по которой можно было бы создавать изделие или строить здание. В общем случае проектная документация все еще допускает вариативность, как минимум по трем причинам:

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

Если перекладывать это на сферу создания программного обеспечения, то [детальные] системные требования должны возникать именно здесь, так как именно на этой стадии возникает технический образ программы: структуры данных и алгоритмы. На этом заканчивается собственно проектирование и только в этот момент можно сказать, что именно мы создаем и сколько оно будет стоить (смета). То есть, обращаю внимание, что в ТЗ на проектирование никак невозможно определить сколько же будет стоить конечное изделие и потому ТЗ - это документ-основание лишь для стадии проектирования. 

3. Собственно конструирование или создание изделия или строительство дома. 

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

Примечание к стадии 1 и 2. Со временем между стадиями 1 и 2 добавили концептуальное проектирование, а отечественные ГОСТы ключили его в состав стадии 1.  Благое намерение, если бы только кто-то в самом деле занимался проектированием на стадии 1. Зачастую слово "концепция" воспринимается неоднозначно, так как занимаются ею те же люди, которые формулируют потребности. К сожалению эти люди не являются проектировщиками по образованию. Кстати, слово "концепция" отсутствует в английском языке.

Следует также заметить, что все это не строгая наука, а некие методические подходы, вымученные практикой. Все это менялось на протяжении десятилетий: стадии то сливались, то разделялись, например возникал техно-рабочий проект. Всё это еще будет меняться. Однако же в ГОСТах это всё строго, потому как по ним нормируют и контролируют труд проектировщиков, ибо он весьма и весьма дорогой, да еще и непредсказуемый в силу самой природы движения от абстрактного к конкретному.