Подход к сбору требований

Ниже приводится типичный сценарий сбора требований.

• Конечный пользователь обращается к руководителю.

• Руководитель обращается к представителю ИТ-подразделения.

• Представитель ИТ-подразделения обращается к менеджеру ИТ-подразделения.

• Менеджер ИТ-подразделения обращается к специалисту по планированию раз­вития продуктов.

• Специалист по планированию развития продуктов обращается к бригаде раз­работчиков.

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

Для сбора, структуризации, документирования и проверки обоснованности требо­ваний полезны такие методы, как JAR (Joint Application Requirements — совместная выработка требований) и JAD (Joint Application Development — совместная разработка приложений), средства поддержки принятия решений, фокус-группы, наблюдение, контекстные интервью, конкурентные оценки, анкетирование, анализ задач, преце­денты, сценарии, прототипирование, а также другие методы вовлечения пользовате­лей в разработку. При сборе требований следует учитывать процессы и потребности, связанные с существующими и будущими пользователями, ведением бизнеса и заказ­чиками. Деятельность по управлению изменениями должна быть направлена на про­гнозирование потребностей, обусловленных изменениями среды деятельности поль­зователей в будущем.

Полезное правило. Аналогично другим проблемным областям, связанным с созданием продукта, требования подчиняются правилу "80/20" в отношении зна­чимости и полноты. 20% требований определяют наиболее существенные черты системы и ее ПИ, они наиболее критичны для проектирования и разработки. Остальные 80% требований важны, но не столь существенны с точки зрения базо­вых потребностей бизнеса или разработки.

Наиболее важные аспекты задачи — систематизированный подход к сбору требо­ваний, согласование с реальными будущими пользователями ПО, взаимодействие с Деловыми спонсорами и согласие по требованиям. Результатом подобных усилий яв­ляется набор требований, который соответствует потребностям пользователей, спон­соров и разработчиков.

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

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

Полезное правило. Таблицы требований необходимы на всем протяжении ЖЦ проекта, поскольку к ним можно добавить столбцы для определения возмож­ностей, которые уже наглядно представлены в ПИ, а также отображения результа­тов тестирования требований.

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

Полезное правило. Помните о правиле "80/20" на этапе одобрения требований.

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

и, так и пользователей.

Отслеживание изменений. Это та область, в которой ориентированная на пользователей бригады разработчиков продукта, работая в тесном взаимодействии с организациями-заказчиками и организациями разработчиками, помогает поддерживать доверие, необходимое в современной быстро изменяющейся бизнес–среде и среде разработки. После того как базисный набор требований определен, управление изменениями становится насущным вопросом.

Полезное правило. При отслеживании изменений в требованиях необходима большая дисциплинированность, чем при первоначальной фиксации требований.

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

• Изменения в требованиях к продукту, выгоды, потенциальные потери oi неосуществления изменений и деловые риски.

• Потенциальные влияния изменений на стоимость проекта, план-графвд; ресурсы и риски.

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