Книга на мой взгляд очень интересная, по секрету поделюсь, что я прочитала ее не с начала, скорее — с конца — в начало, поскольку все самое интересное, включая словарь и сферы применения в рамках сбора требований, все это написано как раз в конце книги. Даны четкие рекомендации как составить список требований и описать систему с разной степенью детализации, начиная от общей концепции, как должно работать приложение, до постраничного составления сценариев.
Для чего она нужна — чтобы лучше понимать, что все-таки делают исполненные очей бизнес-аналитики, когда приходит запрос — хочу сайт, как там по ссылке.


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

Основные понятия:

Use Case — последовательность шагов, которая обычно определяет все взаимодействия между какой-то ролью/функцией (в UML именуемой как «Аctor») и системой, для достижения какой-то определенной цели.
Actor — это в данном случае либо человек, который взаимодействует с системой, либо какая-то внешняя система, которая может запускать какие-то действия в нашей системе. Проще говоря, Use case это все варианты сценариев, всего того что происходит на странице.
Goals — цель, Goal failure — соответственно, недостигнутая цель.
Хороший Use case должен быть написан простым и понятным языком, чтобы информацию можно было легко и просто понять другому человеку.
Описывается основные характеристики:
Scope — что представляет собой проект или часть проекта,
Primary Actor (основное действующее лицо или элемент системы, инициирующий взаимодействие с системой в рамках главной цели) описание того, кто (пользователи/админы) или что будет работать на данной странице и
Level — уровень на котором все происходит;
Preconditions and Guarantees — что должно быть до и после запуска Use case;
Main success scenario — основной сценарий, что должно быть выполнено успешно;
Extensions — различные варианты, когда система отклоняется от основного сценария.
От себя хотелось бы отметить, мне очень понравилась ссылка на Стива Эдольфа, «используйте метод <погрузиться и всплыть>. Создайте основую модель высокого уровня, описывающую ваше представление о том, как могла бы работать новая система. Стремитесь к простоте, поскольку это неисследованная территория. Придумайте, как мог бы выглядеть основной сценарий, проиграйте его со специалистами по старой системе. Затем погрузитесь в один из ваших новых Use Cases. Просто задайтесь вопросом что происходит, в реальности, не вдаваясь в формальные требования <..> Наконец, вернитесь на поверхность, что изменилось после того как вы погрузились в детали? Настройте модель, а затем повторите погружение для следующего Use case...»

Общие правила

Стоят того, пожалуй, чтобы процитировать их полностью:

1. описание системы должно быть читаемо;
2. начинать всегда нужно с общей концепции, и переходить к подуровням,

Для каждого шага:

Сначала следует описать, в чем состоит процесс (по шагам), позволяющей достичь цели и описать намерения Actor, а не вдаваться в детали пользовательского интерфейса. (где Actor — не актер, как любят писать в русских переводах, это может быть человек, либо система, которая производит сумму вычислений, действий и операций на данном уровне приложения или на данной странице).
Затем следует указать информацию, которая должна идентифицировать actor, по каким критериям, или каким именно образом должно происходить проверка обновлений по статусам. Вслед за этим следует написать комментарий о том, что происходит между различными шагами, или если эти шаги отсутствуют.
После этого стоит задаться вопросом, какая цель осуществляется на следующем более высоком уровне с помощью данного шага.

Для описаний данных:

Заносить в описание Use case только соответствующий ему уровень детализации.
Уровень детализации 1: Название данных
Уровень детализации 2: Поля данных, которые связаны с названием
Уровень детализации 3: Типы полей, длина поля и как именно происходит проверка достоверности внесенных данных.

Что не входит в use case, но всегда так или иначе с ним связано и нужно учитывать: форматы данных, протоколы ввода/вывода, требования к производительности и требования к интерфейсу пользователя, проектирование интерфейса пользователя, бизнес-правила.

Есть несколько стадий точности:
1. Действующие лица и цели: Перечислите действующих лиц и каждую из целей, которую будет преследовать система. Проанализируйте правильность и полноту этого списка. Расставьте приоритеты и распределите цели между командами разработчиков и версиями. Теперь у вас есть функциональные требования к первому уровню точности.
2. Краткое изложение Use case или основной сценарий: для Use case вы выбрали следование основному сценарию в общих чертах. Рассмотрите его в форме набросков, чтобы быть уверенным, что система действительно удовлетворяет требованиям участников, о которых вы заботитесь. Это второй уровень точности функциональных требований. Этот материал довольно легко набрать, в отличие от двух следующих уровней.
3. Условия отказа: Завершите основной сценарий и подумайте, какие отказы могут произойти. Занесите их в список, прежде чем решать, как система должна их обрабатывать. Описание процессов обработки отказов — более трудоемко, чем перечисление отказов. <...>
4. Обработка отказа: Напишите, как система должна реагировать на каждый отказ. Это часто непростой, утомительный и непредсказуемый процесс, поскольку при этом могут обнаружиться новые действующие лица, или новые цели, достижение которых должна обеспечить система.

Продолжение следует.