Привет "управляющим требованиями"!

Некоторое время назад я имел опыт управления требованиями в серьёзном проекте с помощью RequisitePro, о чём и написал статью " Управление требованиями и автоматизация этого процесса ". В ней, в частности, я отметил те досадные ограничения RequisitePro, которые повстречались в нашей работе с ним.

Так вот, буквально в прошлом месяце я беседовал со специалистом по CaliberRM, захватив с собой распечатку этой статьи. Я прошёлся по всем отмеченным мой замечаниям к RequisitePro и оказалось, что ни по одному из них сегодняшний CaliberRM не лучше :-(.

Вывод, который я сделал для себя, такой: ни RequisitePro (версии 2003.06.13), ни сегодняшний CaliberRM не предназначены для управления требованиями на бизнес-уровне (что актуально для меня); для требований на уровне компонентов программного обеспечения - наверное, да - ведь пользуются же ими люди... так что для меня вопрос о выборе средства управления требованиями тоже остался открытым.

Sergey Orlikа можно было бы, уже абстрагируясь от конкретных инструментальных средств, услышать Ваши требования к идеальной системе управления требованиями (с мотивацией необходимости наличия той или иной возможности)? Хотя бы Top-10 ;)
Похоже, тут та же история, что и с выбором нотации для моделирования, о которой мы говорили вчера ( BPMN и UML - в чем отличие? ): для требований разных уровней архитектуры предприятия (enterprise architecture) нужны различные подходы.

В частности:
1. Понятие "требование" на бизнес-уровне настолько шире и сложнее классического "Система должна делать то-то и то-то", что в соответствующем инструменте управления такими требованиями необходим кардинально другой объект "требование". Именно из-за попыток "впихивания" сложных, структурированных и форматированных требований в прокрустово ложе инструмента и возникает большинство проблем.

Для меня обязательными являются как...
2. ...возможность работы с документами MS Word, содержащими стили (а не форматирование просто RTF), в рамках инструмента управления требованиями (документ MS Word - это и есть часть требования), ...

3. ...так и возможность на основе:
1) репозитория требований;
2) внешних документов, на которые в репозитории есть только ссылки (например, моделей, текстовых документов и т.п., с которыми можно работать независимо от репозитория и инструмента управления требованиями);
3) и шаблона MS Word (содержащего, в частности, стили абзацев, таблиц и т.п.),
- создания документа MS Word, который без каких-либо доработок является готовым артефактом проекта (например, Техническим заданием, выполненным по ГОСТу и в формате, предложенном Заказчиком). О моём понимании важности стилей MS Word на днях выйдет статья, и я пришлю ссылку.
Таким образом, мне не потребуется отдельно дорабатывать выходные артефакты проекта, а они будут просто собираться из частей, центром которых будет некий "репозиторий бизнес-требований".

А вообще надо будет подумать подробнее/пособирать информацию на эту тему, наверняка люди уже придумали что-то похожее...

1. По поводу "внешних документов" предлагаю ещё более радикальную формулировку требования к системе управления требованиями:
Система управления требованиями должна ориентироваться на то,
что документы-требования хранятся во внешнем хранилище документов.
При этом внутри самого "репозитория требований" хранятся, в основном, метаданные требований и информация, специфичная именно для процессов управления требованиями.

В настоящее время наиболее удобное хранилище требования, формулировка которого превышает несколько предложений, - это файловая система. Для документов, хранящихся в файловой системе, легко организовать и доступ, и контроль этого доступа, и полнотекстовый поиск, и многое что ещё. "Репозитории требований" современных инструментов убоги и неудобны по сравнению с файловой системой и её расширениями. И гнаться за файловой системой, по-моему, нет смысла. В этой связи начинаешь с новой стороны смотреть на инициативы, подобные WinFS , ориентированные на расширение возможностей файловой системы.

2. По поводу вопроса "Что такое требование". На уровне бизнес-процессов (на уровне предприятия) возникают требования как в виде текстовых описаний (сценариев, вариантов использования, см. Новый взгляд на описание бизнес-процессов ), так и в виде графических моделей/диаграмм (см., например, статью Architecture and Architecture Modeling Techniques ).
Эти документы организованы сложным образом, предназначены для различных аудиторий, и на их основе создаются различные артефакты проекта (отчётные документы).
Если "система управления требованиями" будет требовать куда-то _повторно_ "заносить" эти модели/описания и т.п., искусственным образом разбивать их на части, а потом самому отслеживать их актуальность..., то этой системой управления требованиями никто и не будет пользоваться: архитекторы и аналитики следуют прагматичному принципу: "не повторяй себя" ( DRY ). Кроме того, нужно иметь ввиду, что на уровне предприятия одно описание бизнес-процесса может содержать требование к нескольким "Системам" (приложениям, проектам автоматизации и т.п.).

3. По поводу "атомарности" требований. Возможно, "описание бизнес-процесса" действительно будет "атомарным требованием", которое кратко можно сформулировать так: "Система должна делать то, что указано в данном описании". В то же время, документ, который с точки зрения управления требованиями есть "атомарное требование", с точки зрения архитектора есть сложная, структурированная сущность, модель, с точки зрения владельца бизнеса - это рассказ о его бизнесе. Здесь нет противоречия.

4. Система управления требованиями должна максимально использовать атрибуты документов - требований, например, атрибуты документов MS Word, содержащих сценарии, артибуты графической модели в файле хранения этой модели и т.п. Тогда не потребуется повторный ввод информации и не будет проблем с её обновлением.

5. По поводу стилей MS Word, см. статью Документ MS Word - всем миром . Содержание данной статьи сильно пересекается с процессами управления требованиями, в которых требования создаются разными людьми ("всем миром"), а потом на основе этих требований создаётся множество различных документов: как тех, которые нужны для самого процесса разработки (участникам команды), так и те, которые необходимы для формального выполнения проекта в соответствии в условиями контракта (например, Клиент (Заказчик) может требовать оформления документации по неким стандартам).