Исследование

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

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

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

Документальный способ хранения требований имеет массу ограничений, в том числе:

• трудность обновления и синхронизации документов;

• всем членам команды, которым это необходимо, передачу изменений приходится осуществлять вручную;

• трудность хранения дополнительной информации (атрибутов) для каждого требования;

• трудность определения взаимосвязей между функциональными требованиями и другими элементами системы;

• трассирование статуса требований представляет собой трудный и неудобный процесс;

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

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

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

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

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

В табл. 4.1 перечислено несколько доступных в настоящее время инструментальных средств управления требованиями.

Таблица 4.1 –

Некоторые коммерческие инструментальные средства управления требованиями

Инструмент	Производитель	Способ хранения данных
Active! Focus	XapwareTechnologies	База данных
CaliberRM	Borland Software Corporation	База данных
C.A.R.E	SOPHIST Group Telelogic	База данных
DOORS	Rational Software Corporation	База данных
RequisitePro	RBC	Документ
RMTrak	Inc.	Документ
RTM Workshop	Integrated Chipware	База данных
Slate	Inc.EDS	База данных
Vital Link	ComplianceAutomat	Документ

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

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

При документальном подходе документ, созданный при помощи текстового процессора (такого, как Microsoft Word или Adobe FrameMaker), считается основным хранилищем требований. RequisitePro позволяет вам выбирать текстовые строки в документе Word для сохранения их в виде отдельных требований в базе данных. После ввода требований в базу данных вы можете определить атрибуты и связи трассирования так же, как и в продуктах, данные которых хранятся в БД — механизмы синхронизации базы данных и содержимого документа для этого предусмотрены. RTM Workshop поддерживает обе схемы: в первую очередь хранение данных в базе данных, но также и в документе Microsoft Word.