Коллеги, в своё время я поднимал вопрос о работе с требованиями в РеквизитПро (http://www.uml2.ru/forum/index.php?topic=2184.0). По итогам решено было Реквизит в работе не использовать. Однако не прижилось и трассирование в табличке екселя.
Если кратко:
документ должен быть один, чтобы его подписывали;
документ безжалостно редактируется и перелопачивается заказчиком (в режиме правки).
Хотелось бы видеть зависимости требований (ибо их бывает куча и за всеми их хитросплетениями не всегда удаётся уследить).

В процессе ковыряний интернета, дёргания знакомых и не очень знакомых специалистов наткнулся на любопытный способ оформления требований (см вложение, на всякий случай соблюдал конфиденциальность) в виде своеобразных таблиц в текстовом документе.
То есть каждое требование - это вот такая табличка с описанием. Причём описание - только текст (никакими Кобернами и не пахнет).

Мне понравилось:
-Трассировки удобно использовать в документе
-Требование выделено и легко читается
-Требования относительно компактно расположены
- Всё в одном доке, как и хочет заказчик

Не понравилось:
- Боюсь сойти с ума при его составлении и редактировании (одно из моих текущих ТЗ на 800 стр и без каких-либо трассировок)

Может быть кто с таким стилем описания сталкивался? Или выскажет свои соображения?

ТЗ на 800 страниц! У вас похоже очень большая система, раз только требования к ней на 800 страниц тянут. Может имеет смысл декомпозировать требования на отдельные ЧТЗ по подсистемам? Для таких сложных систем таки имеет смысл использовать инструментарий RDM, а не просто Word.
А какие типы требований вы выделяете?

Юра, каким образом твои вопросы приближают автора к ответам на его?

Алексей, именно с таким стилем не сталкивался, но при условии, что документ ведёт один аналитик, такой подход может быть вполне оправданным.

Денис, спасибо!

Юрий, заказчик будет подписывать только один документ. Само-собой там всё логически поделено на модули, есть  накая специфика. Финансы берут данны из инвестиций, инвестиции из корпоративных мероприятий (решения органов управления, а не пьянки ) + есть несколько других, так же переплетённых модулей и куча отчётов.
800 это базовое ТЗ, прибавьте к нему ещё 9 ЧТЗ стр по 80....
ТЗ должно включать все требования - функциональные, нефункциональные. Но это уже другая история Проект практически закрыт, доделываем последнюю доработку. Далее я уже работать в компании не буду.
Тем не менее, раз уж вопрос поднят, то я начал копать про RDM, нагуглил на первой странице запроса следующее: http://www.powertest.com/files/datasheet-teamdefine.pdf    Вроде стало понятно я такое сокращение первый раз встретил..
Глобальная проблема описана мною в исходных данных - заказчик перековыривает вордовый документ в режиме правки, что пораждает лишние телодвижения аналитика по синхронизациям. Заказчик воспринимает только ворд и только один документ на один договор.
Хотелось бы услышать ваши соображения по-поводу найденного способа описания и трассировки требований...
Спасибо!

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

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

Еще для большого документа, с которым работает группа лиц, очень важно зафиксировать на начальных этапах структуру, и менять ее только с отдельным уведомлением, между версиями и не делая ничего другого в этот момент (то есть не принимая других правок). И вообще, стр4уктуру лучше сильно не менять, иначе у читателей крыша едет - они то не монопольно работают с документом, плюс у них выделяются некоторые "чувствительные точки" в которые они смотрят, изменение структуры требует заново их искать. Мне приходилось работать, когда ответственное лицо у заказчика с каждой версией меняло структуру, это кошмар.

И, наконец, формируя шаблон для требований посмотрите, что будет в режиме исправлений и как будет срабатывать объединение и сравнение версий. Напишите несколько требований, поправьте от разных пользователей, объедините. Могут быть чисто word-заморочки в этом процессе, связанные с нюансами форматирования (таблица/не таблица и т.п.). И еще могут быть заморочки с версиями Word - MS же с каждой версией его улучшает, и если автор и читатели-референты пользуются разными версиями, могут быть неприятные сюрпризы. Этот пункт чисто технический, просто лучше это все заранее проверить и сделать устойчивый в этом смысле шаблон оформления требования.

А в целом - способ рабочий, если заказчик хочет ТЗ на 800 страниц (есть такие заказчики, я знаю).

...Юрий, заказчик будет подписывать только один документ. Само-собой там всё логически поделено на модули, есть  накая специфика. Финансы берут данны из инвестиций, инвестиции из корпоративных мероприятий (решения органов управления, а не пьянки ) + есть несколько других, так же переплетённых модулей и куча отчётов.
800 это базовое ТЗ, прибавьте к нему ещё 9 ЧТЗ стр по 80....
ТЗ должно включать все требования - функциональные, нефункциональные. Но это уже другая история Проект практически закрыт, доделываем последнюю доработку. Далее я уже работать в компании не буду.
Тем не менее, раз уж вопрос поднят, то я начал копать про RDM, нагуглил на первой странице запроса следующее: http://www.powertest.com/files/datasheet-teamdefine.pdf    Вроде стало понятно я такое сокращение первый раз встретил..
Глобальная проблема описана мною в исходных данных - заказчик перековыривает вордовый документ в режиме правки, что пораждает лишние телодвижения аналитика по синхронизациям. Заказчик воспринимает только ворд и только один документ на один договор.
Хотелось бы услышать ваши соображения по-поводу найденного способа описания и трассировки требований...
Спасибо!

RDM это сокращение от Requirements Definition and Management, по сути, это синтезированный термин из книги Вигерса. ReqPro относиться к т.н. инструментарию RDM.

Возможно вы пытаетесь решить задачу управления содержимым "большого документа" и  изменениями в нем, а не столько собственно задачу разработки и управления требованиями (как отдельными дискретными утверждениями). Очень часто, аналитики не понимают разницы м/у этими двумя по своей сути разными задачами - для каждой из них есть свои способы решения. Чтобы понять какую именно из задач вы решаете, я и спросил про типизацию требований (как я понял вы выделяете только 2 типа требований - функциональные и нефункциональные?).

"У нас в полку был аналогичный случай" (с) ... один мой клиент имел сходную  проблему - тоже был вынужден работать с Word, где разные представители заказчика вносили правки в режиме исправлений, правда некоторые замечания заказчиком делались от руки на распечатанной версии документа, некоторые в режиме правки в Word, а некоторые просто по-телефону или e-mail  в тексте письма были. Документы были объемными и все это вызывало трепет и ужас, плюс еще и  формальное требование работать по ГОСТ 34. Я рекомендовал сделать три простые вещи:
1. Таки работать по ГОСТ 34, где в ТЗ писать только требования, а не проектные решения - для этого есть другие стадии, а именно Технорабочий проект и соответствующая документация в нем (им было предложено объединить эти две стадии в одну, для упрощения жизни), что позволит сократить объем ТЗ.
2. Четко разделить процессы выпуска релиза ТЗ и работы по сбору и анализу изменений (на основе замечаний заказчика), что позволит не терять замечания, не путаться в версиях и т.п. (+ работа PM-ов, которые должны были постепенно приучить заказчика к такой форме работы - замечания на релиз ТЗ + обсуждения спорных замечаний).  
3. Управлять требованиями, а не документом. Т.е. типизировать и дискретизировать требования и считать изменяющейся частью именно иерархию связанных требований, а структуру документа и вводные части - задающие контекст для разделов - редко изменяемой частью.

Кроме этого были предложено:
а) стандартные шаблоны формулровки требований, что позволило сделать их описания более компактными, лаконичными и однозначными - что в свою очередь вызывало меньше замечаний заказчика. Детализация требования - вниз по иерархии, ссылки на структуры данных из Словаря данных.
б) если требование имело трассировки - указывать в виде ссылок на ID связанных требований. Учитывая, что на стадии ТЗ архитектуры системы еще не было - то и ссылок на элементы архитектуры не было, как и на тест-кейсы. Да и заказчика такие ссылки именно в ТЗ мало интересовали.
в) использовать для управления требованием и генерации релиза ТЗ RDM инструментарий (выбор был между DOORS и CaliberRM).

Да, это всё интересно, спасибо. Как раз сейчас начинаю ГОСТ изучать, да и в принципе замечания и идеи интересны.
Тем не менее, хотелось бы услышать комментарии по моему изначальному вопросу.. Или вы считаете, что мне надо работать по вашему способу и найденный мною способ не эффективен (по каким-то причинам)?

присоединюсь к ранее высказавшимся коллегам, в первую очередь к Юрию:
1. Ведение структуры взаимосвязанных требований и представление требований в виде документа (ТЗ) - два разных вида деятельности.
2. Требованиями нужно управлять централизованно, можно делить на независимые разделы и не забывать контролировать интерфейсы между ними. (хватит Вам одного аналитика для этого или нужно несколько - является особенностями Ваших проектов и Вашего наличного личного состава)
3. Требования могут поступать непрерывно (на этом, собственно, и основывается такая организация работы с ними) и, соответственно, их обработка должна происходить также непрерывно или, скажем так, "синхронизированно" с их поступлением.
4. Документ же, представляемый заказчику (в т.ч. с учетом значимости и приоритетов требований) формируется итерациями/релизами, замечания, формируемые заказчиком, меняют не этот документ, а рассматриваются и вносятся в структуру требований обычным порядком (или с учетом их срочности), при необходимости попадают в следующий релиз и т.д. 
5. Для работы с требованиям и формирования документа удобно использовать подходящие средства. Если Вам подходит Ваша табличка - почему нет? Вот только достаточно ли Вам ее? Свой документ на 800 страниц Вы вручную писали?

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

Да, это всё интересно, спасибо. Как раз сейчас начинаю ГОСТ изучать, да и в принципе замечания и идеи интересны.
Тем не менее, хотелось бы услышать комментарии по моему изначальному вопросу.. Или вы считаете, что мне надо работать по вашему способу и найденный мною способ не эффективен (по каким-то причинам)?

Вы действительно верите, что не зная контекста в котором вы работаете можно сказать эффективен или нет данный способ? Но тем не менее ... вы рискуете остаться в памяти коллег "вечно молодым", т.к. попросту вас настигнет karoshi,  если изменения в формулировках требований, которые будет делать заказчик, будет влиять на их трассировку, и если вы эти связи будете отслеживать один и вручную ... с поправками на общее кол-во требований, топологию связей требований, среднее число трейсов на одно требование и среднее кол-во изменений на одно требование.

Как этого избежать (один из возможных вариантов) - я написал выше - это решение "корневой проблемы". Иногда более эффективно решать именно ее, а не ее следствия.

Юрий, да, ваше сообщение выше было очень полезным.
Контекст можно отбросить - я работаю с 800 стр ТЗ последнюю неделю и вопрос в теме скорее теоретический, с прицелом на новые проекты.

Вижу следующее, на 800 стр (то есть крупные проекты на пару лет с объёмным ТЗ) метод, как я вижу по комментариям - не рабочий.
На маленькие проекты я бы отдал предпочтение user story..
На средних, где ТЗ будет стр на 200, например, я вижу данный метод описания ТЗ живучим.. То есть есть некоторая грань по объёму информации/документации, когда я не вскроюсь от трассировок и кол-ва требований, работая с ними вручную.

У себя на проекте мы в своё время хотели вносить УЖЕ согласованные требования в реквизит, дабы облегчить написание ЧТЗ. Руководсто посчитало, что трудозатраты на занесение текущих требований в реквизит необоснованно экономически,это уже другая, пройденная история

У себя на проекте мы в своё время хотели вносить УЖЕ согласованные требования в реквизит, дабы облегчить написание ЧТЗ. Руководсто посчитало, что трудозатраты на занесение текущих требований в реквизит необоснованно экономически,это уже другая, пройденная история

О, да ... внедрение инструментальных средств RDM, это еще та тема ... Инструментарий эффективен на больших и долгоиграющих проектах или на множестве идущих параллельно средних. Плюс, конечно же культура работы с требованиями в организации играет немаловажную роль.

... Я рекомендовал сделать три простые вещи:
...

Было бы интересно узнать чем это закончилось, если конечно, уже закончилось