Формирование требований в проектировании¶
Формирование требований — это этап жизненного цикла системы, продукта или проекта, на котором выявляются, анализируются, документируются и согласовываются потребности заинтересованных сторон, подлежащие реализации. Результатом этапа становится формализованное описание того, что должна делать система и какими свойствами она должна обладать, — основа для проектирования, разработки, testing и приёмки.
Формирование требований относится к области системной и программной инженерии, управления проектами и промышленного проектирования. Оно предшествует созданию технического задания и служит исходной точкой для всех последующих работ.
¶Место в жизненном цикле
В классических моделях жизненного цикла (каскадной, V-модели) формирование требований — первый и наиболее критичный этап: ошибки, допущенные здесь, обходятся дороже всего при исправлении на поздних стадиях. В итеративных и гибких методологиях требования уточняются постепенно, однако начальная их формулировка (например, в виде списка пользовательских историй или бэклога продукта) сохраняет значение.
Этап включает несколько последовательных действий:
- сбор исходных потребностей;
- анализ и классификацию;
- документирование;
- согласование и утверждение;
- управление изменениями.
¶Виды требований
Требования принято разделять на несколько категорий.
| Категория | Содержание |
|---|---|
| Функциональные | Что система должна делать: функции, операции, реакции на входные воздействия |
| Нефункциональные | Как система должна это делать: производительность, надёжность, безопасность, удобство |
| Бизнес-требования | Цели и ожидания заказчика, критерии успеха |
| Пользовательские | Задачи, которые должен решать конечный пользователь |
| Системные | Требования к системе в целом и её подсистемам |
| Ограничения | Технологические, правовые, ресурсные, временные рамки |
Отдельно выделяют атрибуты требований: приоритет, источник, статус, критерии приёмки, версия.
¶Источники и методы сбора
Источниками требований выступают заказчик, конечные пользователи, нормативные документы, эксплуатирующий персонал, аналоги и конкуренты. Для их выявления применяются:
- интервью и опросы;
- анкетирование;
- наблюдение за работой пользователей;
- анализ существующих документов и процессов;
- мозговой штурм и фокус-группы;
- прототипирование;
- анализ сценариев использования (use cases).
В российской практике при создании автоматизированных систем требования к ним фиксируются в техническом задании, оформляемом с учётом государственных стандартов, в частности ГОСТ 34.602 и родственных документов серии 34 и 19.
¶Свойства качественных требований
Сформулированные требования оценивают по ряду критериев. Распространённый набор признаков качественного требования:
- полнота — отсутствие пропущенных потребностей;
- непротиворечивость — отсутствие взаимно исключающих положений;
- однозначность — единое толкование всеми сторонами;
- проверяемость — возможность подтвердить выполнение;
- трассируемость — прослеживаемость связи с источниками и результатами;
- атомарность — описание одного свойства или функции;
- осуществимость — техническая и экономическая реализуемость;
- приоритизированность — ранжирование по значимости.
Для проверки формулировок применяют критерии SMART и методики рецензирования.
¶Документирование и стандарты
Результаты этапа закрепляются в документах: спецификации требований, техническом задании, реестре требований, матрице трассируемости. В международной практике распространены стандарты IEEE 830 (рекомендуемая практика спецификации требований к программному обеспечению) и свод знаний по программной инженерии SWEBOK. В России действуют государственные стандарты Единой системы программной документации и Единой системы конструкторской документации, а также отраслевые нормативы.
¶Роли и участники
За формирование требований отвечает аналитик (бизнес-аналитик, системный аналитик) совместно с заказчиком, владельцем продукта, экспертами предметной области и будущими пользователями. Согласование требований предполагает участие представителей разработки, тестирования и сопровождения.
¶Управление изменениями
После утверждения требования помещаются под управление изменениями: любая корректировка проходит оценку влияния на сроки, стоимость и архитектуру, затем утверждается ответственными лицами. Для этого ведётся реестр изменений и поддерживается актуальность версий документов.
¶Типичные проблемы
К распространённым трудностям этапа относят:
- неполное или нечёткое изложение потребностей заказчиком;
- конфликт интересов разных групп пользователей;
- «ползучий» рост объёма требований;
- избыточную детализацию на ранних стадиях;
- отсутствие критериев приёмки;
- слабую трассируемость между требованиями и результатами.
¶Значение
Качество сформированных требований напрямую определяет трудоёмкость разработки, число переделок и итоговую удовлетворённость заказчика. Считается, что стоимость исправления ошибки возрастает на порядки по мере продвижения по стадиям жизненного цикла, поэтому этапу формирования требований уделяется повышенное внимание в методологиях управления проектами и стандартах инженерии.
Источники: ГОСТ 34.602, ГОСТ серии 19, IEEE 830, SWEBOK, материалы по бизнес-анализу и управлению требованиями.