На рис. 3-2 показана схема создания требований, которая с разумными исправлениями подойдет для большинства проектов. Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным. Первые семь действий обычно однократно выполняются на ранних стадиях работы над проектом (тем не менее команде разработчиков придется периодически изменять приоритеты). Остальные необходимы для каждого очередного выпуска или этапа работы над проектом.
Оценив доступные вам способы общения с представителями пользователей, выберите подходящие приемы выявления требований (круглые столы, исследования, опросы и т.д.) и спланируйте время и ресурсы, необходимые для сбора информации (этап 5 на рис. 3-2). Многие системы создаются поэтапно, и поэтому любой команде, работающей над проектом, необходимо определить приоритеты вариантов использования и других пользовательских требований (этап 7). Расставив приоритеты, вы решите, на каком этапе следует реализовать те или иные варианты использования. В случае новых систем ИЛУ значительных усовершенствований можно на этапе 14 определить или уточнить архитектуру, а на этапе 15 распределить функциональные требования по конкретным подсистемам. Этапы 12 и 17 — это операции по контролю качества, в результате которых вам, возможно, придется вернуться, чтобы исправить ошибки, улучшить модели анализа или выявить упущенные ранее требования. Прототипы, создаваемые на этапе 13, зачастую выявляют необходимость усовершенствовать и модифицировать определенные ранее требования. Завершив для какой-либо части требований этап 17, можно приступать к реализации соответствующей части системы. Повторите этапы 8—17 для следующих наборов вариантов использования, которые могут войти в более позднюю версию продукта.
