...Юрий, заказчик будет подписывать только один документ. Само-собой там всё логически поделено на модули, есть накая специфика. Финансы берут данны из инвестиций, инвестиции из корпоративных мероприятий (решения органов управления, а не пьянки 
) + есть несколько других, так же переплетённых модулей и куча отчётов.
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).
Просмотр сообщений
