Сценарий использования системы примеры

Содержание
  1. Как и зачем писать Use Cases
  2. Что такое Use Case
  3. Текст vs диаграмма/схема
  4. Кому и в каких случаях нужны сценарии
  5. В каких случаях они нужны:
  6. Как их описывать
  7. Важные моменты
  8. Пользовательские сценарии: что это такое, как и для чего их нужно строить
  9. Для чего нужны пользовательские сценарии
  10. Разновидности сценариев
  11. 1. Пользовательские истории
  12. Сценарий использования системы примеры
  13. От потребности к решению: виды требований и способы их описания
  14. Что такое пользовательская история и чем она хороша
  15. Сценарий использования и UML-диаграмма Use Case
  16. Чем User Story отличается от Use case
  17. Диаграмма сценариев использования в процессе разработки ПО
  18. Оценка трудоемкости проекта
  19. Планирование графика работ
  20. Выявление пропущенных требований
  21. «Оглавление» для проектных документов
  22. m_i_kuznetsov
  23. Размышления о разработке программного обеспечения и информационных систем
  24. То, что действительно важно, но чему нигде не учат

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.

Кому и в каких случаях нужны сценарии

— Разработчикам. Очень удобно, когда ветвистое требование описано при помощи основного и альтернативного потока событий. Все четко и понятно: кто, когда и что вызывает, и что получается в результате. В моем последнем проекте менеджер исповедовал подход: минимум описаний, максимум общения. Но для нескольких сложных сценариев разработчики сами просили сделать подробное описание, и юзкейсы отлично подошли.

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс 🙂

— Всей проектной команде. Если сценарий нужно согласовать, а на каждом совещании пара-тройка альтернативных вариантов сценария звучит иначе, поможет строго описанный поток событий.

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

Пример 2. Авторизация пользователя:

Действующие лица Администратор, Система
Цель Изменить статус учетной записи пользователя на «активный».
Предусловие Учетная запись пользователя не активна.

Успешный сценарий:

Важные моменты

— Очевидно, что если Пример 1 можно было безболезненно описать простым текстом, то Пример 2 намного лучше воспринимается в виде сценария. Но если у вас вся функциональность описана в виде юзкейсов, то лучше описывать юзкейсами даже очень простые сценарии, из пары шагов. Пусть ваша спецификация будет в едином стиле.

— Используйте минимальное количество слов и пунктов, необходимых для однозначного понимания сценария. Если юзкейс получается слишком длинный, возможно, лучше будет разбить его на несколько. С очень длинными сценариями, с большим количеством расширений, работать крайне неудобно.

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

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

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

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

Источник

Пользовательские сценарии: что это такое, как и для чего их нужно строить

Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.

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

Прежде чем разработать сценарий, нужно ответить на три вопроса:

1. Кто те люди, что заходят на ваш сайт?

Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.

2. Почему они заходят к вам?

На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.

3. Какие цели при этом преследуют и как их достигают?

Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.

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

Для чего нужны пользовательские сценарии

Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.

Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.

Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.

Разновидности сценариев

Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.

1. Пользовательские истории

Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.

Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.

Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».

Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:

Источник

Сценарий использования системы примеры

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 2 популярные схемы описания требований в Agile-проектах. Читайте далее, чем User story отличается от Use Case, а также как они связаны с UML-диаграммой прецедентов, а также функциональными и нефункциональными требованиями к решению, которые входят в ТЗ по ГОСТ.

От потребности к решению: виды требований и способы их описания

Напомним, руководство к профессиональному своду знаний по бизнес анализу BABOK®Guide выделяет 3 основных вида требований (бизнес, стейкхолдеров и к решению), а также переходные, актуальные на момент трансформации от текущего состояния (as-is) к желаемому (as-to-be). Подробнее об этом мы говорили в отдельной статье. Аналитик плотно работает со всеми видами требований, последовательно трассируя потребности, проблемы и возможности в требования к решению через бизнес-требования и требования заинтересованных сторон (стейкхолдеров).

Если решением является информационная система или программно-аппаратный комплекс, как это бывает в большинстве случаев, то в техническое задание (ТЗ) на его разработку попадают именно требования к решению: функциональные и нефункциональные. Для этого выделяются соответствующие пункты в стандартах по разработке (ISO/IEC/IEEE 29148:2018, ГОСТ 34.602-89, ГОСТ 19.201-78) и спецификации требований к программному обеспечению (Software Requirements specification, SRS) на основе IEEE/ISO/IEC 29148-2011. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом со множеством циклов согласования между Заказчиком и командой реализации. Поэтому, чтобы лучше понять потребности стейкхолдеров и быстрее начать работу над программным продуктом, бизнес-аналитик описывает требования к системе в виде пользовательских историй (user story), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

Что такое пользовательская история и чем она хороша

Обычно user story создаются по шаблонам возможности или ограничения:

Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.

Сценарий использования и UML-диаграмма Use Case

Однако, user story – далеко не единственная схема представления требований, хотя именно она больше всего подходит к описанию требований стейкхолдеров. Также для описания функциональных требований, описывающих поведение проектируемой системы в едином смысловом контексте, применяется инструмент сценариев или вариантов ее использования (Use Case). В этом случае функциональные требования к системе представляются в виде набора функций, объединенных по контексту. Например, Use Case «Запланировать посещение клиента в клинику» может включать следующие функции:

Все эти функции представляют собой прецеденты UML-диаграммы вариантов использования (Use Case), которые связаны различными видами отношений. О том, как разрабатывать подобную UML-диаграмму, мы поговорим в другой раз. А проверить свое знание основ UML вы можете, пройдя бесплатный интерактивный тест прямо на нашем сайте.

ucs1UML-диаграмма Use Case

Бизнес-логика выполнения каждого прецедента UML-диаграммы Use Case обычно детализируется в диаграммах деятельности, реже в диаграммах последовательности и состояний. Однако, сценарий использования не ограничивается только графической UML-схемой, а также включает тестовое описание по следующей структуре:

Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий» и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.

Чем User Story отличается от Use case

Подводя итог описанию рассмотренных схем представления требований, подчеркнем сходства и отличия User Story и Use case:

На практике обе схемы представления требований могут пересекаться и использоваться совместно, поскольку все они в итоге трассируются в функциональные и нефункциональные требования к решению.

ucs2User Story, Use Case и функциональные требования

Подробнее узнать о сходствах, отличиях, достоинствах и недостатках, примерах применения Use Case и User Story, а также научиться описывать требования по этим схемам представления вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Источник

Диаграмма сценариев использования в процессе разработки ПО

image loaderУже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.

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

Во-первых, что такое сценарий использования? Сценарий использования – это связный рассказ о поведении системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Кто-то или что-то может быть пользователем системы, это может быть какая-то информационная система или устройство. И этот кто-то или что-то называется Действующим лицом (ДЛ). А сам сценарий использования представляет собой последовательность шагов, которые описывают действия ДЛ и реакцию системы на них.

Например, сценарий регистрации на каком-нибудь сайте может выглядеть вот так:

Но въедливый читатель может справедливо возразить, что в разработку такой сценарий отдавать нельзя. И он будет прав! Мы ведь сейчас посмотрели на систему с высоты, наверно, 5-этажного дома, когда общее поведение уже понятно, но детальных требований ещё нет. Поэтому сценарий использования должен быть, как минимум, дополнен альтернативными потоками выполнения (то что представлено выше, называется основной поток и описывает действия системы, когда все идет как надо). Альтернативные потоки – это потоки, в которых описывается реакция системы на ошибочные действия пользователя или исключительные ситуации, либо же случаи альтернативных действий пользователя, если он захотел, например, зарегистрироваться с помощью аккаунта в социальной сети. Также документ со сценарием использования можно дополнить деталями пользовательского интерфейса, правилами валидации данных, различными бизнес-правилами и сообщениями об ошибках. А вот нефункциональные требования обычно описываются в отдельном документе, так как они обычно применимы ко всей системе целиком, а не к конкретным СИ.

Если же подняться ещё выше и посмотреть на систему с большей «высоты», то она будет выглядеть как набор услуг, предоставляемых системой пользователю (сценарии использования также можно рассматривать как высокоуровневые требования к системе). Тут мы приходим к тому, что неплохо бы было визуализировать эти требования, и для этого отлично подходит соответствующая диаграмма UML: диаграмма сценариев использования. Кусочек диаграммы показан ниже. Она состоит из действующих лиц, сценариев использования и различных связей между ними.

image loader

Для разработчиков и тестировщиков она, на первый взгляд, несет ещё меньше пользы, чем сами сценарии использования. Но ведь и предназначена она для другого!

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

Я обычно использую диаграмму СИ для решения следующих задач:

Оценка трудоемкости проекта

Как показывает опыт и практика, оценка получается тем точнее, чем детальнее выделен список предстоящих работ. Ведь действительно, задачу «написать статью» оценить гораздо сложнее, чем задачу «найти 5 картинок для иллюстраций». Так вот, сценарии использования являются первой итерацией разбивки системы на отдельные элементы. Более того, эти элементы обладают хорошей связностью (в данном случае – функциональная) и могут быть оценены отдельно друг от друга. Если этого недостаточно, то уже каждый СИ можно декомпозировать на основной/альтернативные потоки или даже задачи, которые необходимо выполнить программисту для реализации отдельного сценария.

Здесь довольно часто также проявляется возможность повторного использования ранее созданных артефактов. Например, если для системы требуется функционал регистрации пользователей, то плюс/минус он будет работать одинаково во многих системах, что при оценке сразу же снижает степень неопределенности.

Даже существует специальный способ оценки, основанный на СИ – Use Case Points. В этом случае выделяются действующие лица и сценарии, у них по определенным правилам определяется сложность, задаются некоторые поправочные коэффициенты, учитывающие профессионализм команды и сложность предметной области, и на выходе появляется готовая оценка. То есть, к оценке, в идеале, даже не надо привлекать разработчиков и тестировщиков.

Планирование графика работ

В проектах с фиксированном бюджетом обычно явно выделяются последовательные стадии проектирования, разработки и тестирования (как в водопадной модели). Но в реальности тестирование уже частично начинается даже до завершения стадии проектирования, так как тестировщики подключатся к ревью разработанных требований и начинают писать тест-дизайн. И если для аналитика и, скажем, архитектора, составить график работ не составляет большого труда, так как активности этих ролей начинаются вместе со стартом проекта, то определить, когда и на какую задачу стоит подключать тестировщиков с разработчиками, уже становится сложнее. Действительно, ведь входными данными для них являются подготовленные и согласованные документы с требованиями. И для решения этой проблемы опять хорошо подходят СИ. Так как каждый сценарий содержит в себе завершенное описание какого-то процесса, то их проще согласовывать с заказчиками и, соответственно, можно довольно точно установить в план-графике ключевые точки согласования документов требований. А уже от этих точек планировать работу остальной команды.

Выявление пропущенных требований

Не удивительно, что когда заказчик каким-то образом озвучивает требования к будущей системе, то он в своем описании сконцентрирован именно на полезном функционале и никак не упоминает, например, функции настройки системы или функции управления учетными записями пользователей, хотя без них система не будет полноценно работать. Очень часто после получения таких требований команда начинает выполнять оценку. У меня на практике были случаи, когда команда сразу бросалась в бой и оценивала то, что описал заказчик, оставляя за бортом неозвученные, но, тем не менее, обязательные функции системы.

Также бывает и другая ситуация, когда в описании системы присутствуют требования о том, что в процессе работы пользователи должны создавать какие-то сущности. В подавляющем большинстве случаев, к таким сущностям применимы все CRUD (Create, Read (или также встречается расшифровка Retrieve), Update, Delete) операции, про которые тоже иногда забывают. В чем же здесь польза модели СИ? А как раз в графическом представлении требований. Когда глаз охватывает всю картинку, то гораздо проще заметить недостающие элементы, чем когда требования сформулированы обычным текстом.

«Оглавление» для проектных документов

Очень часто заказчик просит вместе с системой передавать комплект проектной документации. У себя в компании мы пишем проектную документацию в виде сценариев использования. Если же заказчик требует документы по ГОСТу, то все равно сперва пишутся сценарии использования, а затем уже на их основе формируются ГОСТовские документы.

У нас используется, как минимум, два подхода к документированию: когда каждый СИ описывается в отдельном документе, и когда в одном документе описываются сразу несколько СИ, относящихся к одной подсистеме. Часто тот или иной подход определяется, исходя из принятого процесса или привычек заказчика.

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

Источник

userinfo v8m_i_kuznetsov

Размышления о разработке программного обеспечения и информационных систем

То, что действительно важно, но чему нигде не учат

72091 original

Что такое сценарии использования

Сценарий использования – описание поведения системы в процессе выполнения ею определённой операции. Под операцией часто понимают выполнение системой команды или запроса пользователя, но ограничиваться только взаимодействия системы с пользователями было бы крайне неверно.

Обратите внимание, что пользовательская история, по сути, также является неким обобщённым сценарием использования системы. В этом первое достоинство сценариев по сравнению с требованиями, излагаемыми в спецификации. Это достоинство часто используется при переходе от пользовательской истории к требованиям, когда спецификация сценариев является переходным звеном, возникающим в ходе систематизации пользовательских историй.

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

Превращение пользовательских историй в сценарии

Как было сказано выше, пользовательская история – это обобщённый сценарий использования. Важной чертой истории является то, что история описывается пользователем, когда системы ещё нет. Совокупность пользовательских историй как бы определяет примерный облик будущей системы, её прототип.

Но при переходе от историй к сценариям использования нам нужно выполнить переход от прототипа к реальной системе, и описываемые сценарии использования должны быть реализованы в реальном железе и программном коде.
Много ли вы видели концепт-каров, воплощённых затем в реальный автомобиль? Часто новый автомобиль отличается от исходного концепта так сильно, что проследить связь не всегда удаётся. Ниже приведён один из таких примеров от лидеров автопрома – концерна Toyota. Вот уж кто денег на ветер не бросает и точно знает, что делает. Но разница видна сразу.

71897 original

Такая же ситуация и с переходом от концептуальной информационной системы к реальной: картина системы не может не измениться. Это важное свойство любого процесса реализации информационной системы, которое не следует недооценивать.

Итак, мы имеем систематизированный набор пользовательских историй. Мы решили не идти простым путём сваливания ответственности на архитектора, а взять ответственность на себя и попытаться разобраться, как будет себя вести система в динамике. Соответственно, мы отказались от спецификации требований в пользу динамичной модели сценариев использования.

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

При рассмотрении каждой функциональности следует сначала найти так называемую базовую историю. Как правило, она позволяет достичь результата самым оптимальным способом. «Оптимальность» тут следует понимать в контексте потребностей пользователей и бизнеса. В одном случае оптимальность будет связана со скоростью выполнения операции, в другом – с точностью получаемого результата, в третьем – с требуемыми ресурсами и т.д.

Последовательность действий системы (алгоритм выполнения операции), описанная в базовой истории, называют базовым путём выполнения данной операции.

Часто бывает, что при поиске базовой истории оказывается, что есть одна и та же последовательность действий, изложенная в разных историях, но не описанная отдельной историей. Наверное, следует выделить такую последовательность в отдельную историю и, возможно, в отдельный функциональный пакет.

Нетрудно догадаться, что остальные истории либо дублируют базовую, либо расширяют базовую историю для некоторых отдельных случаев, либо описывают альтернативные варианты выполнения операции для случаев изменения исходных данных или/и нарушения состояния системы в ходе операции, либо же просто не оптимальны и подразумевают никому не нужные действия. Истории, которые попадают в первую и последнюю группы, нужно отбросить.

Ещё на стадии систематизации историй мы старались решить конфликты и иные проблемы набора историй. Но не лишним будет ещё раз проверить, что у нас нет взаимоисключающих историй, что все истории реализуемы, что истории не касаются реализации системы, а лишь описывают мотивацию пользователей и т.д.

Переход к вариантам использования

Собственно, при создании модели базовая история становится базовым сценарием автоматически. Затем на диаграмму сценариев выводятся расширения и альтернативы.

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

При переходе к сценариям важно сохранить параметры историй, в частности, приоритеты реализации. Иногда приоритеты задаются цветовым кодированием. Однако такая нотация ограничена, т.к. при печати цвет не всегда передаётся, а само кодирование не всегда полезно. Лучше использовать стереотипы.

Чаще цветовое кодирование используется при сопровождении модели, когда удалённые сценарии помечаются одним цветом, новые – другим, а изменённые – третьим. Также и в описании сценария новые, изменённые и удалённые формулировки помечаются теми же цветами.

Применение сценариев использования

Модель сценариев использования – очень гибкий инструмент анализа и проектирования. Из-за этого эту модель предпочтительнее применять при использовании гибких методологий, при больших объёмах требований или в командах с большим количеством взаимодействий.

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

Отдельно нужно упомянуть о важнейшей роли сценариев при проектировании, реализации и тестировании разрабатываемой системы. Достаточно указать, что сценарии лежат в центре представления архитектуры Филиппа Крачтена («модель 4+1»).

Источник

Adblock
detector
Действующие лица Пользователь, Система
Цели Пользователь: авторизоваться в системе и начать работать;
Система: идентифицировать пользователя и его права.