Для того, чтобы полностью описать ВИ, можно использовать следующий набор параметров:
- ID + наименование
- Краткое описание
- Актеры
- Триггеры
- Предусловия (Preconditions)
- Постусловия (Postconditions)
- Сценарии выполнения: базовый, альтернативные и исключительные
- Прочие дополнительные моменты
Давайте разберем по порядку и с примерами.
ID + Именование
С идентификатором, полагаю, понятно. Ключевые требования (к коим точно относятся единички скоупа решения) нужно уникально идентифицировать для последующей простой и корректной ссылаемости — это азы документирования требований. Что вы возьмете за айдишник, дело ваше. Например, такой формат: ВИ-01.
Что касается наименования, то тут рекомендуется быть консистентным, т. е. придерживаться однообразия в подходе. Я рекомендую использовать глагол в неопределенной форме: что сделать? Плюс, как правило, есть некие уточнения для данного глагола: как минимум практически всегда присутствует указание на объект действия.
Соответственно, для банкомата давайте возьмем «ВИ-01 Снять наличные средства», а для новостного портала — «UC-03 Просмотреть новость».
Краткое описание
Тут рекомендуется указать краткую суть ВИ и пользу, которую ВИ принесет первичному актеру. Это опциональная секция, но я рекомендую ей пользоваться, чтобы не заставлять читателя изучать сценарии ВИ, дабы понять, о чем идет речь. Плюс старайтесь именно раскрыть суть ВИ с акцентом на ценность для актера вместо банального дублирования названия — это глупо и бессмысленно.
Актер снимает определенную сумму наличных средств со своего счета с использованием банковской карты.
Актер просматривает содержимое отдельно взятой новости на портале, чтобы получить по ней детальную информацию.
Актеры
Перечислите тут первичных и вторичных актеров для ВИ, причем укажите явно, кто из них какой. Обратите внимание, что для обеспечения такого качества набора требований, как изменяемость, грешно заниматься дублированием информации. В ногу с этим принципом раскрытие того, какие у ВИ актеры, идет именно тут. Во всех остальных секциях в ВИ мы не пишем «Пользователь» или «Администратор» — мы пишем именно «Актер» (дополняя, если нужно, указанием на то, первичный он или вторичный).
Триггеры
Весьма опциональная секция. Триггеры — это то, что вызывает старт выполнения ВИ. В большинстве случаев триггером ваших ВИ будут желания актеров (некий мотивационный импульс, сподвигнувший актера к старту ВИ). Но иногда триггером может быть нечто иное: например, «Наступило 16.00 по часовому поясу X» — в подобных случаях, когда они не самоочевидны (то есть не «Актеру захотелось просмотреть новость»), их и рекомендуется указывать в данной секции.
Предусловия
Это условия, которые должны выполняться, чтобы сценарий ВИ вообще мог начаться (важно: чтобы он именно мог начаться, а не успешно завершиться). Это некое ограничение для старта выполнения ВИ актером. По своей сути, факт наличия предусловий и то, какими они будут, напрямую зависит от того, что вы будете считать сценарием юз кейса, т. е. c какого шага ваш актер будет начинать выполнение ВИ.
Для формулировки предусловий задайте себе (или иным ЗЛ, если необходимо) два вопроса:
1. С чего вообще будет начинаться ВИ? Что будет первым шагом в рамках сценария ВИ и кто его будет выполнять?
2. Что системе необходимо проверить (в выполнении какого условия ей необходимо убедиться), чтобы позволить первому шагу осуществиться?
Ответы на второй вопрос и будут вашими предусловиями.
Давайте разберем «ВИ-01 Снять наличные средства». Моим ответом на первый вопрос будет «Актер вставляет банковскую карту в банкомат». Во втором вопросе я могу сгенерировать следующее, что я и помещу в данный раздел: «Слот для банковской карты пуст» (ну а вдруг кто-то забыл карту до меня или напихал в разъем всякий мусор?)
Аналогично и для «UC-03 Просмотреть новость». Первым шагом сценария я бы поставил «Актер инициирует открытие деталей желаемой новости из новостной ленты». Обратите внимание, что в отличие от предыдущего примера я начинаю не с «подхода к системе с нуля», а с состояния, в котором актер уже видит новостную ленту. Допустимы оба подхода в трактовке сценариев ВИ — выбирайте тот, который вам ближе. Соответственно, для такого подхода предусловия уже будут иными, и в данном случае это «На экране отображена новостная лента с минимум одной новостью в списке» — без выполнения данного условия актер не сможет перейти на детали какой-либо новости. И тут для качественной трассировки требований можно сослаться на то, что это успешный результат выполнения ВИ «Просмотреть список новостей в категории», например так: «На экране отображена новостная лента с минимум одной новостью в списке (см. UC-02 Просмотреть список новостей в категории)».
Постусловия
Это условия/факты/состояния, которые справедливы/выполняются, когда ВИ успешно закончен. Вы также можете выделить отдельные постусловия для исключительных сценариев (об этом ниже), но, как правило, такое не делают.
Тут может быть что-то внешне видимое для актера или же какие-то внутренние изменения в системе. Как минимум, тут должен быть результат успешного выполнения ВИ. Все остальное, что вы хотели бы выделить и акцентировать, — на ваше усмотрение.
1. В слоте выдачи наличных средств доступна денежная сумма, которую актер снял со счета. 2. С банковского счета актера, к которому привязана карта, вычтена сумма снятых наличных средств. 3. В слоте выдачи чека операции доступен чек, отражающий детали операции по снятию наличных средств.
1. На экране отображены детали просматриваемой новости.
Сценарии
Сценарий – это последовательность шагов, которые выполняют актеры (первичные и вторичные) и система, чтобы осуществить ВИ. Фактически, тут и кроется большинство функциональных требований к решению в рамках детализации ВИ, то бишь алгоритмы системы и вызывающие их действия пользователя. Чаще всего сценарий напоминает «переброс мячика»: действие актера —> реакция системы —> действие актера —> реакция системы…). Но бывают, конечно, и последовательные несколько действий с любой из сторон.
Тут также важно отметить следующее: есть два существенно разнящихся взгляда на то, как детализировать юз кейсы.
- Интерфейсонезависимый подход. Такой подход подразумевает, что вы будете описывать требования внутри юз кейсов без упоминания специфик UI решения. Например, такой шаг ВИ, как «Актер сохраняет Заказ».
- В терминах интерфейса пользователя. В этом подходе вы сохраняете специфики UI. Например, «Актер нажимает кнопку «Сохранить» для сохранения Заказа».
Большинство теорий настаивают на первом подходе, но я не рекомендую относиться к этому настолько категорично. Оба варианта имеют право на жизнь, только нужно понимать, какой вариант и чем именно сработает лучше для ваших задач. Первый вариант фокусируется на требованиях вне деталей реализации. И в некоторых рабочих средах аналитики не оперируют пользовательским интерфейсом в рамках требований к решению, оставляя это на усмотрение дизайнеров и прочих юиксеров. Как следствие, если ваши требования к решению в принципе не должны касаться UI, то и ВИ, что вполне логично, должны следовать данному подходу. Второй же вариант вносит полную ясность в то, что и как делает пользователь в терминах элементов управления на UI. Если вы а) в ваших требованиях в силу специфики работы таки оперируете интерфейсом и его компонентами и б) у вас не описан UI со всеми его элементами и их параметрами где-то в ином месте (а иначе будет дублирование требований, что, в общем и целом, зло), то и в ВИ нет смысла делать требования интерфейсонезависимыми — лишняя абстракция только усложнит работу тем, кто будет брать ваши ВИ за базу для своих задач. Я в примерах буду оперировать первым вариантом, т. к. второй вариант, как мне кажется, проще и очевиднее.
Основной сценарий — это сценарий, приводящий к успешному завершению ВИ (может быть только один).
«ВИ-01 Снять наличные средства»
1. Актер вставляет банковскую карту в банкомат.
2. Система предлагает актеру ввести ПИН-код карты.
3. Актер вводит ПИН-код и подтверждает ввод.
4. Система проверяет корректность введенного ПИН-кода.
5. Система отображает список доступных операций с банковской картой.
7. Система предлагает актеру указать сумму для снятия средств.
8. Актер выбирает интересующий его вариант суммы из отображенных на экране.
9. Система проверяет наличие запрошенной суммы в резерве наличных.
10. Система отправляет запрос вторичному актеру на вычет запрошенной суммы из баланса актера на счету, привязанном к текущей карте.
11. Система получает подтверждение о вычете суммы со счета актера от вторичного актера.
12. Система выдает в слот для наличных средств запрошенную актером сумму.
13. Система печатает чек, отражающий детали выполненной операции по снятию наличных средств.
«UC-03 Просмотреть новость»
1. Актер инициирует открытие деталей желаемой новости из новостной ленты.
2. Система отображает детали выбранной новости. Может быть расширен UC-04 Откомментировать новость.
Собственно, всё :) Обратите внимание на то, что в последнем шаге указана точка расширения (т. е. точка, в которой актер может перейти на выполнение расширяющего ВИ «Откомментировать новость»), дабы идти в ногу с дополнительной семантикой, которая отражена на диаграмме. Сценарий UC-04, при этом, начнется с шага, который является логическим продолжением шага 2 UC-03: «Актер вводит текст комментария и подтверждает его отправку». Что касается того, как отразить связь включения, то в этом случае включаемый ВИ просто становится шагом включающего ВИ — например, шаг 3 для UC-03: «См. UC-05…» Отражение же в тексте наследования между ВИ оставим за кадром — это уже продвинутое использование юз кейсов и я не хочу нагружать и без того немаленький пост.
Помимо основного бывают еще и альтернативные сценарии (их может быть несколько). Альтернативные сценарии — это второстепенные по отношению к основному сценарии, также приводящие к успешному завершению. В сравнении с базовым сценарием часть шагов или даже все шаги альтернативного сценария выполняются по-иному. При этом ветвление может идти либо со старта ВИ (т. е. начинаться сценарии могут по-разному, но сливаться в дальнейшем), либо наоборот — начаться с одних и тех же шагов, а в дальнейшем разветвиться, либо с комбинацией обоих вариантов, либо полностью идти параллельно и независимо. Альтернативный сценарий — это то, как еще можно выполнить ВИ (например, для другого актера, через другую точку входа, с другими выбранными опциями и т. д.), но при этом все равно успешно его завершить. Критерием альтернативности чаще всего выступает предполагаемая частота использования: то, как актеры будут чаще всего поступать — это базовый сценарий. Остальные — альтернативные.
Давайте дополним ВИ для банкомата одним альтернативным сценарием и допишем следующее:
Альтернативный сценарий а — Актер указывает сумму для снятия вручную
8.1а. Актер выбирает вариант ручного указания желаемой суммы.
8.2а Система предлагает актеру ввести желаемую сумму.
8.3а Актер вводит желаемую сумму и подтверждает ввод.
Что означает такая схема записи?
1) В альтернативном сценарии отличаться от базового сценария будет только один шаг: восьмой шаг базового сценария превращается в три шага в альтернативном. Остальные шаги базового сценария в альтернативном останутся теми же.
2) Сценарий идентифицирован уникально буквой а, а потому свойственные ему шаги будут иметь, с одной стороны, цифру 8 в своем идентификаторе, чтобы показать, что данные шаги заменяют именно шаг 8 базового сценария, а с другой — в них добавлена буква а, чтобы показать принадлежность сценарию а.
Это далеко не единственно верная схема оформления шагов в альтернативных (и исключительных, как мы увидим далее) сценариях. Главное, чтобы целевая аудитория была в курсе выбранного подхода и однозначно понимала, как его трактовать.
Что такое исключительные сценарии? Это сценарии, не приводящие к успешному завершению ВИ. Ошибки системы как по вине, так и не по вине актера, явные отмены операций актером и прочие исключения из красивой цепочки событий. Они крайне важны, т. к. аналитику необходимо их все учесть и продумать в плане требований (для каждого шага из базового и альтернативных сценариев задайте себе/ЗЛ вопрос: что может пойти не так?). А если не продумаете и не донесете до команды, то разработчики этого не реализуют. Как следствие, актер вполне себе может увидеть какой-нибудь аналог голубого экрана ранних версий Windows, интерпретируемый только андроидами. При этом, оставайтесь в рамках системы и ее функциональных требований: падение метеорита на сервер с системой описывать не стоит.
Для примера с просмотром новости исключительных сценариев не наблюдается. Давайте найдем такие сценарии для ВИ банкомата:
Исключительный сценарий б — Актер указал некорректный ПИН-код
5б. Система отображает сообщение о некорректно введенном ПИН-коде. Возврат к шагу 3.
Исключительный сценарий в — В системе отсутствует запрошенная сумма
10в. Система отображает сообщение об отсутствие запрошенной суммы. Возврат к шагу 7.
Кстати, совершенно неюзабельный подход, будь он таким. Я как актер не знаю, какую сумму я могу запросить, и все, что мне остается, это тыкать суммы, пока не нащупаю ту, которая есть в наличии.
Исключительный сценарий г — Вторичный актер недоступен для осуществления запросов
11г. Система отображает информацию о том, что выбранная операция в текущий момент не может быть выполнена.
И тут есть проблема с удобством использования: я как актер уже продвинулся на несколько шагов в плане желаемой операции, но внезапно я не могу ее завершить — я потратил свое время впустую.
Исключительный сценарий д — В системе отсутствует краска или бумага для печати чека
13д. Система отображает информацию о невозможности печати чека.
И тут проблема с юзабилити: вероятно, я не готов был бы снимать наличные без чека. Хорошо бы мне знать о подобном заранее.
Исключительный сценарий е — Актер отменяет операцию
2е-8е. Актер инициирует отмену операции.
9е. Система возвращает актеру карту, извлекая ее из слота для банковских карт.
Проблему юзабилити в этом кейсе, думаю, и сами найдете :)
Прочие дополнительные моменты:
В этом разделе вы можете привести или сослаться на все то прочее, чем вам хотелось бы дополнить описание ВИ. Типовые варианты применения:
- Приведите тут ссылки на все иные ВИ, которые связаны тем или иным отношением с данным ВИ.
- Приведите или сошлитесь на макеты UI, который фигурирует в шагах данного ВИ.
- Перечислите или сошлитесь на все недостающие для полной картины требования к решению. Что тут может быть: нефункциональные требования для данного ВИ (в частности, атрибуты качества — параметры производительности, удобства использования и пр.), детальное описание взаимодействия с внешними интерфейсами, участвующими в ВИ в качестве вторичных актеров (маппинги данных, форматы запросов/ответов и пр.), требования к данным (используемые в ВИ объекты данных и их атрибуты), требования к UI (параметы доступности/видимости компонентов UI, валидации и пр.) и т. д.
Собственно, вот. Теперь объедините все секции в единый набор информации, и у вас получится с некоторыми условностями спецификация требований к решению для выбранного юз кейса. Опишите подобное для всех юз кейсов, плюс дополните построенной ранее диаграммой ВИ — и у вас практически полноценная спецификация требований к системе. Конечно, одной техникой арсенал аналитика не должен ограничиваться, но в контексте поставленных в начале статьи задач варианты использования — это вполне себе классный инструмент. Берите и смело используйте — всего описанного в посте вам должно хватить для абсолютного большинства ситуаций.