Процесс создания требований

Не ждите, что все действия по выявлению, анализу, спецификации и проверке требований удастся выполнить последовательно и за один проход. На практике эти действия выполняются попеременно, поэтапно и повторяются (рис. 3-1). Работая с клиентами в качестве аналитика, вы будете задавать вопросы, выслушивать ответы и наблюдать за действиями клиентов (выявление требований). Далее вы обработаете полученную информацию, классифицируете по различным категориям и соотнесете потребности клиентов с возможными требованиями к ПО (анализ). Затем вы оформите информацию от клиентов и выработанные требования в виде письменных документов и диаграмм (спецификация), предложите представителям пользователей подтвердить, что написанный вами текст точен и полон, и попросите их исправить возможные ошибки (проверка). Этот итерационный процесс и есть процедура создания требований.

Рис. 3-1. Итеративный процесс формулирования требований

Из-за разнообразия проектов по разработке ПО и организационных культур единого, шаблонного подхода к созданию требований не существует. На рис. 3-2 показана схема создания требований, которая с разумными исправлениями подойдет для большинства проектов. Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным. Первые семь действий обычно однократно выполняются на ранних стадиях работы нал проектом (тем не менее, команде разработчиков придется периодически изменять приоритеты). Остальные необходимы для каждого очередного выпуска или этапа работы над проектом.

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

Рис. 3-2. Поэтапный процесс создания требований