5 способов разработки Use Cases

Система управления требованиями 3SL Cradle предоставляет возможность выбора технологии разработки Use Cases удобной для конкретного коллектива. В данной статье кратко рассматриваются основные технологические подходы к организации разработки вариантов использования в 3SL Cradle. 

Немного о Use Cases.

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

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

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

  • Основное действующее лицо
  • Область действия
  • Участники и интересы
  • Предусловия
  • Минимальные гарантии
  • Гарантия успеха
  • Основной сценарий
  • Расширения

Технологии разработки Uses Cases в 3SL Cradle

Способ первый. Один элемент — один вариант использования — одно поле.

Основная единица управления в базе данных Cradle — элемент (item). Вы можете определить любой набор типов элементов, например, требования, тесты, функции, классы, оборудование… Также мы можем определить тип элемента Use Case и в поле TEXT данного элемента вводить полное описание варианта использования.

  • Преимущества подхода:  простота настройки, легкость copy/past из документов, обеспечение трассируемости варианта использования в целом к другим элементам, в том числе к другим вариантам использования, изменение структуры Use Case не повлияет на технологию.
  • Недостатки подхода: сложность анализа и сравнения объемных вариантов использования.

Способ второй. Один элемент — один вариант использования — каждому разделу варианта использования свое поле.

Данный способ отличается от предыдущего тем, что для элемента типа Use Case настраиваются поля в соответствии с выбранной структурой Use Case. Один раздел — одно поле. Таким образом, будут настроены поля: основное действующее лицо, область действия, участники и интересы и др.

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

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

Данный способ предполагает занесение каждого раздела Use Case в отдельный элемент (item), при этом можно ввести атрибут — тип раздела,  что упростит анализ и выборки. Каждый вариант использования будет выглядеть как иерархия элементов, где элемент верхнего уровня соответствует данному варианту использования в целом, а подчиненные элементы — его разделам.

  • Преимущества подхода: возможна большая детализация при трассировке — трассировать не к Use Cases целиком, а только к одному из разделов, повторное использование отдельных разделов, что может значительно сократить время разработки всего набора вариантов использования, пораздельное управление правами доступа, построение пораздельных выборок, например, выбрать всех действующих лиц и т.п.
  • Недостатки подхода: необходимость создавать и поддерживать связи не только между отдельными Use Cases, но и связи между элементами разделов (не сложно при технологии drag&drop).

Способ четвертый. Каждому разделу варианта использования — свой тип элементов.

Данный способ предполагает, что для каждого раздела варианта использования создаются соответствующие типы элементов. Один из вариантов соответствующей модели трассировки описан в статье «Зоопарк трассировки«, в разделе Альбом моделей трассировки требований.

  • Преимущества подхода: дополнительно к предыдущему — возможность использовать автоматически созданные для каждого типа запросы и представления.
  • Недостатки подхода: аналогично предыдущему.
Практика показывает, что выбирать стоит из второй, третьей и четвертой технологии разработки Use Cases. Окончательный выбор зависит от общей технологии работы, модели трассировки и задач, которые решаются с помощью трассировки требований.
Способ пятый. Диаграммы Use Cases для графического представления вариантов использования.
use_case_diagram
При необходимости консультации в области разработки технологии трассировки для ваших производственных задач вы можете обратиться к специалистам компании SATURS.

Добавить комментарий