Современные методы описания функциональных требований к системам

В книге описан один метод написания части постановки задачи, а именно метод use case. Что это такое? Это описание сценария взаимодействия пользователя с системой (или с бизнесом). Система при этом выступает как черный ящик (и это дает возможность разделить сложную задачу проектирования на проектирование взаимодействия и обеспечение этого взаимодействия). При этом вводятся стандарты нотации, что обеспечивает простоту прочтения в том числе не участникам, и позволяет делать некоторые проверки на полноту и соответствие целям стейкхолдера. В целом, после прочтения книги, к сожалению, не понятно как пройти весь путь аналитика от бизнес-проблем до формализованного ТЗ для разработчика. В книге рассказывается только часть процесса с неясно сформулированными входящими и неясно показанными…

Помнится давно я впервые столкнулся с вариантами использования и немного офигел. Глядя на них меня очаровывала их простота и наглядность. Но как только я попытался сделать их сам, то мой мозг закипел. Я задался вероятно попсовым вопросом: «Как определить границы описания системы? В нашей жизни возможно бесконечное количество вариантов использования. Если пытаться полностью описать систему то описывая расширения простой авторизации я доберусь до причины смерти динозавров».

С тех пор прошло много времени и только недавно я смог ответить на этот вопрос и многие другие. Коберн в своей плохо переведенной и полной опечаток книге «Современные методы описания функциональных требований к системам» описывает методы создания вариантов использования. Рекомендуэ.

Классика не стареющая с Годами

Очень полезна для обучения тому, как же надо на самом деле составлять варианты использования (прецеденты). Мало книг, где работа с требованиями и составление прецедентов описаны так подробно и основательно. Для постановщика задач, аналитика и проектировщика должна стать настольной. Для восприятия книга довольно трудна, приходится перечитывать не раз.