Уровни и типы требований
Коротко Требования складываются в слои: зачем организации нужен продукт, что пользователи должны уметь с ним делать и как должна вести себя система. Если держать слои раздельно, видно, куда относится каждое утверждение, кто его утверждает и чего не хватает.
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 1; модель «область проблемы — область решения» Э. Халла, К. Джексона и Дж. Дика в изложении курса И. Корнипаева «Управление требованиями».
На этой странице
Главные идеи#
Что считать требованием#
Вигерс и Битти отталкиваются от определения Соммервилла и Сойера: требование задаёт поведение, свойство или атрибут, которым должна обладать система, и может также ограничивать то, как её создают. Утверждение остаётся требованием, даже если у него низкий приоритет или его реализацию отложили. Не спорьте, «настоящее» ли это требование: запишите его и назначьте приоритет.
Три уровня требований к продукту#
| Уровень | На какой вопрос отвечает | Типичная форма | Где их хранят Вигерс и Битти |
|---|---|---|---|
| Бизнес-требования | Зачем это нужно организации? | Бизнес-цели, показатели успеха | Документ концепции и границ |
| Пользовательские требования | Что должны уметь делать пользователи? | Варианты использования, пользовательские истории, таблицы «событие — реакция» | Документ пользовательских требований |
| Функциональные требования | Как должна вести себя система в заданных условиях? | Утверждения вида «Система должна…» | Спецификация требований к ПО (SRS) |
Рядом с уровнями существуют ещё три вида информации:
- Нефункциональные требования — атрибуты качества (доступность, удобство использования и т. д.), ограничения дизайна и требования к внешним интерфейсам. Они встречаются на всех уровнях.
- Бизнес-правила — политики, нормативные требования и расчёты. Строго говоря, это не требования к ПО, но они служат их важным источником.
- Системные требования — требования верхнего уровня к продукту из нескольких подсистем, часто к сочетанию оборудования и ПО. Пример из книги — кассовое рабочее место в супермаркете с несколькими подключёнными устройствами.
Функция (feature) — группа связанных функциональных требований, которая даёт пользователям что-то ценное, например автосохранение. Дерево функций раскладывает функцию на подфункции, и каждая из них связана с конкретными пользовательскими и функциональными требованиями.
Требования к продукту и требования к проекту#
В SRS попадают только требования к продукту. То, что нужно проекту, — ресурсы команды, обучение персонала, пользовательская документация, миграция данных, сертификация, лицензирование, соглашения об уровне обслуживания — уходит в план управления проектом, за который бизнес-аналитик и руководитель проекта отвечают вместе. Если утверждение описывает, что должен сделать проект, а не что должен делать продукт, уберите его из SRS.
Разработка и управление#
Вигерс и Битти делят разработку требований на выявление (elicitation), анализ, спецификацию и валидацию. Эти действия повторяют, с каждым проходом всё подробнее, а не выполняют один раз по порядку. Управление требованиями начинается, когда согласована базовая версия (baseline): версии, влияние изменений, статусы и связи. В каскадных проектах эту работу делают в основном в начале, в итеративных — понемногу в каждой итерации, а в гибких каждую историю уточняют непосредственно перед реализацией.
Сначала использование, потом функции#
Авторы советуют подход, ориентированный на использование: сначала понять бизнес-цели и задачи пользователей, затем вывести из них функции. Подход, ориентированный на продукт, начинается с привлекательного списка функций, и при нём легко создать функции, которыми в итоге никто не пользуется.
Второй взгляд: область проблемы и область решения#
Халл, Джексон и Дик в изложении курса Корнипаева описывают три похожих слоя: требования заинтересованных сторон формулируют проблему и не называют решений; системные требования абстрактно говорят, как система удовлетворит эти потребности; системные спецификации описывают архитектуру. Вывод тот же, что у Вигерса и Битти: не смешивайте цели с решениями. В Руководстве BABOK® есть похожее деление на бизнес-требования, требования заинтересованных сторон, требования к решению и переходные требования.
Как применять#
- Помечайте каждое собранное утверждение его уровнем: бизнес-требование, пользовательское, функциональное, нефункциональное, бизнес-правило или требование к проекту.
- Трассируйте каждое функциональное требование вверх к пользовательскому, а каждое пользовательское — к бизнес-цели. То, что ни к чему не трассируется, либо лишнее, либо указывает на пропущенную цель.
- Переносите требования к проекту в план проекта.
- Ведите бизнес-правила отдельным списком и ссылайтесь на них, а не копируйте.
Пример#
Для «Мастерской», вымышленной сети из 12 веломастерских:
| Вид | Утверждение |
|---|---|
| Бизнес-требование | В течение года после запуска сократить на 30% число звонков на стойки приёма о записи и статусе ремонта. |
| Пользовательское требование | Клиент может онлайн записаться на ремонт в выбранную мастерскую. |
| Функциональное требование | Система должна показывать свободное время для ремонта в выбранной мастерской на ближайшие 14 дней. |
| Нефункциональное требование | Страница записи должна быть доступна в течение всех объявленных часов работы. |
| Бизнес-правило | Запись можно бесплатно отменить не позднее чем за 24 часа до её начала. |
| Требование к проекту (не входит в SRS) | Обучить сотрудников стойки приёма во всех 12 мастерских до запуска. |
Подводные камни#
Вигерс и Битти называют шесть тревожных признаков проблем с требованиями:
- Недостаточное участие пользователей. Аналитик описывает идеальный процесс, а не реальный. В книге описан налоговый отдел, о существовании которого команда несколько месяцев не знала.
- Небрежное планирование. Грубую прикидку воспринимают как обязательство.
- Разрастание требований. Пропускайте каждый новый запрос через фильтр бизнес-целей, границ и критериев успеха и закладывайте в план резервы. В гибкой работе эту роль выполняет бэклог.
- Неоднозначность. Каждому читателю его собственное прочтение кажется разумным, поэтому дружеская вычитка её не замечает. Используйте формальные ревью, тест-кейсы или прототипы.
- «Позолота». Разработчики добавляют функции, которых никто не просил. Трассируйте каждую функцию к источнику.
- Упущенные классы пользователей. Учитывайте косвенных пользователей и скрытые заинтересованные стороны: регуляторов, сотрудников поддержки, специалистов по миграции данных.
Авторы ссылаются на исследования, по которым примерно 40–50% дефектов ПО вызваны ошибками в требованиях (Дэвис), и доказывают, что работа с требованиями — это вложение, а не задержка.
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 1.
- И. Корнипаев. Управление требованиями: слайды курса. Изложение модели Халла, Джексона и Дика.
- E. Hull, K. Jackson, J. Dick. Requirements Engineering.
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0.