Как детализировать ВИ?
Для того, чтобы полностью описать ВИ, можно использовать следующий набор параметров:
- 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. Система отображает список доступных операций с банковской картой.
6. Актер инициирует операцию снятия наличных средств.
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, валидации и пр.) и т. д.
Собственно, вот. Теперь объедините все секции в единый набор информации, и у вас получится с некоторыми условностями спецификация требований к решению для выбранного юз кейса. Опишите подобное для всех юз кейсов, плюс дополните построенной ранее диаграммой ВИ — и у вас практически полноценная спецификация требований к системе. Конечно, одной техникой арсенал аналитика не должен ограничиваться, но в контексте поставленных в начале статьи задач варианты использования — это вполне себе классный инструмент. Берите и смело используйте — всего описанного в посте вам должно хватить для абсолютного большинства ситуаций.
Для того, чтобы полностью описать ВИ, можно использовать следующий набор параметров:
- 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. Система отображает список доступных операций с банковской картой.
6. Актер инициирует операцию снятия наличных средств.
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, валидации и пр.) и т. д.
Собственно, вот. Теперь объедините все секции в единый набор информации, и у вас получится с некоторыми условностями спецификация требований к решению для выбранного юз кейса. Опишите подобное для всех юз кейсов, плюс дополните построенной ранее диаграммой ВИ — и у вас практически полноценная спецификация требований к системе. Конечно, одной техникой арсенал аналитика не должен ограничиваться, но в контексте поставленных в начале статьи задач варианты использования — это вполне себе классный инструмент. Берите и смело используйте — всего описанного в посте вам должно хватить для абсолютного большинства ситуаций.
