Определение требований в проектировании¶
Определение требований — это этап жизненного цикла системы или проекта, на котором выявляются, анализируются, документируются и согласовываются потребности заинтересованных сторон, которым должен удовлетворять создаваемый продукт, услуга или процесс. Результатом этапа становится формализованное описание того, что система должна делать и каким условиям соответствовать, — основа для проектирования, разработки, testing и приёмки. В инженерии программного обеспечения и системной инженерии этот этап считается одним из наиболее критичных: ошибки, допущенные при определении требований, обходятся тем дороже, чем позже они обнаруживаются.
¶Место в жизненном цикле
Определение требований открывает процесс создания системы и предшествует проектированию (design) и реализации. В классических моделях, таких как каскадная (waterfall), этап выполняется однократно и завершается утверждением документа требований. В итеративных и гибких методологиях (Agile, Scrum) работа с требованиями ведётся непрерывно: они уточняются и пересматриваются в каждом цикле. Независимо от модели, этап включает сбор, анализ, спецификацию, проверку и управление изменениями требований.
¶Виды требований
Требования принято разделять на несколько категорий.
- Функциональные — описывают, какие функции должна выполнять система: например, «система должна позволять пользователю восстановить пароль по электронной почте».
- Нефункциональные — задают качественные ограничения: производительность, надёжность, безопасность, удобство использования, совместимость. Их также называют атрибутами качества.
- Бизнес-требования — формулируют цели организации: зачем создаётся продукт, какие выгоды ожидаются.
- Пользовательские требования — описывают задачи, которые должны решаться с точки зрения конечного пользователя.
- Системные требования — детализируют, как система реализует пользовательские и бизнес-требования на техническом уровне.
Дополнительно выделяют ограничения (constraints) — заранее заданные условия, которые нельзя нарушить: законодательные нормы, стандарты, используемые технологии, бюджет и сроки.
¶Источники и методы сбора
Источниками требований выступают заказчики, конечные пользователи, эксперты предметной области, нормативные документы, аналогичные системы и техническая документация. Для их выявления применяются:
- интервью и опросы;
- анкетирование и фокус-группы;
- наблюдение за работой пользователей;
- анализ существующих документов и бизнес-процессов;
- мозговой штурм и рабочие семинары;
- прототипирование и макетирование;
- анализ конкурентных решений.
На практике методы комбинируют, поскольку каждый из них даёт неполную картину.
¶Свойства качественных требований
Сформулированные требования оценивают по набору критериев. Распространённый перечень включает следующие свойства:
| Свойство | Содержание |
|---|---|
| Полнота | требование охватывает все необходимые условия |
| Непротиворечивость | требования не конфликтуют между собой |
| Однозначность | допускается только одно толкование |
| Проверяемость | можно объективно установить факт выполнения |
| Атомарность | требование описывает одну функцию или условие |
| Трассируемость | прослеживается связь с источником и реализацией |
| Приоритетность | указана важность относительно других требований |
Для проверки однозначности и полноты применяются формальные и полуформальные методы: модели вариантов использования (use case), пользовательские истории (user story), диаграммы, спецификации в виде шаблонов.
¶Документирование и управление
Результаты этапа фиксируются в документе, который в разных традициях называют техническим заданием, спецификацией требований (Software Requirements Specification, SRS) или бэклогом продукта. Документ содержит описание системы, функциональные и нефункциональные требования, ограничения, критерии приёмки и глоссарий.
Поскольку требования меняются в ходе проекта, применяется управление требованиями: ведение их версий, оценка влияния изменений, согласование с заинтересованными сторонами, поддержание трассируемости. В России требования к ряду систем закрепляются государственными стандартами, в частности серией ГОСТ 34 и ГОСТ 19, регулирующими создание автоматизированных систем и программной документации.
¶Типичные проблемы
К распространённым трудностям этапа относят:
- неполное или неверное понимание потребностей заказчика;
- противоречия между требованиями разных групп пользователей;
- «ползучее» расширение объёма (scope creep) — бесконтрольное добавление новых требований;
- избыточную детализацию на ранних стадиях, ограничивающую проектные решения;
- отсутствие измеримых критериев, из-за чего требование невозможно проверить.
Стоимость исправления ошибки растёт по мере продвижения по жизненному циклу, поэтому качеству определения требований уделяется особое внимание.
¶Значение
Определение требований связывает потребности заказчика с технической реализацией и служит основой для планирования, оценки трудозатрат, проектирования, тестирования и приёмки. Корректно выполненный этап снижает риски переделок, сокращает сроки и стоимость разработки, повышает вероятность того, что созданная система будет востребована. В системной и программной инженерии дисциплина работы с требованиями выделена в отдельную область знания — инженерию требований (requirements engineering).
Источники: ГОСТ 34.601-90, ГОСТ 19.201-78, IEEE Std 830, К. Вигерс «Разработка требований к программному обеспечению», материалы по системной и программной инженерии.