paul310Ситуация:
6. Описание БП проиходит в Word'e
Word - это вполне адекватный инструмент для управления требованиями в небольших проектах. Все зависит от целей описания БП.


Word как инструмент документирования требований скорее. Для управления требовниями ой как неудобно пользоваться вордом.

AlexTheRavenГлубокое IMHO:

Какими средстами лучше пользоватся для свзяи БП и требованиями ТЗ, когда БП меняется?
С ТЗ - не знаю, а вот в RUP SRS есть такой класс требований (и даже не совсем требований, а скорее законов природы :) ) - бизнес-правила, которые и являются моделями бизнес-процессов. Трассируете (связываете) их с функциональными требованиями, и как только бизнес-требование изменилось - можете пройтись по связанным с ним функциональным требованиям, пересмотреть их. Если используете, например, RequisitePro или CaliberRM - это можно сделать с помощью матрицы трассировок. Мой опыт, правда, показывает, что трассировки - ерунда, и что просто должен быть человек, который постоянно держит в голове ВСЕ требования и страстно желает поддерживать их в целостном состоянии.



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