День 1942. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 10. Требования должны быть достаточно хорошими, чтобы разработка могла продолжаться с приемлемым уровнем риска
Невозможно создать идеальный набор требований. Некоторые требования могут быть неполными, неправильными, ненужными, невыполнимыми, двусмысленными или вообще отсутствовать. Иногда они противоречат друг другу. Но в любом случае ПО должно создаваться на основе требований.

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

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

Понятие «достаточно хорошие» включает как количество представленной информации, так и её качество. Цель спецификации требований - определить желаемое поведение системы достаточно подробно, чтобы разработчики системы, маркетологи, клиенты, пользователи и руководство интерпретировали его более или менее одинаково.

Полноту требований можно представить в трех измерениях:
1. Типы информации
Простого набора функциональных требований или пользовательских историй недостаточно. Разработчики должны знать об источниках данных, ограничениях, бизнес-правилах, требованиях к качеству и внешнему интерфейсу.

2. Широта знаний
Объём информации, содержащейся в спецификации. В неё входят все требования пользователей или только высокоприоритетные? Учитываются все атрибуты качества или только первостепенные? Очевидно ли читателю требований, что перед ним полные или не полные требования? Если набор требований неполный, то все ли читатели увидят одни и те же пробелы? Если подразумеваемые и предполагаемые требования нигде не фиксируются, то высока вероятность, что они останутся незамеченными.

3. Глубина детализации
Учитывают ли требования возможные исключения (ошибки) и определяют ли, как система должна их обрабатывать? Если спецификация определяет нефункциональное требование, например установку, охватывает ли она также удаление, повторную установку, восстановление и установку обновлений и исправлений? Любые требования, и функциональные, и нефункциональные, должны быть достаточно полными и точными, чтобы их можно было проверить в реализованном решении.

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

Многие команды Agile-разработки ПО не оформляют все детали требований в письменном виде, но это не значит, что эти детали не нужны разработчикам и тестировщикам. Если письменная информация недоступна во время реализации, то должна быть возможность получить её из нужного источника. В противном случае члены команды должны будут сами восполнять пробелы, что может быть отмечено заказчиком как недостаток. А это будет означать, что требования не полностью готовы для реализации.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.