Применение Borland CaliberRM для управления требованиями.

Первичный сбор требований

Первичный сбор требований

Процесс первичного сбора требований (gathering) является первым шагом в процессе создания требований. Сбор требований следует начинать с бизнес требований, так как все остальные виды требований подчинены им.
Основной задачей этапа сбора бизнес требований является выработка образа продукта (product vision). Образ продукта описывает, что сейчас представляет собой продукт и каким он станет впоследствии. Границы проекта (project scope) показывают, к какой области долгосрочного образа продукта направлен текущий проект. Образ продукта подразумевает определение долгосрочных перспектив развития проекта, в то время как границы проекта могут быть определены для конкретной итерации. Следует очень внимательно отнестись к формированию образа и границ проекта. Это позволит избежать или, по крайней мере, запланировать на более позднее время реализацию менее критичных для успеха проекта возможностей ПО (наверно вам знакомы ситуации когда войдя во вкус клиент просит сделать еще и вот это и это, при этом не выделяя дополнительных ресурсов). Формирование образа и границ проекта позволяет руководству понять, за что именно они будут платить деньги, а разработчикам понять чего хочет от них руководство. В прилагаемых к статье материалах мы привели шаблон документа об образе и границах проекта, взятый с сайта Карла Вигерса .
Следующим этапом является сбор пользовательских требований, другими словами вам необходимо выяснить чего ожидают от вас непосредственные пользователи. Естественно, что пользовательские требования должны быть жестко подчинены бизнес требованиям.
Практически любая информационная система имеет несколько категорий пользователей. Очень важно проанализировать потребности каждой из таких групп, достигнув компромисса между противоречащими требованиями различных групп пользователей. Необходимо четко определить приоритетность каждой группы и при разрешении противоречий между требованиями в первую очередь заботится об удовлетворении наиболее приоритетных групп.
Наиболее удачным подходом является оформление пользовательских требований в виде вариантов использования.
Собранные требования оформляются в виде спецификации требований (System Requirement Specification - SRS).
Основными ошибками, допускаемыми этапе первичного сбора требований, являются:.
• Нечеткое определение границ проекта, что приводит к затягиванию сроков проекта, перерасходу бюджета за счет включения в продукт второстепенных возможностей.
• Недостаточно четко определенные группы пользователей продукта.
• В каждой группе не выделены представители, наиболее заинтересованные в продукте, готовые продуктивно сотрудничать с командой разработчиков.
• Попытка с первого раза максимально детализировать и проанализировать все требования.
Чтобы не допустить этих ошибок можно дать несколько рекомендаций:.
• Разделите пользователей продукта на категории в соответствии с их ролями.
• В каждой группе выберите одного - двух человек в качестве представителей интересов группы. Выбранные люди должны быть лидерами (пусть даже и неформальными) в своей группе, четко представлять бизнес процессы, в которых участвует группа и лояльно настроенных по отношению к проекту создания и внедрения разрабатываемой системы.
• Не пытайтесь сразу и досконально описать все требования. Это приведет лишь к затягиванию работ. Требования должны прорабатываться и детализироваться в ходе проекта.
• Каждому требованию присваивайте приоритетность. Это позволит реализовывать в первую очередь самые необходимые требования, откладывая реализацию второстепенных возможностей на более поздний срок. Как правило, достаточно ввести три - четыре градации приоритетности требований.