Реальное дерево требований для коммерческого ПО, а тем более для бизнес-процесса - вещь для служебного использования. Потому не дам.

Сразу оговорюсь: занимаемся всё-таки тиражируемым (хотя и не «коробочным»), а не заказным ПО. Поэтому делаем не «вслепую» руководствуясь пожеланиями заказчиков, а хорошо их переосмысливая и иногда даже откладывая на светлое будущее.

Компания уже не маленькая, поэтому мы, системные аналитики, напрямую с заказчиками не контактируем.

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

Потом в обыкновенном MS Word'е пишем Концепцию. В ней описываем
-- какие проблемы нужно решить
-- кто заинтересован в решении проблем
-- как (в общем виде) разрабатываемое ПО поможет в решении проблем
-- какие функции (!!!) с точки зрения пользователя должны быть в будущем ПО.
Потом долго эту концепцию вылизываем, согласовываем с внутренними заинтересованными лицами и в конце концов утверждаем.

Дерево у нас – не CaliberRM’овское по умолчанию.
Есть STRQ («запрос заинтересованного лица») – туда вносим исходные требования из концепции.

Есть требование к системе – FEAT. Там есть группы «функциональные требования» и «нефункциональные требования». Туда мы и вносим требования из концепции, иногда по copy-paste, иногда – изменяя. Упорядочивая уже по примерной структуре системы (что к какому модулю). Трассировка с требованиями из концепции должна быть в 100% случаев.

Дальше уточняем FEAT, добавляя ещё 1-2 уровня иерархии.
Уточняем:
-- либо по вопросам, поступающим от архитекторов, программистов, тестировщиков (если от тестировщиков – значит, что-то пропустили мы, если от программистов – значит, что-то пропустили архитекторы)
-- либо по запросам, поступающим от заказчиков через маркетинг и консультантов.
В любом случае, сначала вносим требование как STRQ, сохраняя авторскую постановку, потом добавляем в детализацию соответствующих FEAT и делаем трассировку с STRQ.

STRQ и FEAT иногда удобно уточнять, добавляя варианты использования. Опять же, трассировка обязательна. Часто советуют начинать с вариантов использования, но для нас так неудобно.

У каждого требования есть внутренний источник (наш сотрудник), внешний источник (заказчик, лучше всего тоже конкретный человек), автор и исполнители. Если требование изменяется – исполнителям идёт уведомление. Если требование непонятно – системный аналитик идёт к внутреннему источнику.

Требование обладает важностью и вхождением в baseline. В соответствии с этим, а также с архитектурой, ПМы делают планы в MS Project’е, трассируя задачи с требованиями (что не обязательно, но полезно для верификации и валидации).

Архитекторы тоже могут привязывать свои модели к требованиям, но делают это нечасто: это не всегда возможно, а если возможно – то муторно (для верификации и валидации).

Время от времени проверяем трассировки. Если STRQ или UC не трассировано с FEAT – значит, мы где-то ошиблись.

Осилил!

Ruby<...>
О ... что это за контора такая продвинутая, с требованиями работает даже. У вас часом вакансий нет?
Компания как компания, не из самых продвинутых, но далеко не из последних. Продукт делаем сложный, новый, потому без управления требованиями никак.

Работать приходится много, но и платят нормально, и палочной дисциплины нет. Вот, по два раза в день на sql.ru захожу :) .

Знаете, я не представитель маркетинга, и не знаю, как может повлиять на наш имидж упоминание управления требованиями. И не начальник я (надеюсь, пока), а потому о вакансиях не осведомлён.

Работу, кстати, нашёл через sql.ru .