каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.
возможна ещё ситуация, когда аналитик записал требования правильно, но сам заказчик ошибается и выдал противоречивые или, как минимум, плохо согласованные требования.
И в первом и во втором случае меня в работе аналитика всегда сильно выручал метод построения ЮМЛ-моделей для себя - и текстовых экскурсий по ним - для Заказчика.
Обычно это диаграмма классов для бизнес-сущностей и диаграммы состояний для них же.
Иногда сильно помогает активити со свим-лайнами в двух вариантах:
- детальный, с отображением передаваемых между активностями объектов[в состояниях].
- и упрощённый, где поток объектов скрыт полностью или почти полностью.
В модели для себя пытаюсь увязать всё, что записано со слов Заказчика,
а затем - по модели излагаю своё понимание и задаю вопросы в текстовом виде.
Самое мучительное - именно качественная модель.
Если она получилась - текстовое описание рождается как речевой поток у спортивного комментатора :-)
Дальше - уже всё просто: Заказчику отсылается текст с 1-м (главным) вопросом:
правильно ли я, аналитик, понял суть происходящего в предметной области?
И если ДА, то как быть с проблемами, изложенными далее в пачке остальных вопросов?
Всё это пространное описание я привожу с одной целью -
указать, что вот оно, место для безмолвного моделирования:
бизнес-модель для согласования требований в умах аналитиков.
Даже если аналитик один, и в одном лице объединяет роли и автора и инспектора требований,
и даже, если Заказчик за такое моделирование не платит и падает в обморок при словах ЮМЛ и Диаграмма -
всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".
Процесс обратной семантической трассировки