Определение образа и границ проекта

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

К заинтересованным в проекте лицам относятся:

1) заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес-задач;

2) пользователи, которые взаимодействуют напрямую или не напрямую с приложением (подкласс заказчиков);

3) аналитики требований, которые пишут требования и передают их разработчикам;

4) разработчики, которые создают, разворачивают и поддерживают продукт;

5) тестеры, которые определяют соответствие поведения ПО желаемому;

6) технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;

7) менеджер по проекту, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта;

8) сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям;

9) производственники, которые должны построить продукт, содержащий данное ПО;

10) сотрудники отдела продаж и маркетинга, выездной службы поддержки и другие, кому придется работать с продуктом и его пользователями.

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

Но разработка требований и управление ими — трудный процесс!

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

В этой книге описаны дюжины таких приемов. Их рекламируют для построения абсолютно новых систем, однако они отлично подходят для поддержки проектов и выбора коммерческих готовых решений (см. главу 16). Не используйте эти приемы только для модели водопада BB.

Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document).

Создание такого документа описано в главе 5. Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью

системы. Пример варианта использования — Сделать заказ для заказа билетов на самолет, аренды автомобиля, заказа гостиницы через Интернет.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Как вы увидите в главе 9, бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил. Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Я буду относиться к спецификации, как к документу, хотя это может быть база данных или крупноформатная таблица с требованиями, хранилище данных в коммерческом инструменте управления требованиями (см. главу 21) или даже, может быть, куча карточек для небольшого проекта. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях.

В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества.

Каких требований не должно быть

Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании (Letting well и Widrig, 2000). Удалите указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду.