Даже если вы провели внушительную работу по сбору требований для своего проекта, автоматизированная поддержка поможет вам оперировать с этими требованиями в процессе разработки. Инструментальное средство управления требованиями становится все полезнее со временем, когда детали требований постепенно тускнеют в памяти членов команды. В следующих разделах описаны некоторые задачи, которые подобное средство поможет вам решать.
Управление версиями и изменениями. Вашпроект должен определять основную версию требований — четкий набор требований для конкретной версии. Некоторые средства управления требованиями предлагают функции гибкого управления базовой версией. Они также сохраняют историю изменений каждого требования. Вы можете записывать обоснование каждого решения об изменении и при необходимости возвратиться к предыдущей версии требования. Некоторые средства, такие как Active! Focus и DOORS, содержат простые, встроенные системы изменений-предложений, устанавливающие связи между предложениями об изменениях и измененными требованиями.
Хранение атрибутов требований. Вы должны записывать несколько описательных атрибутов для каждого требования, как говорилось в главе 18. Каждый, кто работает над проектом, должен иметь доступ к просмотру этих атрибутов, а некоторые — к изменению их значений. Инструментальное средство управления требованиями генерирует несколько системных атрибутов, например дату создания требования и номер его версии, а также, позволяет вам создавать дополнительные атрибуты различных типов данных. Продуманное определение атрибутов позволяет всем заинтересованным в проекте лицам просматривать подмножества требований, основанных на выбранных комбинациях значений атрибутов. Вы можете запросить список всех требований, основанных на каком-либо бизнес-правиле, чтобы принять решение о последствиях изменения этого правила. Один из способов учета требований в основных версиях различных выпусков продукта — использовать атрибут «номер выпуска».
|
|
Облегчение анализа воздействия. Средства управления требованиями помогают осуществлять трассирование требований, позволяя вам определять связи между различными типами требований, между требованиями в различных подсистемах и между отдельными требованиями и связанными системными компонентами (например, проектным решением, модулями кода, тестами и пользовательской документацией). Эти связи помогут вам анализировать воздействие, которое предлагаемое изменение окажет на конкретное требование, выявляя другие элементы системы, которые оно затронет. Другой полезный способ — отследить каждое функциональное требование назад до первоисточника, чтобы знать, откуда оно берет начало.
| Дополнительная информация В главе 19 описан анализ воздействия, а в главе: 20 — трассирование требований. |
Трассирование статусов требований. Собрав требования в базе данных, вы узнаете, сколько отдельных требований вы указали для продукта. Трассирование статуса каждого требования в процессе разработки способствует общему трассированию статуса проекта. Meнеджер проекта точно представляет себе статус проекта, если знает, что 55% требований для следующего выпуска проверены, 28% — реализованы, но не проверены, а 17% еще не до конца реализованы.
|
|
Контролируемый доступ. Средства управления требованиями позволяют вам устанавливать права доступа для отдельных людей и групп пользователей и предоставлять информацию в общий доступ географически распределенной команде через Web-интерфейс к базе данных. Базы данных используют блокировку на уровне требований, позволяя сразу многим пользователям обновлять содержимое базы данных одновременно.
Связь со всеми заинтересованными в проекте лицами. Некоторые средства управления требованиями позволяют членам команды обсуждать вопросы, связанные с требованиями, на тематических дискуссиях с помощью электронных средств обмена сообщениями. Автоматически отсылаемые электронные сообщения уведомляют членов команды, когда в дискуссии появляется новая запись или любое требование модифицируется. Возможность работы с требованиями через Интернет сокращает расходы на транспорт и уменьшает документооборот.
Повторное использование требований. Хранение требований в базе данных облегчает их повторное использование в других проектах и подпроектах. Требования, логически подходящие нескольким разделам описания проекта, можно сохранить однажды, а затем лишь ссылаться на них во избежание дублирования требований.