В предыдущих главах я уже говорил о создании спецификации требований к ПО на естественном языке, которая содержит функциональные и нефункциональные требования, а также, о создании документов, содержащих бизнес-требования и описания вариантов использования. Документальный способ хранения требований имеет массу ограничений, в том числе:
· трудность обновления и синхронизации документов;
· всем членам команды, которым это необходимо, передачу изменений приходится осуществлять вручную;
· трудность хранения дополнительной информации (атрибутов) для каждого требования; трудность определения взаимосвязей между функциональными требованиями и другими элементами системы;
· трассирование статуса требований представляет собой трудный и неудобный процесс;
· одновременное управление наборами требований, запланированных для различных выпусков или взаимосвязанных продуктов, затруднено. Когда реализация требования откладывается до следующего выпуска, аналитику приходится перемещать его из одной спецификации требований в другую;
· при повторном использовании какого-то требования аналитик приходится копировать текст исходной спецификации требований в спецификацию требований каждой системы или продукта, где оно будет использоваться;
· трудность модификации требований несколькими участниками проекта, особенно если они географически разделены;
· отсутствие удобного места хранения требований, которые были предложены, но отклонены, или требований, удаленных из основной версии.
Средство управления требованиями, хранящее информацию в многопользовательской базе данных, позволяет снять эти ограничения. В небольших проектах для управления требованиями вам пригодятся электронные таблицы или простые базы данных, сохраняющие как текст, так и отдельные атрибуты каждого требования. В более крупных проектах выгодно применять коммерческие средства управления требованиями. Такие продукты позволяют пользователям импортировать требования из исходных документов, определять значения атрибутов, фильтровать и выводить на экран содержание базы данных, экспортировать требования в различных форматах, контролировать связи трассирования и соединять требования с элементами, хранящимися в других средствах разработки ПО.
| Ловушка Избегайте искушения разработать собственное средство управления требованиями или на скорую руку слепить его из средств офисной автоматизации общего назначения в подражание коммерческим продуктам. Первоначально это кажется легко, но такая работа может быстро истощить ресурсы команды, не обладающей средствами, необходимыми для создания желаемого инструмента. |
Обратите внимание, я называю эти продукты средствами управления требованиям, а не их разработки. Они не помогут вам определить потенциальных пользователей или собрать нужные требования для создаваемого продукта. Тем не менее они позволяют очень гибко управлять изменениями в этих требованиях и использовать их как основу для конструирования, тестирования и управления продуктом. Эти инструментальные средства не заменяют собой приемов, с помощью которых члены вашей команды выявляют требования и управляют ими. Используйте инструменты, когда у вас уже есть рабочая методика, но ей не хватает эффективности; не надейтесь, что инструмент восполнит недостаток трудолюбия, дисциплины, опыта или понимания.
Данная глава рассказывает о нескольких преимуществах использования средств управления требованиями и указывает на некоторые общие возможности таких продуктов. В табл. 21-1 перечислено несколько доступных в настоящее время инструментальных средств управления требованиями. В этой главе я не буду подробно сравнивать их — функция за функцией, поскольку эти продукты еще развиваются, и их возможности изменяются с каждой версией. Цены на них, платформы, которые они поддерживают, и даже производители также часто изменяются, поэтому для получения текущей информации используйте Интернет-адреса, приведенные в табл. 21-1 (с учетом того, что и Интернет-адреса могут изменяться, если, например, один производитель ПО поглотит другого, как случилось за две недели до написания этого материала). Детализированное сравнение возможностей этих и многих других инструментальных средств вы найдете на Web-странице Intelnational Council on Systems Engineering (https://www.incose.org/toc.html- Error 404: Not Found прим. Редактора ). Там же опубликованы рекомендации по выбору инструментального средства управления требованиями (Jones и др., 1995).
Таблица 21-1. Некоторые коммерческие инструментальные средства управления требованиями
| Инструмент | Производитель | Способ хранения данных |
| Active! Focus | Xapware Technologies, https://www.hapware.com | База данных |
| CaliberRM | Borland Software Corporation, https://www.borland.com | База данных |
| C.A.R.E,, | SOPHIST Group, https://www.sophist.de | База данных |
| IDOORS | Telelogic, http:/www.telel ogic.com | База данных |
| RequisitePro | Rational Software Corporation, https://www.rational.com | Документ |
| RMTrak | RBC, Inc., https://www2.rbcorp.com | Документ |
| RTM Workshop | Integrated Chipware, Inc. https://www.chipware.com | База данных |
| Slate | EDS, https://www.eds.com | База данных |
| Vital Link | Compliance Automation, Inc., https://www.complianceautomation.com | Документ |
Важное отличие инструментальных средств заключается в способе хранения данных. Одни хранят все требования, атрибуты и информацию трассирования в базе данных. В зависимости от продукта, база данных может быть коммерческой или разработанной собственными силами и запатентованной, реляционной или объектно-ориентированной. Требования могут импортироваться из различных исходных документов, но затем они сохраняются в базе данных. Как правило, текстовое описание требования считается просто одним из атрибутов. Некоторые продукты позволяют устанавливать связи отдельных требований с внешними файлами (например, файлами Microsoft Word, Microsoft Excel, графическими файлами и т.д.), в которых содержится информация, дополняющая содержимое базы.
При документальном подходе документ, созданный при помощи текстового процессора (такого, как Microsoft Word или Adobe FrameMaker), считается основным хранилищем требований. RequisitePro позволяет вам выбирать текстовые строки в документе Word для сохранения их в виде отдельных требований в базе данных. После ввода требований в базу данных вы можете определить атрибуты и связи трассирования так же, как и в продуктах, данные которых хранятся в БД — механизмы синхронизации базы данных и содержимого документа для этого предусмотрены. RTM Workshop поддерживает обе схемы: в первую очередь хранение данных в базе данных, но также и в документе Microsoft Word.
Эти средства не дешевы, но высокая стоимость решения проблем управления требованиями оправдывает инвестиции в них. Учитывайте, что цена инструментального средства определяется не только ценой лицензии. Вам придется потратиться на компьютер, на который будет установлена программа, учесть ежегодные затраты на поддержку и периодическое обновление продукта, на установку ПО, администрирование, техническую поддержку и консультации производителя, а также на обучение пользователей. Проанализируйте возможные затраты и результаты до того, как примете решение о покупке.