Комментарии 9
Описание бизнес требований в формате use case, это лучшее что я видел в айти. При этом любой пример использования use case сценариев априори хороший, а плохой пример - не использование use case сценариев впринципе.
Непонятно, на какое понимание БТ вы опираетесь. Вигерс и BABOK считают бизнес-требованиями цели организации в конкретной инициативе оргразвмтия.
На ISO 29148? Но там вроде БТ понимаются как бизнес-процессы и бизнес-функции уровнем выше юскейсов.
А ваши юскейсы даже не про бизнес-уровень, а про человеко-машинное взаимодействие, которое по стандартам системной инженерии находится между 2-м и 3-м уровнем:
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
Бизнес приходит с требованиями и проблемами, а не с юзкейсами.
Далее уже задача аналитика сориентироваться среди имеющегося функционала и подумать над дополнительными функциями.
И на основе этих функций можно написать юзкейсы и задачи разработке.
Самый главный вопрос, который мучает многих:
А как от юзкейсов перейти к системе?
Оставьте в покое уже тему с Use Cases! Технике более 20 лет, но нет - аналитики продолжают про неё рассказывать, будто это что-то невиданное.
Если все так очевидно, почему постоянно продолжают писать плохие кейсы.
А я отвечу почему - потому что специалисты как прочитают книжку так ее и трактуют. Тут собственно собрана конкретная инструкция, которую можно загрузить в промт llm и на этапе прескорринга обратно отбрасывать требования, и не брать в работу всякое непроработанное г@вно
Гайд по работе с бизнес-требованиями. На основе формата Use Case