Выявление требований

Выявление требований по существу является базовым процессом разработки требований. На Рис. 4‑1 представлена детальная модель процесса выявления требований.

В общем виде процесс выявления требований распадается на процесс планирования конкретных мероприятий по выявлению требований, собственно процессы выявления различных видов требований и процесс формулирования выявленных требований в виде проекта требований.

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

Рис. 4‑1. Модель выявления требований

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

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

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

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