Как сделать требования измеримыми и наглядными

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

Наглядные Требования. Функциональные требования легко представить в различном виде, удобном для их отслеживания. Чтобы перечислить функциональные требования, достаточно простой электронной таблицы плана проекта. Дополнитель­ные столбцы электронной таблицы используются для отображения факта выполне­ния определенных требований на конкретную версию программного продукта или дату реализации требования.

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

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

Публикация требований. Требования должны быть всегда доступны всем заинтересованным в проекте сторонам. Доступность принимает форму печатной или электронной документации, прототипов и раскадровки требований, а также презен­таций. Обычно используется несколько типов коммуникации.

Полезное правило. Для управления изменениями следует предоставлять ин­ формацию, связанную с отслеживанием требований, по всем аспектам требований.

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

Полезное правило. При установлении приоритетов полезен следующий при­ем: попробуйте задаться вопросом: "Если я могу сделать только что-нибудь одно, то что именно?" Цель состоит в том, чтобы определить, какие возможности можно отложить или вообще не реализовывать. "Будет ли нанесен ущерб проекту, если я не сделаю этого?"

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

Полезное правило. После того как одобрены требования или взяты обязатель­ства, какие-либо увертки недопустимы.

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

Продолжение обсуждения проекта:

формулирование требований

Ваше совещание с высшим руководством по пересмотру обобщенного плана прошло чрезвычайно удачно. План был одобрен, вы получили несколько заданий: обеспечить оценку количества окон, Web-страниц и экранов; представить приближенную оценку количества часов, требуемых для разработки окна, Web-страницы и экрана объяснить, на какие компромиссы придется пойти в связи с применением объектно–ориентированного подхода и методов наподобие языка UML. Отсчет проектного времени начался.

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

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

План-график также очень напряжен. Контакты с потенциальными покупателями ПО показали, что несколько клиентов могли бы использовать продукт уже через де­вять месяцев начиная с сегодняшнего дня.

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

Лидер проекта пришел к вам с такими заданиями.

1. Подготовить короткое информационное совещание для высшего руководства по следующим вопросам: каким образом собрать, зафиксировать в документа­ции и утвердить проектные требования, назначить им приоритеты, составить календарный план их реализации и включить его в рабочий план проекта. Как обычно, совещание должно состояться завтра утром и на подготовку у вас око­ло 30 минут. Менеджер проекта подчеркнул важность план-графика и обосно­ванность предложений.

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

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

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

5. подготовить ответы на задания, данные высшим руководством для подготовки этой информации в вашем распоряжении имеется два часа.

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

Вопросы?

Ссылки

Schneider G., and Winters J. Applying Use Cases: A practical Guide, Addison – Wesley: New

York, 2001.

Torres R.J. User Interface Design and Development, Westlake reflections, Apr.1992.

Wiegers K. Software Requirements, Microsoft Press; Redmond, WA,1999.