Спасибо, Gevorg. Очень познавательно
с другой стороны, - требования не могут “болтаться” в воздухе, они обязательно должны опираться на модели соответствующих уровней (уровень проблемы и уровень решений по ней). На начальных этапах сбора и анализа требований не следует ожидать, что такие модели будут цельными, согласованными, полными, - приходится довольствоваться тем, что объективно есть на текущий момент и выжимать из него всё, что можно.
Полностью согласен. Это также согласуется с моим пониманием управления требованиями и фактами из жизни проектов. Взять хотябы данные из книги Лармана Применение UML, где он описывает сущность итерационной разработки (стр. 89 русского 3-го издания от Вильямс):
25 % требований изменяются в ходе разработки;
45 % требований определенных до начала проектирования (каскадный подход) - не используются
19 % - используются редко
16 % - используются редко
13 % - часто используются
7 % - всегда используются
т.е. 64 % требований просто выбрасываются
Потому например в RUP очень четко определено и принудительно ограничено, что к первой точке следует определить и проанализировать не более 10% прецедентов и аркитектурно значимых нефункциональных требований.
Таким образом на первом этапе следует выделить наиболее значимые прецеденты, функциональные и не функциональные требования и их обработать, далее по нарастающей в итерационной манере идет выполенение 90% требований к первому устойчивому выпуску, на каждой итерации набор требований стабилизируется после анализа и формируется как я понимаю baseline
Просмотр сообщений
