Что такое сценарии функциональной модели

В прошлый раз мы выяснили ограничения применимости спецификации требований . Сегодня поговорим об альтернативе - модели сценариев использования. Что такое сценарии использования Сценарий использования описание поведения системы в процессе выполнения ею определённой операции. Под операцией…

В прошлый раз мы выяснили ограничения применимости спецификации требований. Сегодня поговорим об альтернативе — модели сценариев использования.

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

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

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

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

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

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

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

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

С чего начать?

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

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

Базовая история

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

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

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

Фильтрация историй

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

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

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

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

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

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

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

Каждый сценарий использования должен удовлетворять тем же параметрам, что и обычное требование, но изменённые для описания поведения системы, а не её статичных характеристик:

  • Единичность — сценарий описывает один и только один вариант поведения системы.

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

  • Непротиворечивость — сценарий не противоречит другим сценариям.

  • Связность (последовательность) – сценарий дополняет другие сценарии и составляет с ними единую картину будущей системы.

  • Атомарность — сценарий нельзя разделить на более мелкие сценарии без потери конкретного полезного результата.

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

  • Актуальность — сценарий не стал устаревшим с течением времени.

  • Реализуемость — сценарий может быть реализован в рамках проекта.

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

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

  • Проверяемость — полнота реализации сценария может быть проверена на каждом шаге сценария.

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

  • условия доступа к вызову сценария (кто/что имеет право вызвать сценарий);

  • значения показателей качества, предъявляемые к исходным данным, и условия выполнения сценария;

  • значения показателей качества, предъявляемые к каждому шагу сценария, включая условия завершения шага;

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

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

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

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

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

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

P.S. В довесок ссылка на статью Александра Шамрая «Советы для написания хороших сценариев использования». Однако следует иметь в виду, что в этой статье речь идёт о сценариях взаимодействия пользователя с системой, несколько подменяя определение сценария, введённое в стандарте UML, и при этом искажая суть сценария. Однако, если иметь в виду этот момент, то остальное описание будет весьма полезным.

Источник

Аннотация: Классификация требований, их спецификация в форме диаграмм вариантов использования. Сценарии вариантов использования, их графическая интерпретация. Применение шаблонов сценариев при разработке диаграмм вариантов использования. Примеры написания текста сценария. Рекомендации по написанию вариантов использования.

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

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

Требование (requirement) — желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

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

  • функциональные требования (Functionality)
  • требования удобства использования (Usability)
  • требования надежности (Reliability)
  • требования производительности (Performance)
  • требования возможности сопровождения (Supportability)

При этом символом «+» обозначены дополнительные условия, к которым относятся:

  • проектные ограничения
  • требования управления системой
  • требования к графическому интерфейсу пользователя
  • физические требования
  • юридические требования

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

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

Сценарий (scenario) — определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.

В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев. Один из таких шаблонов рассматривается ниже и может быть рекомендован читателям для применения на начальных этапах концептуального моделирования (табл. 4.1).

Таблица
4.1.
Шаблон для написания сценария отдельного варианта использования

Главный раздел Раздел «Типичный ход событий» Раздел «Исключения» Раздел «Примечания»
Имя варианта использования Типичный ход событий, приводящий к успешному выполнению варианта использования Исключение № 1 Примечания № 1
Актеры Исключение № 2 Примечания № 2
Цель … …
Краткое описание
Тип
Ссылки на другие варианты использования Исключение № N Примечания № N

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

Построение диаграммы вариантов использования — самый первый этап процесса объектно-ориентированного анализа и проектирования, цель которого — представить совокупность функциональных требований к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования и дополнительных сценариев может представлять собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип <<useCaseModel>>.

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

Источник

Функциональное моделирование на базе стандарта IDEF0. Функционально-стоимостной анализ. Методические рекомендации.

1. Область применения

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

Методические рекомендации могут использоваться при анализе функциональных моделей. Методические рекомендации ориентированы на применение программного продукта IDEF0/EMTool.

6

Функциональное моделирование на базе стандарта IDEF0. Функционально-стоимостной анализ. Методические рекомендации.

2. Определения

Драйвер – Центр затрат –

Ценность – субъективно воспринимаемая покупателем совокупность потребительских качеств продукта или услуги.

Вспомогательный процесс – процесс, характеризующийся производством продукции, используемой в качестве «механизма» или «управления» для других процессов предприятия.

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

Процессное управление – продукция определенного процесса, используемая в качестве «управления» в анализируемом процессе.

7

Функциональное моделирование на базе стандарта IDEF0. Функционально-стоимостной анализ. Методические рекомендации.

3. Сценарий проведения ФСА

ФСА представляет собой процесс сбора и обработки информации, имеющий, как правило, несколько этапов:

1.Построение функциональной модели. На этом этапе происходит сбор информации о процессах предприятия, построение и утверждение функциональной модели. При построении функциональной модели следует использовать «Функциональное моделирование на базе стандарта IDEF0. Методические рекомендации». Результатом выполнения этапа является функциональная модель процессов.

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

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

4.Анализ результатов и выработка рекомендаций. Проводиться анализ полученных на предыдущих этапах информации и формируются рекомендации по усовершенствованию процессов.

Укрупненная схема проведения ФСА

Построение

функциональной

модели

Перенос стоимостей

Анализ

результатов и

на функциональную

выработка

модель

рекомендаций

Собирание

стоимостей

8

Функциональное моделирование на базе стандарта IDEF0. Функционально-стоимостной анализ. Методические рекомендации.

4.Построение функциональной модели

5.1Процесс построения функциональной модели рассмотрен в документе «Функциональное моделирование на базе стандарта IDEF0. Методические рекомендации».

5.2Локализация процессов. Для проведения дальнейшего анализа необходимо локализовать процессы функциональной модели. Следует составить перечень функций, связанных причинно-следственными отношениями. Эти функции должны располагаться на самом низком уровне иерархии, но не обязательно на одном и том же. Работу следует вести, используя определение процесса, данное в «Функциональное моделирование на базе стандарта IDEF0. Методические рекомендации».

5.3Составления глоссария «механизмов» и «управлений». Глоссарий

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

5.4Определение последовательности рассмотрения процессов. Определять последовательность рассмотрения процессов следует только в том случае, если продукция одного или нескольких процессов используется в качестве «управления» или «механизма»

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

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

—Процесс подготовки дневных планов выпуска продукции (Процесс 1);

—Процесс подготовки оснастки и инструментов (Процесс 2);

—Процесс выпуска продукции (Процесс 3).

Очевидно, что планы выпуска продукции являются управлением для Процесса 2 и Процесса 3. Процесс 2 имеет продукцию, которая используется в Процессе 3 в качестве механизма. Следовательно, очередность рассмотрения процессов:

—Процесс 1 – определяется стоимость «управления», которая не может быть получена из бухгалтерской системы;

—Процесс 2 – определяется стоимость «механизмов», используемых в Процессе 3;

—Процесс 3 – определяется стоимость функций при реализации продукции.

В данном примере для определения стоимости функций процесса выпуска продукции (Процесс 3) необходимо определить себестоимость продукции вспомогательных процессов (Процесс 1 и Процесс 2).

9

Соседние файлы в папке ОРИЕНТСОФТ

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

Анна Вичугова | Анна Гасраталиева

Алгоритм описания функциональных требований к системе в формате Use Case

Существуют разные формы представления функциональных требований: пользовательская история (user story), каноническая форма с привязкой к CRUDL-операциям и модели данных (классический формат описания требований), а также описание сценариев использования (Use Case).

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

В официальной литературе на русский язык Use Case принято переводить как вариант использования (сокращённо ВИ), хотя в разговорной речи и проектных документах достаточно часто употребляется ещё и транслитерация термина Use Case, то есть говорят и пишут юскейс.

В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.

Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, «Купить Товар» — Use case, и у него есть Use case scenario (пошаговое описание того, как именно купить товар: 1. Выбрать товар, 2. Добавить в корзину, 3. Оплатить).

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

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

Итак, Use case (UC) — это популярная форма представления функциональных требований к ПО в виде пошагового сценария взаимодействия актора (пользователя или внешнего сервиса) с проектируемой системой, включая описание метаданных этого взаимодействия: области применения, предусловия, триггеры, постусловия, релевантные бизнес-правила и пр.

Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.

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

Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:

  1. Определить Акторов — тех, кто взаимодействует с системой
  2. Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
  3. Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
  4. Для каждого важного юскейса определить контекст применения, конечную цель и результат
  5. Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
  6. Дополнить основной поток расширениями, исключениями и циклами
  7. Собрать воедино результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой

Теперь давайте рассмотрим каждый шаг поподробнее.

1. Определить акторов, которые взаимодействуют с системой

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

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

2. Для каждого актора составить список задач, которые он сможет решить с помощью системы

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

Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.

Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.

Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).

Обычно для продуктов и проектов в сфере B2C исходные данные для этого извлекаются из изучения интересов, потребностей и пользовательского опыта людей (клиентов, экспертов предметной области) и конкурентного анализа, а также CJM-карты.

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

Давайте сформируем реестр юскейсов. Например, ранее для пользователя мобильного телефона мы определи функциональные возможности «Сделать звоноки» и «Отправить СМС». Они реализуют единую пользовательскую потребность: «Связаться с другим человеком», поэтому их можно объединить в один юскейс.

Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».

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

3. Для каждого UC определить его приоритет

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

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

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

  • Must — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
  • Should — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
  • Could — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
  • Would — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4

В нашем примере с мобильным телефоном приоритизировать юскейсы можно так, как показано в таблице 2.

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

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

4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат

Это можно оформить в виде списка или таблицы, например в Notion:

5. Раскрыть содержание основного потока каждого юскейса высокого приоритета в виде пользовательского сценария

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

Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.

Как может выглядеть черновик сценария основного потока юскейса:

1. Пользователь даёт команду совершить звонок
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номер абонента
4. Система убеждается в корректности указанного номера телефона
5. Система вызывает абонента с указанным номером телефона
6. Система убеждается, что звонок начался
7. Система передаёт голос собеседников в ходе разговора

Для наглядности можно нарисовать эту линейную последовательность шагов в виде простого процесса в нотациях EPC, BPMN (рис.1), UML activity или sequence, а также блок-схемы алгоритма по ГОСТ 19.701−90.

Последовательность шагов в виде BPMN-диаграммы

На практике подавляющая часть сценариев описывается только текстовым описанием. Пример такого описания мы разберём с вами ниже.

6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами

На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.

Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).

Расширенная BPMN-диаграмма юскейса с исключениями и альтернативными потоками

7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой

На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:

  • Имя
  • Приоритет
  • Область действия
  • Контекст
  • Актор
  • Цель
  • Предусловия
  • Результат (постусловие)
  • Основной поток
  • Расширения или альтернативные потоки
  • Бизнес-правила

Давайте разберем каждый элемент этой структуры поподробнее.

Эту структуру можно представить в текстовом виде или, для наглядности, в виде таблицы. Давайте завершим описание этого юскейса так, как мы делаем это на реальных проектах, то есть полностью опишем happy path и альтернативные сценарии.

Пример 1. UC «Сделать Звонок»

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

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

Как структурировать UC из набора
исходных ФТ

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

Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.

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

  • FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
  • FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
  • FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

Формируем описание в формате UC, применяя алгоритм:

Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.

Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).

Исходная UML-диаграмма use case

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

Упрощённая UML-диаграмма use case

Давайте также сопоставим получившиеся юскейсы и функциональные требования в таблице ниже.

При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.

Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.

Реестр вариантов использования:

Шаг 3. Определить приоритеты системных юскейсов

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

Шаги 4−7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см. ниже). По аналогии будет описан и UC «Заключить Договор».

Пример 2. UC «Оплатить Договор»

Для нашего примера вариант использования «Оплатить Договор» может выглядеть так:

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

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

Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.

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

Пример 3. UC «Обновить Анкету»

Достоинства и недостатки UC как формы представления требований

Основными преимуществами UC являются следующие:

  • Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
  • Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ;
  • Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
  • Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
  • UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось

Обратной стороной этих достоинств являются следующие недостатки:

  • Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
  • Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
  • На детальную проработку каждого UC уходит много времени. Например, у меня это занимает в среднем от 30 минут; добиться существенного повышения скорости работы можно за счёт повторного использования типовых юскейсов (опытный аналитик или отдел могут создать библиотеку своих юскейсов)
  • Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)

Откуда взялся такой формат как Use Case

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

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

  • FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору

В 1986 году Ивар Якобсон (шведский учёный, который вместе с Гради Бучем и Джеймсом Рамбо стоял у истоков ООП и UML) предложил альтернативную форму представления функциональных возможностей системы. Вместо описания функциональных требований к системе в виде отдельных функций Якобсон предложил объединить их по контексту, а затем превратить в набор вариантов использования (ВИ), который будет обеспечивать полноту и неизбыточность требований.

Якобсон обнаружил, что отдельные системные ФТ обычно не представляют большой самостоятельной ценности для заказчика, менеджера, пользователя, так как являются слишком мелкими единицами функциональности. Подход Якобсона позволил вместо сотен-тысяч системных функций применять единицы-десятки юскейсов, что гораздо удобнее в целях управления, планирования и сдачи ИТ-продукта/системы. Кроме того, он хорошо стыкуется с задачами тестирования и создания пользовательской документации. Подробнее об этом см в статье.

В 2001 году Алистер Коберн, эксперт в разработке ПО, расширил и уточнил идеи Якобсона, выпустив книгу «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases). Книга получилась достаточно подробной, содержащей множество примеров. Помимо техник описания самих UC, работа Коберна включает также связанные вопросы о контексте, границах и основных компонентах проектируемой системы, то есть так называемый scope системы.

Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.

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

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

Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.

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

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

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

Анна Вичугова

  • Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
  • Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
  • Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
  • Сертифицированный специалист и администратор СЭД Directum (2011

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Анна Гасраталиева

Системный аналитик, выпускающий редактор Systems. Education

Системный аналитик, выпускающий редактор Systems. Education

Профессиональные интересы: телекоммуникации, интеграции, управление задачами, управление людьми, обучения

Источник

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

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

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

  1. Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

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

  1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

Сценарии использования включают в себя следующие разделы: 

  1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

  1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Пользователь

Система

Какое физическое действие произвел пользователь? 

Как отреагировала система?

Нажимает “Добавить в корзину”

Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину. 

Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину”

Пользователь нажимает “перейти в корзину”

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

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

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

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

Пользователь

Система

Какое физическое действие произвел пользователь? 

Как отреагировала система?

Пользователь нажал кнопку “Зарегистрироваться” 

Система вывела форму регистрации, поле “email”

Пользователь вводит данные в поле “email”

3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации

Если данные не прошли проверку валидации, запускается альтернативный сценарий №1. 

Система производит поиск введенных данных “email”  по учетным записям в системе. 

Учетных записей с такими данными “email” не найдено. 

Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2

Система отправляет пользователю код подтверждения на email

Система выводит пользователю поле “код подтверждения”

Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. — обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный. 

Пользователь вводит корректный код подтверждения в поле “код подтверждения” 

Система производит проверку кода подтверждения. Код введен верно. 

Пользователь зарегистрирован. 

Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения” 

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

  1. Система выводит информер  с указанием запрещенных символов.

  2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Источник

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area.[1]

Example of a function model of the process of «Maintain Reparable Spares» in IDEF0 notation.

A function model, similar with the activity model or process model, is a graphical representation of an enterprise’s function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.[2]

History[edit]

The function model in the field of systems engineering and software engineering originates in the 1950s and 1960s, but the origin of functional modelling of organizational activity goes back to the late 19th century.

In the late 19th century the first diagrams appeared that pictured business activities, actions, processes, or operations, and in the first half of the 20th century the first structured methods for documenting business process activities emerged. One of those methods was the flow process chart, introduced by Frank Gilbreth to members of American Society of Mechanical Engineers (ASME) in 1921 with the presentation, entitled “Process Charts—First Steps in Finding the One Best Way”.[3] Gilbreth’s tools quickly found their way into industrial engineering curricula.

The emergence of the field of systems engineering can be traced back to Bell Telephone Laboratories in the 1940s.[4] The need to identify and manipulate the properties of a system as a whole, which in complex engineering projects may greatly differ from the sum of the parts’ properties, motivated various industries to apply the discipline.[5] One of the first to define the function model in this field was the British engineer William Gosling. In his book The design of engineering systems (1962, p. 25) he stated:

A functional model must thus achieve two aims in order to be of use. It must furnish a throughput description mechanics capable of completely defining the first and last throughput states, and perhaps some of the intervening states. It must also offer some means by which any input, correctly described in terms of this mechanics, can be used to generate an output which is an equally correct description of the output which the actual system would have given for the input concerned. It may also be noted that there are two other things which a functional model may do, but which are not necessary to all functional models. Thus such a system may, but need not, describe the system throughputs other than at the input and output, and it may also contain a description of the operation which each element carries out on the throughput, but once again this is not.[6]

One of the first well defined function models, was the functional flow block diagram (FFBD) developed by the defense-related TRW Incorporated in the 1950s.[7] In the 1960s it was exploited by the NASA to visualize the time sequence of events in a space systems and flight missions.[8] It is further widely used in classical systems engineering to show the order of execution of system functions.[9]

Functional modeling topics[edit]

Functional perspective[edit]

In systems engineering and software engineering a function model is created with a functional modeling perspective. The functional perspective is one of the perspectives possible in business process modelling, other perspectives are for example behavioural, organisational or informational.[10]

A functional modeling perspective concentrates on describing the dynamic process. The main concept in this modeling perspective is the process, this could be a function, transformation, activity, action, task etc. A well-known example of a modeling language employing this perspective is data flow diagrams.

The perspective uses four symbols to describe a process, these being:

  • Process: Illustrates transformation from input to output.
  • Store: Data-collection or some sort of material.
  • Flow: Movement of data or material in the process.
  • External Entity: External to the modeled system, but interacts with it.

Now, with these symbols, a process can be represented as a network of these symbols. This decomposed process is a DFD, data flow diagram.

Example of functional decomposition in a systems analysis.

In Dynamic Enterprise Modeling a division is made in the Control model, Function Model, Process model and Organizational model.

Functional decomposition[edit]

Functional decomposition refers broadly to the process of resolving a functional relationship into its constituent parts in such a way that the original function can be reconstructed from those parts by function composition. In general, this process of decomposition is undertaken either for the purpose of gaining insight into the identity of the constituent components, or for the purpose of obtaining a compressed representation of the global function, a task which is feasible only when the constituent processes possess a certain level of modularity.

Functional decomposition has a prominent role in computer programming, where a major goal is to modularize processes to the greatest extent possible. For example, a library management system may be broken up into an inventory module, a patron information module, and a fee assessment module. In the early decades of computer programming, this was manifested as the «art of subroutining,» as it was called by some prominent practitioners.

Functional decomposition of engineering systems is a method for analyzing engineered systems. The basic idea is to try to divide a system in such a way that each block of the block diagram can be described without an «and» or «or» in the description.

This exercise forces each part of the system to have a pure function. When a system is composed of pure functions, they can be reused, or replaced. A usual side effect is that the interfaces between blocks become simple and generic. Since the interfaces usually become simple, it is easier to replace a pure function with a related, similar function.

Functional modeling methods[edit]

The functional approach is extended in multiple diagrammic techniques and modeling notations. This section gives an overview of the important techniques in chronological order.

Function block diagram[edit]

Functional block diagram of the attitude control and maneuvering electronics system of the Gemini spacecraft. June 1962.

A functional block diagram is a block diagram, that describes the functions and interrelationships of a system. The functional block diagram can picture:[11]

  • Functions of a system pictured by blocks
  • Input of a block pictured with lines, and
  • Relationships between 9 functions
  • Functional sequences and paths for matter and or signals[12]

The block diagram can use additional schematic symbols to show particular properties.

Specific function block diagram are the classic functional flow block diagram, and the Function Block Diagram (FBD) used in the design of programmable logic controllers.

Functional flow block diagram[edit]

The functional flow block diagram (FFBD) is a multi-tier, time-sequenced, step-by-step flow diagram of the system’s functional flow.[14]
The diagram is developed in the 1950s and widely used in classical systems engineering. The functional flow block diagram is also referred to as Functional Flow Diagram, functional block diagram, and functional flow.[15]

Functional flow block diagrams (FFBD) usually define the detailed, step-by-step operational and support sequences for systems, but they are also used effectively to define processes in developing and producing systems. The software development processes also use FFBDs extensively. In the system context, the functional flow steps may include combinations of hardware, software, personnel, facilities, and/or procedures.

In the FFBD method, the functions are organized and depicted by their logical order of execution. Each function is shown with respect to its logical relationship to the execution and completion of other functions. A node labeled with the function name depicts each function. Arrows from left to right show the order of execution of the functions. Logic symbols represent sequential or parallel execution of functions.[16]

HIPO and oPO[edit]

HIPO for hierarchical input process output is a popular 1970s systems analysis design aid and documentation technique[17] for representing the modules of a system as a hierarchy and for documenting each module.[18]

It was used to develop requirements, construct the design, and support implementation of an expert system to demonstrate automated rendezvous. Verification was then conducted systematically because of the method of design and implementation.[19]

The overall design of the system is documented using HIPO charts or structure charts. The structure chart is similar in appearance to an organizational chart, but has been modified to show additional detail. Structure charts can be used to display several types of information, but are used most commonly to diagram either data structures or code structures.[18]

N2 Chart[edit]

Figure 2. N2 chart definition.[20]

The N2 Chart is a diagram in the shape of a matrix, representing functional or physical interfaces between system elements. It is used to systematically identify, define, tabulate, design, and analyze functional and physical interfaces. It applies to system interfaces and hardware and/or software interfaces.[14]

The N2 diagram has been used extensively to develop data interfaces, primarily in the software areas. However, it can also be used to develop hardware interfaces. The basic N2 chart is shown in Figure 2. The system functions are placed on the diagonal; the remainder of the squares in the N × N matrix represent the interface inputs and outputs.
[20]

Structured Analysis and Design Technique[edit]

Structured Analysis and Design Technique (SADT) is a software engineering methodology for describing systems as a hierarchy of functions, a diagrammatic notation for constructing a sketch for a software application. It offers building blocks to represent entities and activities, and a variety of arrows to relate boxes. These boxes and arrows have an associated informal semantics.[21] SADT can be used as a functional analysis tool of a given process, using successive levels of details. The SADT method allows to define user needs for IT developments, which is used in industrial Information Systems, but also to explain and to present an activity’s manufacturing processes, procedures.[22]

The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company. These functions fulfill the objectives of a company, such as sales, order planning, product design, part manufacturing, and human resource management. The SADT can depict simple functional relationships and can reflect data and control flow relationships between different functions. The IDEF0 formalism is based on SADT, developed by Douglas T. Ross in 1985.[23]

IDEF0[edit]

IDEF0 is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, re-engineering, and integration of information systems; business processes; or software engineering analysis.[24] It is part of the IDEF family of modeling languages in the field of software engineering, and is built on the functional modeling language building SADT.

The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system.[25] It was derived from the established graphic modeling language structured analysis and design technique (SADT) developed by Douglas T. Ross and SofTech, Inc. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.[1] The US Air Force commissioned the SADT developers to develop a function model method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.[25]

Axiomatic design[edit]

Axiomatic design is a top down hierarchical functional decomposition process used as a solution synthesis framework for the analysis, development, re-engineering, and integration of products, information systems, business processes or software engineering solutions.[26] Its structure is suited mathematically to analyze coupling between functions in order to optimize the architectural robustness of potential functional solution models.

[edit]

In the field of systems and software engineering numerous specific function and functional models and close related models have been defined. Here only a few general types will be explained.

Business function model[edit]

A Business Function Model (BFM) is a general description or category of operations performed routinely to carry out an organization’s mission. They «provide a conceptual structure for the identification of general business functions».[27] It can show the critical business processes in the context of the business area functions. The processes in the business function model must be consistent with the processes in the value chain models. Processes are a group of related business activities performed to produce an end product or to provide a service. Unlike business functions that are performed on a continual basis, processes are characterized by the fact that they have a specific beginning and an end point marked by the delivery of a desired output. The figure on the right depicts the relationship between the business processes, business functions, and the business area’s business reference model.[28]

Business Process Model and Notation[edit]

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is currently maintained by the Object Management Group since the two organizations merged in 2005. The current version of BPMN is 2.0.[29]

The Business Process Model and Notation (BPMN) specification provides a graphical notation for specifying business processes in a Business Process Diagram (BPD).[30] The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly BPEL4WS.[31]

Business reference model[edit]

This FEA Business reference model depicts the relationship between the business processes, business functions, and the business area’s business reference model.

A Business reference model is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency. In enterprise engineering a business reference model is part of an Enterprise Architecture Framework or Architecture Framework, which defines how to organize the structure and views associated with an Enterprise Architecture.

A reference model in general is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that perform them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area’s business reference model. These reference model can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

Operator function model[edit]

The Operator Function Model (OFM) is proposed as an alternative to traditional task analysis techniques used by human factors engineers. An operator function model attempts to represent in mathematical form how an operator might decompose a complex system into simpler parts and coordinate control actions and system configurations so that acceptable overall system performance is achieved. The model represents basic issues of knowledge representation, information flow, and decision making in complex systems. Miller (1985) suggests that the network structure can be thought of as a possible representation of an operator’s internal model of the system plus a control structure which specifies how the model is used to solve the decision problems that comprise operator control functions.[32]

See also[edit]

  • Bus Functional Model
  • Business process modeling
  • Data model
  • Enterprise modeling
  • Functional Software Architecture
  • Polynomial function model
  • Rational function model
  • Scientific modeling
  • Unified Modeling Language
  • View model

References[edit]

Public Domain This article incorporates public domain material from the National Institute of Standards and Technology.

Public Domain This article incorporates public domain material from Operator Function Model (OFM). Federal Aviation Administration.

  1. ^ a b FIPS Publication 183 Archived 2009-02-27 at the Wayback Machine released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
  2. ^ Reader’s Guide to IDEF0 Function Models. Accessed 27 Nov 2008.
  3. ^ Ben B. Graham (2002). Detail Process Charting. p.2.
  4. ^ Schlager, J. (July 1956). «Systems engineering: key to modern development». IRE Transactions. EM-3 (3): 64–66. doi:10.1109/IRET-EM.1956.5007383. S2CID 51635376.
  5. ^ Arthur D. Hall (1962). A Methodology for Systems Engineering. Van Nostrand Reinhold. ISBN 0-442-03046-0.
  6. ^ William Gosling (1962) The design of engineering systems. p. 23
  7. ^ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design. Page 287.
  8. ^ Harold Chestnut (1967). Systems Engineering Methods. Page 254.
  9. ^ Thomas Dufresne & James Martin (2003). «Process Modeling for E-Business» Archived December 20, 2006, at the Wayback Machine. INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
  10. ^ Process perspectives. In: Metamodeling and method engineering, Minna Koskinen, 2000.
  11. ^ James Perozzo (1994) The complete guide to electronics troubleshooting. p. 72
  12. ^ William H. Von Alven (1964) Reliability engineering explains: «Functional block diagrams show functional sequences and signal paths, and items which are wired in parallel are drawn in parallel» (p. 286)
  13. ^ Systems Engineering Fundamentals. Archived September 27, 2007, at the Wayback Machine Defense Acquisition University Press, 2001
  14. ^ a b The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  15. ^ Task Analysis Tools Used Throughout Development. FAA 2008. Retrieved 25 Sept 2008.
  16. ^ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  17. ^ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique, Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
  18. ^ a b Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques,and Methodologies Archived 2009-08-25 at the Wayback Machine SANDIA REPORTS 85–2348qUC–32
  19. ^ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT. NASA paper N88-17234.
  20. ^ a b NASA (1995). «Techniques of Functional Analysis». In: NASA Systems Engineering Handbook Archived 2008-12-17 at the Wayback Machine June 1995. p.142.
  21. ^ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
  22. ^ SADT at Free-logistics.com. Retrieved 21 Sep 2008.
  23. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  24. ^ Systems Engineering Fundamentals. Archived September 27, 2007, at the Wayback Machine Defense Acquisition University Press, 1999.
  25. ^ a b Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
  26. ^ Paul Grefen (2010) Mastering e-Business. p. 5-10
  27. ^ US Department of Interior (2000–2008) Analyze the Business and Define the Target Business Environment. Accessed 27 Nov 2008.
  28. ^ «BPMN Information». Archived from the original on 2008-12-18. Retrieved 2008-11-02.
  29. ^ Richard C. Simpson (2004). An XML Representation for Crew Procedures. Final Report NASA Faculty Fellowship Program – 2004. Johnson Space Center.
  30. ^ S.A. White, «Business Process Modeling Notation (BPMN),» In: Business Process Management Initiative (BPMI) 3 May 2004.
  31. ^ Operator Function Model (OFM) Archived 2009-01-21 at the Wayback Machine. Accessed 27 Nov 2008.
Источник

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area.[1]

Example of a function model of the process of «Maintain Reparable Spares» in IDEF0 notation.

A function model, similar with the activity model or process model, is a graphical representation of an enterprise’s function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.[2]

History[edit]

The function model in the field of systems engineering and software engineering originates in the 1950s and 1960s, but the origin of functional modelling of organizational activity goes back to the late 19th century.

In the late 19th century the first diagrams appeared that pictured business activities, actions, processes, or operations, and in the first half of the 20th century the first structured methods for documenting business process activities emerged. One of those methods was the flow process chart, introduced by Frank Gilbreth to members of American Society of Mechanical Engineers (ASME) in 1921 with the presentation, entitled “Process Charts—First Steps in Finding the One Best Way”.[3] Gilbreth’s tools quickly found their way into industrial engineering curricula.

The emergence of the field of systems engineering can be traced back to Bell Telephone Laboratories in the 1940s.[4] The need to identify and manipulate the properties of a system as a whole, which in complex engineering projects may greatly differ from the sum of the parts’ properties, motivated various industries to apply the discipline.[5] One of the first to define the function model in this field was the British engineer William Gosling. In his book The design of engineering systems (1962, p. 25) he stated:

A functional model must thus achieve two aims in order to be of use. It must furnish a throughput description mechanics capable of completely defining the first and last throughput states, and perhaps some of the intervening states. It must also offer some means by which any input, correctly described in terms of this mechanics, can be used to generate an output which is an equally correct description of the output which the actual system would have given for the input concerned. It may also be noted that there are two other things which a functional model may do, but which are not necessary to all functional models. Thus such a system may, but need not, describe the system throughputs other than at the input and output, and it may also contain a description of the operation which each element carries out on the throughput, but once again this is not.[6]

One of the first well defined function models, was the functional flow block diagram (FFBD) developed by the defense-related TRW Incorporated in the 1950s.[7] In the 1960s it was exploited by the NASA to visualize the time sequence of events in a space systems and flight missions.[8] It is further widely used in classical systems engineering to show the order of execution of system functions.[9]

Functional modeling topics[edit]

Functional perspective[edit]

In systems engineering and software engineering a function model is created with a functional modeling perspective. The functional perspective is one of the perspectives possible in business process modelling, other perspectives are for example behavioural, organisational or informational.[10]

A functional modeling perspective concentrates on describing the dynamic process. The main concept in this modeling perspective is the process, this could be a function, transformation, activity, action, task etc. A well-known example of a modeling language employing this perspective is data flow diagrams.

The perspective uses four symbols to describe a process, these being:

  • Process: Illustrates transformation from input to output.
  • Store: Data-collection or some sort of material.
  • Flow: Movement of data or material in the process.
  • External Entity: External to the modeled system, but interacts with it.

Now, with these symbols, a process can be represented as a network of these symbols. This decomposed process is a DFD, data flow diagram.

Example of functional decomposition in a systems analysis.

In Dynamic Enterprise Modeling a division is made in the Control model, Function Model, Process model and Organizational model.

Functional decomposition[edit]

Functional decomposition refers broadly to the process of resolving a functional relationship into its constituent parts in such a way that the original function can be reconstructed from those parts by function composition. In general, this process of decomposition is undertaken either for the purpose of gaining insight into the identity of the constituent components, or for the purpose of obtaining a compressed representation of the global function, a task which is feasible only when the constituent processes possess a certain level of modularity.

Functional decomposition has a prominent role in computer programming, where a major goal is to modularize processes to the greatest extent possible. For example, a library management system may be broken up into an inventory module, a patron information module, and a fee assessment module. In the early decades of computer programming, this was manifested as the «art of subroutining,» as it was called by some prominent practitioners.

Functional decomposition of engineering systems is a method for analyzing engineered systems. The basic idea is to try to divide a system in such a way that each block of the block diagram can be described without an «and» or «or» in the description.

This exercise forces each part of the system to have a pure function. When a system is composed of pure functions, they can be reused, or replaced. A usual side effect is that the interfaces between blocks become simple and generic. Since the interfaces usually become simple, it is easier to replace a pure function with a related, similar function.

Functional modeling methods[edit]

The functional approach is extended in multiple diagrammic techniques and modeling notations. This section gives an overview of the important techniques in chronological order.

Function block diagram[edit]

Functional block diagram of the attitude control and maneuvering electronics system of the Gemini spacecraft. June 1962.

A functional block diagram is a block diagram, that describes the functions and interrelationships of a system. The functional block diagram can picture:[11]

  • Functions of a system pictured by blocks
  • Input of a block pictured with lines, and
  • Relationships between 9 functions
  • Functional sequences and paths for matter and or signals[12]

The block diagram can use additional schematic symbols to show particular properties.

Specific function block diagram are the classic functional flow block diagram, and the Function Block Diagram (FBD) used in the design of programmable logic controllers.

Functional flow block diagram[edit]

The functional flow block diagram (FFBD) is a multi-tier, time-sequenced, step-by-step flow diagram of the system’s functional flow.[14]
The diagram is developed in the 1950s and widely used in classical systems engineering. The functional flow block diagram is also referred to as Functional Flow Diagram, functional block diagram, and functional flow.[15]

Functional flow block diagrams (FFBD) usually define the detailed, step-by-step operational and support sequences for systems, but they are also used effectively to define processes in developing and producing systems. The software development processes also use FFBDs extensively. In the system context, the functional flow steps may include combinations of hardware, software, personnel, facilities, and/or procedures.

In the FFBD method, the functions are organized and depicted by their logical order of execution. Each function is shown with respect to its logical relationship to the execution and completion of other functions. A node labeled with the function name depicts each function. Arrows from left to right show the order of execution of the functions. Logic symbols represent sequential or parallel execution of functions.[16]

HIPO and oPO[edit]

HIPO for hierarchical input process output is a popular 1970s systems analysis design aid and documentation technique[17] for representing the modules of a system as a hierarchy and for documenting each module.[18]

It was used to develop requirements, construct the design, and support implementation of an expert system to demonstrate automated rendezvous. Verification was then conducted systematically because of the method of design and implementation.[19]

The overall design of the system is documented using HIPO charts or structure charts. The structure chart is similar in appearance to an organizational chart, but has been modified to show additional detail. Structure charts can be used to display several types of information, but are used most commonly to diagram either data structures or code structures.[18]

N2 Chart[edit]

Figure 2. N2 chart definition.[20]

The N2 Chart is a diagram in the shape of a matrix, representing functional or physical interfaces between system elements. It is used to systematically identify, define, tabulate, design, and analyze functional and physical interfaces. It applies to system interfaces and hardware and/or software interfaces.[14]

The N2 diagram has been used extensively to develop data interfaces, primarily in the software areas. However, it can also be used to develop hardware interfaces. The basic N2 chart is shown in Figure 2. The system functions are placed on the diagonal; the remainder of the squares in the N × N matrix represent the interface inputs and outputs.
[20]

Structured Analysis and Design Technique[edit]

Structured Analysis and Design Technique (SADT) is a software engineering methodology for describing systems as a hierarchy of functions, a diagrammatic notation for constructing a sketch for a software application. It offers building blocks to represent entities and activities, and a variety of arrows to relate boxes. These boxes and arrows have an associated informal semantics.[21] SADT can be used as a functional analysis tool of a given process, using successive levels of details. The SADT method allows to define user needs for IT developments, which is used in industrial Information Systems, but also to explain and to present an activity’s manufacturing processes, procedures.[22]

The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company. These functions fulfill the objectives of a company, such as sales, order planning, product design, part manufacturing, and human resource management. The SADT can depict simple functional relationships and can reflect data and control flow relationships between different functions. The IDEF0 formalism is based on SADT, developed by Douglas T. Ross in 1985.[23]

IDEF0[edit]

IDEF0 is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, re-engineering, and integration of information systems; business processes; or software engineering analysis.[24] It is part of the IDEF family of modeling languages in the field of software engineering, and is built on the functional modeling language building SADT.

The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system.[25] It was derived from the established graphic modeling language structured analysis and design technique (SADT) developed by Douglas T. Ross and SofTech, Inc. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.[1] The US Air Force commissioned the SADT developers to develop a function model method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.[25]

Axiomatic design[edit]

Axiomatic design is a top down hierarchical functional decomposition process used as a solution synthesis framework for the analysis, development, re-engineering, and integration of products, information systems, business processes or software engineering solutions.[26] Its structure is suited mathematically to analyze coupling between functions in order to optimize the architectural robustness of potential functional solution models.

[edit]

In the field of systems and software engineering numerous specific function and functional models and close related models have been defined. Here only a few general types will be explained.

Business function model[edit]

A Business Function Model (BFM) is a general description or category of operations performed routinely to carry out an organization’s mission. They «provide a conceptual structure for the identification of general business functions».[27] It can show the critical business processes in the context of the business area functions. The processes in the business function model must be consistent with the processes in the value chain models. Processes are a group of related business activities performed to produce an end product or to provide a service. Unlike business functions that are performed on a continual basis, processes are characterized by the fact that they have a specific beginning and an end point marked by the delivery of a desired output. The figure on the right depicts the relationship between the business processes, business functions, and the business area’s business reference model.[28]

Business Process Model and Notation[edit]

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is currently maintained by the Object Management Group since the two organizations merged in 2005. The current version of BPMN is 2.0.[29]

The Business Process Model and Notation (BPMN) specification provides a graphical notation for specifying business processes in a Business Process Diagram (BPD).[30] The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly BPEL4WS.[31]

Business reference model[edit]

This FEA Business reference model depicts the relationship between the business processes, business functions, and the business area’s business reference model.

A Business reference model is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency. In enterprise engineering a business reference model is part of an Enterprise Architecture Framework or Architecture Framework, which defines how to organize the structure and views associated with an Enterprise Architecture.

A reference model in general is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that perform them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area’s business reference model. These reference model can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

Operator function model[edit]

The Operator Function Model (OFM) is proposed as an alternative to traditional task analysis techniques used by human factors engineers. An operator function model attempts to represent in mathematical form how an operator might decompose a complex system into simpler parts and coordinate control actions and system configurations so that acceptable overall system performance is achieved. The model represents basic issues of knowledge representation, information flow, and decision making in complex systems. Miller (1985) suggests that the network structure can be thought of as a possible representation of an operator’s internal model of the system plus a control structure which specifies how the model is used to solve the decision problems that comprise operator control functions.[32]

See also[edit]

  • Bus Functional Model
  • Business process modeling
  • Data model
  • Enterprise modeling
  • Functional Software Architecture
  • Polynomial function model
  • Rational function model
  • Scientific modeling
  • Unified Modeling Language
  • View model

References[edit]

Public Domain This article incorporates public domain material from the National Institute of Standards and Technology.

Public Domain This article incorporates public domain material from Operator Function Model (OFM). Federal Aviation Administration.

  1. ^ a b FIPS Publication 183 Archived 2009-02-27 at the Wayback Machine released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
  2. ^ Reader’s Guide to IDEF0 Function Models. Accessed 27 Nov 2008.
  3. ^ Ben B. Graham (2002). Detail Process Charting. p.2.
  4. ^ Schlager, J. (July 1956). «Systems engineering: key to modern development». IRE Transactions. EM-3 (3): 64–66. doi:10.1109/IRET-EM.1956.5007383. S2CID 51635376.
  5. ^ Arthur D. Hall (1962). A Methodology for Systems Engineering. Van Nostrand Reinhold. ISBN 0-442-03046-0.
  6. ^ William Gosling (1962) The design of engineering systems. p. 23
  7. ^ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design. Page 287.
  8. ^ Harold Chestnut (1967). Systems Engineering Methods. Page 254.
  9. ^ Thomas Dufresne & James Martin (2003). «Process Modeling for E-Business» Archived December 20, 2006, at the Wayback Machine. INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
  10. ^ Process perspectives. In: Metamodeling and method engineering, Minna Koskinen, 2000.
  11. ^ James Perozzo (1994) The complete guide to electronics troubleshooting. p. 72
  12. ^ William H. Von Alven (1964) Reliability engineering explains: «Functional block diagrams show functional sequences and signal paths, and items which are wired in parallel are drawn in parallel» (p. 286)
  13. ^ Systems Engineering Fundamentals. Archived September 27, 2007, at the Wayback Machine Defense Acquisition University Press, 2001
  14. ^ a b The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  15. ^ Task Analysis Tools Used Throughout Development. FAA 2008. Retrieved 25 Sept 2008.
  16. ^ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  17. ^ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique, Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
  18. ^ a b Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques,and Methodologies Archived 2009-08-25 at the Wayback Machine SANDIA REPORTS 85–2348qUC–32
  19. ^ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT. NASA paper N88-17234.
  20. ^ a b NASA (1995). «Techniques of Functional Analysis». In: NASA Systems Engineering Handbook Archived 2008-12-17 at the Wayback Machine June 1995. p.142.
  21. ^ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
  22. ^ SADT at Free-logistics.com. Retrieved 21 Sep 2008.
  23. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  24. ^ Systems Engineering Fundamentals. Archived September 27, 2007, at the Wayback Machine Defense Acquisition University Press, 1999.
  25. ^ a b Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
  26. ^ Paul Grefen (2010) Mastering e-Business. p. 5-10
  27. ^ US Department of Interior (2000–2008) Analyze the Business and Define the Target Business Environment. Accessed 27 Nov 2008.
  28. ^ «BPMN Information». Archived from the original on 2008-12-18. Retrieved 2008-11-02.
  29. ^ Richard C. Simpson (2004). An XML Representation for Crew Procedures. Final Report NASA Faculty Fellowship Program – 2004. Johnson Space Center.
  30. ^ S.A. White, «Business Process Modeling Notation (BPMN),» In: Business Process Management Initiative (BPMI) 3 May 2004.
  31. ^ Operator Function Model (OFM) Archived 2009-01-21 at the Wayback Machine. Accessed 27 Nov 2008.
Источник

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

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

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

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

Требование (requirement) — желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации

Принята следующая  классификация требований , которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке: функциональные требования  (Functionality) требования удобства использования ( Usability ) требования надежности ( Reliability ) требования производительности (Performance) требования возможности сопровождения (Supportability) символом

Принята следующая  классификация требований , которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке:

  • функциональные требования  (Functionality)
  • требования удобства использования ( Usability )
  • требования надежности ( Reliability )
  • требования производительности (Performance)
  • требования возможности сопровождения (Supportability)
  • символом «+» обозначены дополнительные условия, к которым относятся:
  • проектные ограничения
  • требования управления системой
  • требования к графическому интерфейсу пользователя

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

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

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

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

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

Один из таких  шаблонов  рассматривается ниже и рекомендуется для применения на начальных этапах концептуального моделирования

Шаблон для написания сценария отдельного варианта использования

Шаблон для написания сценария отдельного варианта использования

Текст  сценария  должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полностью. В противном случае будут потеряны достоинства визуального представления моделей. Построение  диаграммы вариантов использования  - самый первый этап процесса  объектно-ориентированного анализа и проектирования . Цель его - представить совокупность  функциональных требований  к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме  диаграммы вариантов использования  и дополнительных  сценариев  может представлять собой самостоятельную модель,

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

Построение  диаграммы вариантов использования  — самый первый этап процесса  объектно-ориентированного анализа и проектирования . Цель его — представить совокупность  функциональных требований  к поведению проектируемой системы.

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

. Все заданные в этой модели требования допустимо представить в виде общей модели системы, которая может быть оформлена как отдельный пакет Система. Этот пакет в свою  очередь  может представлять собой иерархию пакетов, на самом верхнем уровне которых содержится множество классов, реализующих базовые варианты использования проектируемой системы. При этом пакет системы самого верхнего уровня может быть дополнительно помечен стереотипом . » width=»640″

которая в языке  UML  получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип .

Все заданные в этой модели требования допустимо представить в виде общей модели системы, которая может быть оформлена как отдельный пакет Система.

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

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

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

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

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

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

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

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

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

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

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

(Рисунок 1 — Диаграмма вариантов использования для модели банкомата ).

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

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

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

Таблица 1 - Главный раздел сценария выполнения варианта использования

Таблица 1 — Главный раздел сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

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

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

Таблица2. Раздел Типичный ход событий сценария выполнения варианта использования

Таблица2. Раздел Типичный ход событий сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

В третьем разделе  сценария  (таблица3) описывается последовательность действий, выполняемых при возникновении исключительных ситуаций или исключений.

В третьем разделе  сценария  (таблица3) описывается последовательность действий, выполняемых при возникновении исключительных ситуаций или исключений.

Таблица 3. Раздел Исключения сценария выполнения варианта использования

Таблица 3. Раздел Исключения сценария выполнения варианта использования «Снятие наличных по кредитной карточке»

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

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

Отдельные небольшие по своему объему  сценарии  могут быть размещены на диаграмме в форме примечаний.

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

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

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

Графически примечания на всех типах диаграмм обозначаются прямоугольником с

Графически примечания на всех типах диаграмм обозначаются прямоугольником с «загнутым» верхним правым уголком (рисунок ниже). Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других  канонических диаграммах .

Примеры примечаний на диаграммах вариантов использования

Примеры примечаний на диаграммах вариантов использования

, то данное примечание является ограничением, налагаемым на соответствующий элемент модели, но не на саму диаграмму. При этом  запись ограничения заключается в  фигурные скобки  и должна соответствовать правилам построения выражений языка OCL. Однако для диаграмм вариантов использования ограничения включать в модели не рекомендуется, поскольку они достаточно жестко регламентируют физические аспекты реализации системы, что противоречит концептуальному характеру общей модели вариантов использования. » width=»640″

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

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

Рекомендации по разработке диаграмм вариантов использования

  • Определить главных или первичных и второстепенных актеров
  • Определить цели главных актеров по отношению к системе
  • Сформулировать основные варианты использования, которые специфицируют  функциональные требования  к системе
  • Упорядочить варианты использования по степени убывания риска их реализации
  • Рассмотреть все базовые варианты использования в порядке убывания их степени риска
  • Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования
  • Написать успешный  сценарий  реализации выбранного варианта использования

Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом Проверить диаграмму на отсутствие дублирования вариантов использования и актеров » width=»640″

  • Определить исключения или неуспех в выполнении  сценария  варианта использования
  • Написать  сценарии  для всех исключений
  • Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом
  • Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом
  • Проверить диаграмму на отсутствие дублирования вариантов использования и актеров
Источник

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

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

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

  1. Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

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

  1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

Сценарии использования включают в себя следующие разделы: 

  1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

  1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Пользователь

Система

Какое физическое действие произвел пользователь? 

Как отреагировала система?

Нажимает “Добавить в корзину”

Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину. 

Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину”

Пользователь нажимает “перейти в корзину”

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

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

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

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

Пользователь

Система

Какое физическое действие произвел пользователь? 

Как отреагировала система?

Пользователь нажал кнопку “Зарегистрироваться” 

Система вывела форму регистрации, поле “email”

Пользователь вводит данные в поле “email”

3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации

Если данные не прошли проверку валидации, запускается альтернативный сценарий №1. 

Система производит поиск введенных данных “email”  по учетным записям в системе. 

Учетных записей с такими данными “email” не найдено. 

Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2

Система отправляет пользователю код подтверждения на email

Система выводит пользователю поле “код подтверждения”

Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. — обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный. 

Пользователь вводит корректный код подтверждения в поле “код подтверждения” 

Система производит проверку кода подтверждения. Код введен верно. 

Пользователь зарегистрирован. 

Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения” 

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

  1. Система выводит информер  с указанием запрещенных символов.

  2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Источник

Понравилась статья? Поделить с друзьями:
  • Что такое праздник неглиже
  • Что такое праздник сумбуля
  • Что такое сценарии оболочки
  • Что такое сценарий пьесы
  • Что такое праздник на английском языке