Требования, какие и зачем

Какие бывают требования?

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

По ходу статьи я буду давать свои комментарии под такими сносками

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

Функциональные требования в свою очередь подразделяются на:

• Бизнес-требования;
• Пользовательские требования;
• Непосредственно, сами функциональные требования;
• Системные требования;

Нефункциональные требования подразделяются на:

• Бизнес-правила;
• Ограничения;
• Атрибуты качества;
• Требования к визуализации (если есть UI).

Вот вам для наглядности классическая картинка Вигерса:

Остановимся на каждом типе требований подробнее.

Функциональные требования

Как понятно из названия это требования непосредственно к функциональности системы (сервиса, приложения), которую от нее ожидают.

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

Бизнес-требования, как правило, фиксируются в концепте (concept) или уставе проекта (project charter), иногда еще в так называемом в документе рыночных требований (market requirements document). В общем в любом верхнеуровневом документе, который описывает образ и границы системы.

Если требования собираются для модуля существующей системы или небольшого приложения, т.е. без выделения отдельного проекта, то бизнес-требования фиксируются в отдельном разделе SRS (Software Requirement Specification). Обычно достаточно указать бизнес-цель создания системы, и то каким образом планируется что она будет достигнута.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. Простым языком я бы называл это "хотелки" пользователей. В отдельный документ такие требования конечно не выносятся, а просто фиксируются в виде "Пользовательских Историй" (User Story) в тасктрекерах.

В мире Scrum беклог вашего проекта как раз наполняется подобными User Stories, при этом я всегда рекомендую аналитика подниматься от этих требований вверх, чтобы точно понимать какую цель преследует та или иная хотелка.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, что-бы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда их именуют "требованиями поведения" (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Функциональные требования фиксируются в отдельном документе который и будет основным документом используемым командой в процессе разработки и тестирования, обычно его называют SRS (Software Requirement Specification).

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

Системные требования - это требования которые предъявляют вашей системе системы с которыми запланирована интеграция.

Обычно системные требования фиксируются: в контрактах заключаемых между системами, или в заголовочных файлах (хэдерах).

Я не рекомендую описывать системные требования в SRS, т.к. SRS это все же внутренний документ, которым будут пользоваться только ваши разработчики, в то время как контракт или хэдер - общие документы, и им пользуются обе стороны взаимодействия, потому в SRS вставляем только ссылку на контракт/хэдер, а все описание взаимодействия оставляем там.

Разобрались с функциональными, перейдем к НФТ.

Нефункциональные требования (НФТ)

Про эти требования все постоянно забывают, ввиду нехватки времени и кажущейся неважности этих самых НФТ. Но тем не менее, знать и помнить про них надо обязательно.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес правила обычно фиксируются в SRS, в разделе ограничений.

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

Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Атрибуты качества обычно фиксируются в соответствующем разделе srs.

Иногда атрибуты качества называют "критерии успеха" - имея ввиду что по этим критериям пользователи будут оценивать будут оценивать качество вашей системы. Желательно выявить их на этапе сбора требований, и зафиксировать в user story и srs. Т.о. вы не забудете предусмотреть реализацию мониторинга за этими показателями.

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

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

Я рекомендую оформлять проволочные диаграммы отдельно от SRS, так вам и пользователям будет их проще согласовывать.

На сегодня, всё, увидимся в следующей статье!