Каждый аналитик в своей работе сталкивается с ситуацией, когда нужно принять решение о том, что сбор требований по задаче (проекту) завершен и можно переходить к следующему этапу работы - документированию в соответствии с принятыми в компании (или команде) стандартами и передаче в дизайн и разработку.
Здесь есть закономерный вопрос - какие триггеры вам подскажут, что требования иссякли, по крайней мере на текущем этапе их сбора?
Для ответа на данный вопрос, нужно в первую очередь определиться с однозначным пониманием того, что мы понимаем под "завершением сбора требований". Очевидно, что это некоторый экспертный критерий того, что собранные требований достаточны для начала проектирования дизайна решений и разработки и их возможные изменения (дополнения) не окажут значительного влияния на решение.
Важно помнить тот факт, что этап сбора требований выполняется по разному в зависимости от используемой методологии разработки ПО:
- Waterfall: этап сбора требований имеет определенные регламентированные границы и после требования не изменяются (по крайней мере не сильно 🙂)
- V-образная модель: аналогично Waterfall с дополнением, что выполняется их тестирование для снижения рисков. Те сбор требований может быть расширен в случае выявления дефектов в них;
- Итерационная, инкрементная модель: сбор требований повторяется на каждой итерации для каждого инкремента продукта;
- Спиральная модель: аналогично итерационной и инкрементной модели, ибо это их частный случай;
- Гибкая (agile) модель: работа с требованиями ведется постоянно;
Из сказанного следует, что сбор требований в некоторых случаях может выполнять постоянно и это нормально, а в некоторых должна быть поставлена точка, чтобы перейти к следующих шагам.
Аналитику для понимания того, что требования от заказчика больше не поступают, предлагается ориентироваться на список признаков, описанный в книге Карла Вигерса и Джой Битти "Разработка требований к программному обеспечению":
- пользователи уже не могут придумать каких-либо еще вариантов использования или пользовательских историй. Обычно они описывают их в порядке убывания значимости последних;
- пользователи предлагают новые варианты использования, однако они не приводят к появлению новых функциональных требований. Эти «новые» предложения могут оказаться случаями других вариантов использования, которые вы уже рассмотрели;
- пользователи повторно описывают уже обсуждавшиеся проблемы;
- предлагаемые новые функции, пользовательские или функциональные требования выходят за рамки проекта;
- вновь предлагаемые требования имеют низкий приоритет;
- пользователи предлагают возможности, которые можно реализовать «когда-то позже», а не включить «в конкретный продукт, который мы сейчас обсуждаем»;
- разработчики и тестировщики, проверяющие требования, задают очень мало вопросов.
Кроме явно заявленных пользователями требований, в проекте могут быть еще и упущенных требования, подробно о причинах их появления и способах выявления можно почитать в статье "Работаем с упущенными требованиями".
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse