Коммерческие средства управления требованиями позволяют вам определять различные типы (или классы) требований, такие, как бизнес-требования, варианты использования, функциональные требования, требования к оборудованию, а также ограничения. Это позволяет вам отделять задачи, с которыми можно работать, как с требованиями, от другой полезной информации, содержащейся в спецификации требований к ПО. Все инструментальные средства обладают мощными возможностями определения атрибутов для каждого типа требований, что представляет огромное преимущество перед обычными способами документирования спецификации требований к ПО.
Большинство инструментальных средств управления требованиями в той или иной степени интегрируются с Microsoft Word — на панель меню Microsoft Word добавляется их специализированный раздел. Vital Link основан на Adobe FrameMaker, a Slate интегрируется и с FrameMaker, и с Word. Инструментальные средства высокого уровня поддерживают широкий набор форматов файлов для импорта и экспорта. Некоторые инструменты позволяют пометить текст в документе Word, чтобы обращаться с ним, как с отдельным требованием. Инструмент выделяет требование и вставляет в документ закладки Word и скрытый текст. Кроме того, вы получаете возможность различными способами анализировать документы, чтобы извлекать из них отдельные требования. Анализ документа в текстовом редакторе будет несовершенным, если только при создании документа вы не станете последовательно использовать стили или ключевые слова, такие как «должно».
Инструментальные средства поддерживают иерархическую систему нумерации требований помимо уникального внутреннего идентификатора для каждого требования. Эти идентификаторы обычно состоят из короткого текстового префикса, который указывает на тип требования, например UR обозначает требование пользователя (user requirement), и уникального целого числа. Некоторые средства предоставляют возможность пользоваться Microsoft Windows Explorer — для отображения и управления иерархическим деревом требований. Один из способов отображения требований в DOORS — иерархически структурированная спецификация требований к ПО.
К возможностям вывода данных инструментальных средств относится способность генерировать требования либо в документе заданного пользователем формата, либо в табличном отчете. CaliberRM обладает мощной функцией Document Factory, позволяющей определить шаблон спецификации требований к ПО в Word, используя простые способы для разметки макета страницы, шаблона текстов, атрибутов для извлечения данных из базы и стилей текста, которые вы хотите применять. Document Factory заполняет этот шаблон информацией, которую выбирает из базы данных соответственно критериям заданного пользователем запроса, чтобы создать заказанный документ спецификации требований к ПО. Таким образом, спецификация требований к ПО, в сущности, представляет собой отчет, генерируемый по некоторой выборке из содержимого базы данных.
Все инструментальные средства обладают развитыми возможностями трассирования. Например, в RTM Workshop каждый проект определяет схему классов, похожую на диаграмму «сущность-связь», для всех хранящихся типов объектов. Трассирование выполняют, определяя связи между объектами двух классов (или внутри одного класса) на основе взаимоотношений между классами, заданными в схеме.
К числу других функций относится возможность задавать группы пользователей и определять разрешения некоторым пользователям или группам на создание, чтение, обновление и удаление проектов, требований, атрибутов и их значений. Некоторые продукты позволяют поместить нетекстовые объекты, такие, как графику и крупноформатные таблицы, в базу требований. Инструментальные средства предлагают также средства обучения или проекты примеры, которые помогут пользователям научиться работать быстро и эффективно.
Эти продукты отражают тенденцию к увеличению интеграции с другими инструментальными средствами, используемыми в разработке приложений, как показано на рис. 21-1. Выбирая средство для управления требованиями, выясните, сможет ли оно обмениваться данными с другими используемыми вами инструментами. Вот лишь несколько примеров взаимосвязей между инструментальными средствами, существующими сегодня:
· вы можете устанавливать связи между требованиями в RequisitePro и вариантами использования, смоделированными в Rational Rose, a также вариантами тестирования, хранящимися в Rational TeamTest;
· DOORS позволяет трассировать требования вплоть до отдельных конструктивных элементов, хранящихся в Rational Rose, Telelogic Таu и других инструментах проектирования;
· RequisitePro и DOORS могут устанавливать связи между отдельными элементами проектного задания в Microsoft Project;
· CaliberRM имеет централизованную структуру коммуникаций, которая позволит вам связать требования с вариантами использования, классами или элементами дизайна (проектирования) процессов, хранящимися в ТogetherSoft Control Center, с исходным кодом, хранящемся в Borland's StarTeam, и с тестовыми элементами, хранящимися в Mercury Interactive'sTestDirector. Вы сможете получать доступ к этим взаимосвязанным элементам непосредственно из требований, хранящихся в базе данных CaliberRM.
Оценивая программные средства, подумайте, как вы сможете воспользоваться преимуществом интеграции продуктов при составлении требований, тестировании, трассировании проекта и других процессах. Например, подумайте, как опубликовать основной набор требований в инструменте для управления версиями продукта и определить связи трассирования между функциональными требованиями и конкретными элементами дизайна или кода.
Рис. 21-1. Инструментальные средства управления требованиями интегрируются с другими видами программных средств