IBM Rational Requisite Pro - средство управления требованиями к проекту. Позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения. Решение IBM Rational RequisitePro представляет собой инструмент управления требованиями и вариантами использования и предназначен для групп разработчиков, стремящихся усовершенствовать обмен информацией о целях проекта, расширить возможности коллективной разработки, сократить проектные риски и повысить качество приложений до этапа развертывания.
Успешный опыт разработки показывает, что эффективное управление требованиями является ключевым фактором всего процесса разработки ПО. Требования определяют то, что должна делать система. Поэтому в течение всего жизненного цикла проекта нужно организовать эффективную работу с ними. Первым шагом в этом направлении служит организация хранения всех выявленных требований.
Основные цели управления требованиями:
- Добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система.
- Дать разработчикам системы наилучшее понимание требований к системе.
- Определить границы системы.
- Обеспечить базу для планирования технического содержания итераций.
- Обеспечить базу для оценки стоимости и времени на разработку системы.
- Определить пользовательский интерфейс, фокусирующийся на потребностях и целях пользователей.
 |
 |
 | |
Интеграция Rational RequsitePro с другими средствами Rational
Техническая документация и руководство пользователя
Описание Rational Requisite Pro
Rational Requisite Pro - средство управления требованиями к проекту. Позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения. Решение IBM Rational RequisitePro представляет собой инструмент управления требованиями и вариантами использования и предназначен для групп разработчиков, стремящихся усовершенствовать обмен информацией о целях проекта, расширить возможности коллективной разработки, сократить проектные риски и повысить качество приложений до этапа развертывания.
Успешный опыт разработки показывает, что эффективное управление требованиями является ключевым фактором всего процесса разработки ПО. Требования определяют то, что должна делать система. Поэтому в течение всего жизненного цикла проекта нужно организовать эффективную работу с ними. Первым шагом в этом направлении служит организация хранения всех выявленных требований.
Основные цели управления требованиями:
- Добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система.
- Дать разработчикам системы наилучшее понимание требований к системе.
- Определить границы системы.
- Обеспечить базу для планирования технического содержания итераций.
- Обеспечить базу для оценки стоимости и времени на разработку системы.
- Определить пользовательский интерфейс, фокусирующийся на потребностях и целях пользователей.
Для достижения этих целей важно, прежде всего, выяснить определение и контекст проблемы, которую будет решать разрабатываемая система. Бизнес-правила, Модель бизнес вариантов использования и Модель бизнес объектов, разработанные в течение бизнес моделирования, будут служить при этом ценной исходной информацией. Идентифицируются заинтересованные лица и выявляются, собираются и анализируются Запросы заинтересованных лиц. Разрабатываются документ Концепция, Модель вариантов использования, Варианты использования и Дополнительная спецификация, которые описывают, что будет делать система. Все заинтересованные лица, включая заказчиков и потенциальных пользователей, рассматриваются как важные источники информации для пополнения требований к системе.
Запросы заинтересованных лиц- это список пожеланий различных заинтересованных лиц проекта (заказчики, пользователи, другие заинтересованные лица) относительно содержания системы, вместе с информацией о том, как каждое пожелание рассмотрено в проекте. Документ "Концепция" дает полное представление о разрабатываемой программной системе и поддерживает взаимопонимание между заказчиком и разрабатывающей организацией. Каждый проект нуждается в источнике, фиксирующем ожидания заинтересованных лиц.
Рис. 1
Документ Концепция пишется с точки зрения заказчиков и фокусируется на существенных возможностях системных и приемлемом уровне качества. Документ Концепция должен содержать описание того, какие возможности будут включены в систему, а какие рассмотрены, но не включены. Кроме того, он должен определить операционные возможности (объемы, быстродействие, точность), профили пользователей и межоперационные интерфейсы с объектами за границами системы, если такие существуют. Документ Концепция обеспечивает договорное основание для требований, видимых совладельцами.
Модель вариантов использования должна служить средством общения и базой для договоренности между заказчиком, пользователями и разработчиками о функциональных возможностях системы. Она позволяет:
- Заказчику и пользователям проверить, будет ли система такой, как они ожидали.
- Разработчикам системы создать то, что ожидают заказчик и пользователи.
Модель вариантов использования состоит из вариантов использования и актеров. Каждый вариант использования в модели подробно, по шагам описывает, как система взаимодействует с актерами, и что система делает в варианте использования. Варианты использования функционируют как единая "красная нить" на всем протяжении жизненного цикла программы; одна и та же модель вариантов использования используется при анализе и проектировании системы, ее выполнении и испытаниях.
Дополнительные спецификации - важное дополнение к модели вариантов использования, потому что вместе они фиксируют все необходимые требования к программному обеспечению (функциональные и не функциональные), которые вместе составляют полную спецификацию требований к программному обеспечению. Полные определения требований к программному обеспечению, описанные в вариантах использования и Дополнительных спецификациях можно объединять для определения Спецификации требований к программному обеспечению (Software Requirements Specification - SRS) для специфической "возможности" или некоторой части системы.
В дополнение к этому разрабатываются следующие артефакты: Глоссарий, Иллюстрированный сценарий варианта использования и Прототип интерфейса пользователя. Глоссарий важен, потому что он определяет общую терминологию для всех моделей и текстовых описаний в проекте или в организации. Иллюстрированный сценарий варианта использования и прототип интерфейса пользователя - все это результаты моделирования и прототипирования интерфейса пользователя, которые выполняются параллельно с другими действиями разработки требований. Эти артефакты обеспечивают важные механизмы обратной связи в более поздних итерациях для обнаружения неизвестных или неясных требований.
IBM Rational RequisitePro - это инструмент управления требованиями, разработки сценариев использования. Предназначен для рабочих групп, желающих улучшить контроль целей проекта, снизить риски и улучшить качество приложения до их развертывания.
- Rational RequisitePro открывает доступ через Web-интерфейс всем участникам команды, работающим удаленно или на разных платформах. Пользователи могут получать доступ, запрашивать, изменять и создавать требования через Rational RequisiteWeb-интерфейс.
- Решение использует расширенную интеграцию с приложением Microsoft Word, предоставляя пользователям знакомую среду для выполнения таких операций, как определение и организация требований.
- Объединяет мощную инфраструктуру базы данных и синхронизацию документов Word в реальном времени, что облегчает задачи организации, интеграции и анализа требований.
- Поддерживает детальную настройку и фильтрацию атрибутов, что позволяет максимизировать информативную значимость каждого требования.
- Предлагает подробные представления, отражающие взаимосвязи типа "родитель/потомок", а также отображает требования, на которые могут воздействовать входящие и исходящие изменения.
- Позволяет проводить сравнения проектов при помощи экспортируемых XML-описаний.
- Поддерживает интеграцию с многочисленными инструментами платформы разработки IBM Software Development Platform, что повышает доступность информации о требованиях и способствует передаче этой информации.
Рис. 2
Архитектура 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 ClearQuest
В процессе разработки неизбежно появление новых требований. Интеграция Rational RequisitePro и Rational ClearQuest облегчает внесение изменений в проект, ассоциируя запрос на изменение с новым требованием, которое его удовлетворяет. Доступ к информации о требованиях возможен как из RequisitePro, так и из ClearQuest, включая, например, такие атрибуты, как приоритет, статус, трудоемкость и т.д.
Версионный контроль в Rational ClearCase
Интеграция с Rational ClearCase позволяет контролировать версии требований наравне с другими артефактами проекта и создавать базовые версии требований.
Управление тестированием в Rational TestManager
Интеграция с Rational TestManager гарантирует, что требования используются как исходная информация для создания сценария тестирования тестировщиком и специалистом по контролю качества.
Лучший опыт использования и Rational Unified Process
Интеграция Rational RequisitePro и Rational Unified Process (RUP) обеспечивает ясным пониманием основных задач всех участников проекта в процессе управления требованиями.
Системные требования
Ниже приведены базовые системные требования для использования IBM Rational RequisitePro:
|
Операционная система |
Программное обеспечение |
Аппаратное обеспечение |
|
ПРОДУКТЫ Microsoft Office (опционально):
ПОДДЕРЖИВАЕМЫЕ БАЗЫ ДАННЫХ :
HOSTED ENVIRONMENTS:
|
ПРОЦЕССОР :
ОПЕРАТИВНАЯ ПАМЯТЬ RAM :
СВОБОДНОЕ МЕСТО НА ЖЕСТКОМ ДИСКЕ:
|