Успешный опыт разработки показывает, что эффективное управление требованиями является ключевым фактором всего процесса разработки ПО. Требования определяют то, что должна делать система. Поэтому в течение всего жизненного цикла проекта нужно организовать эффективную работу с ними. Первым шагом в этом направлении служит организация хранения всех выявленных требований.
Основные цели управления требованиями:
Для достижения этих целей важно, прежде всего, выяснить определение и контекст проблемы, которую будет решать разрабатываемая система. Бизнес-правила, Модель бизнес вариантов использования и Модель бизнес объектов, разработанные в течение бизнес моделирования, будут служить при этом ценной исходной информацией. Идентифицируются заинтересованные лица и выявляются, собираются и анализируются Запросы заинтересованных лиц. Разрабатываются документ Концепция, Модель вариантов использования, Варианты использования и Дополнительная спецификация, которые описывают, что будет делать система. Все заинтересованные лица, включая заказчиков и потенциальных пользователей, рассматриваются как важные источники информации для пополнения требований к системе.
Запросы заинтересованных лиц- это список пожеланий различных заинтересованных лиц проекта (заказчики, пользователи, другие заинтересованные лица) относительно содержания системы, вместе с информацией о том, как каждое пожелание рассмотрено в проекте. Документ "Концепция" дает полное представление о разрабатываемой программной системе и поддерживает взаимопонимание между заказчиком и разрабатывающей организацией. Каждый проект нуждается в источнике, фиксирующем ожидания заинтересованных лиц.
Рис. 1
Документ Концепция пишется с точки зрения заказчиков и фокусируется на существенных возможностях системных и приемлемом уровне качества. Документ Концепция должен содержать описание того, какие возможности будут включены в систему, а какие рассмотрены, но не включены. Кроме того, он должен определить операционные возможности (объемы, быстродействие, точность), профили пользователей и межоперационные интерфейсы с объектами за границами системы, если такие существуют. Документ Концепция обеспечивает договорное основание для требований, видимых совладельцами.
Модель вариантов использования должна служить средством общения и базой для договоренности между заказчиком, пользователями и разработчиками о функциональных возможностях системы. Она позволяет:
Модель вариантов использования состоит из вариантов использования и актеров. Каждый вариант использования в модели подробно, по шагам описывает, как система взаимодействует с актерами, и что система делает в варианте использования. Варианты использования функционируют как единая "красная нить" на всем протяжении жизненного цикла программы; одна и та же модель вариантов использования используется при анализе и проектировании системы, ее выполнении и испытаниях.
Дополнительные спецификации - важное дополнение к модели вариантов использования, потому что вместе они фиксируют все необходимые требования к программному обеспечению (функциональные и не функциональные), которые вместе составляют полную спецификацию требований к программному обеспечению. Полные определения требований к программному обеспечению, описанные в вариантах использования и Дополнительных спецификациях можно объединять для определения Спецификации требований к программному обеспечению (Software Requirements Specification - SRS) для специфической "возможности" или некоторой части системы.
В дополнение к этому разрабатываются следующие артефакты: Глоссарий, Иллюстрированный сценарий варианта использования и Прототип интерфейса пользователя. Глоссарий важен, потому что он определяет общую терминологию для всех моделей и текстовых описаний в проекте или в организации. Иллюстрированный сценарий варианта использования и прототип интерфейса пользователя - все это результаты моделирования и прототипирования интерфейса пользователя, которые выполняются параллельно с другими действиями разработки требований. Эти артефакты обеспечивают важные механизмы обратной связи в более поздних итерациях для обнаружения неизвестных или неясных требований.
IBM Rational RequisitePro - это инструмент управления требованиями, разработки сценариев использования. Предназначен для рабочих групп, желающих улучшить контроль целей проекта, снизить риски и улучшить качество приложения до их развертывания.
Архитектура Rational RequisitePro является гибкой, что позволяет отделять документы от БД без ущерба для дальнейшей работы или доступа других членов команды. Авторы требований, подрядчики или иные лица, внешние по отношению к организации, могут составлять, просматривать, редактировать и утверждать документы независимо от БД проекта. Эти документы автоматически синхронизируются с проектом при помещении их обратно. Rational RequisitePro поддерживает ряд ведущих СУБД (Oracle, Microsoft SQL Server и Microsoft Access), с помощью которых можно легко организовывать, прослеживать отношения, устанавливать их приоритеты и отслеживать изменения требований.
RequisitePro предоставляет стандартные атрибуты и их значения сразу после установки и может легко настраиваться для поддержки процессов и регламентов. Присваивание атрибутов, например приоритета, сложности, состояния, владельца и номера версии, поможет разработчику управлять своими требованиями так, как это было бы невозможно с помощью одних лишь документов.
RequisitePro предусматривает механизмы для легкого определения и анализа контроля доступа. Такое визуальное уведомление об изменениях в режиме реального времени позволяет точно определять их влияние во всем проекте и оценивать, насколько они "покрываются" тестами. Rational RequisitePro ведет историю изменений требований, отслеживая их эволюцию по ходу выполнения проекта, и позволяет выяснить кто, когда, зачем и какие изменения в требование вносил. Таким образом, можно проанализировать необходимость изменения и его влияние на проект.
Объединяя мощь базы данных с удобством Word, Rational RequisitePro предлагает самое надежное и удобное в использовании решение в области управления требованиями.
Требования должны быть интегрированы с другими процессами жизненного цикла разработки ПО, что обеспечивает четкие коммуникации в проекте. Это экономит ресурсы за счет минимизации изменений уже готовых материалов. Rational RequisitePro позволяет использовать требования (из своего репозитория) в других инструментах Rational Software.
Рис. 3. Для улучшения коммуникации и повторного использования формулировок требований RequisitePro интегрирован
с другими продуктами Rational Software на всех этапах жизненного цикла разработки ПО.
В процессе разработки неизбежно появление новых требований. Интеграция Rational RequisitePro и Rational ClearQuest облегчает внесение изменений в проект, ассоциируя запрос на изменение с новым требованием, которое его удовлетворяет. Доступ к информации о требованиях возможен как из RequisitePro, так и из ClearQuest, включая, например, такие атрибуты, как приоритет, статус, трудоемкость и т.д.
Интеграция с Rational ClearCase позволяет контролировать версии требований наравне с другими артефактами проекта и создавать базовые версии требований.
Интеграция с Rational TestManager гарантирует, что требования используются как исходная информация для создания сценария тестирования тестировщиком и специалистом по контролю качества.
Интеграция Rational RequisitePro и Rational Unified Process (RUP) обеспечивает ясным пониманием основных задач всех участников проекта в процессе управления требованиями.
Ниже приведены базовые системные требования для использования IBM Rational RequisitePro версии 7.0.1 :
|
Операционная система |
Программное обеспечение |
Аппаратное обеспечение |
|
ПРОДУКТЫ Microsoft Office (опционально):
ПОДДЕРЖИВАЕМЫЕ БАЗЫ ДАННЫХ :
HOSTED ENVIRONMENTS:
|
ПРОЦЕССОР :
ОПЕРАТИВНАЯ ПАМЯТЬ RAM :
СВОБОДНОЕ МЕСТО НА ЖЕСТКОМ ДИСКЕ:
|
|
|
 |
