Обработка результатов сеанса

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

Из всех идей необходимо отбросить те, которые не завершены или не могут быть использованы. Остальные идеи могут быть разбиты на три категории:

· Реальные – представляют собой требования, которые могут быть оттестированы.

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

· Маловероятные – идеи, скорее всего не являющиеся разумными требованиями.

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

Сценарии

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

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

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

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

Сценарии событий

Событийные сценарии (event scenarios) используются для документирования поведения системы, представленного определенными событиями. В большинстве случаев сценарий включает в себя:

· Описание начального состояния системы.

· Описание нормального протекания событий.

· Описание исключительных ситуаций и способов их обработки.

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

· Описание конечного состояния системы.

Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].

Пример 3.1.

На рисунке 3.1 приведен сценарий события “Регистрировать программу”, который описывает процесс регистрации новой программы в реестре организации-разработчика.

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

· Полномочия недостаточны. Отказ в регистрации программы.

· Незарегистрированный контракт. Отказ в регистрации программы.

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

Рис. 3.1

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

Варианты использования

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

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

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

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

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

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

2. Основное действующее лицо – участник, который обращается к системе, чтобы она обеспечила достижение его цели.

3. Уровень, который определяет, насколько высока эта цель.

Требования должны быть короткими и ясными, поэтому основные рекомендации по написанию варианта использования могут быть следующими [7]:

· Начните со стратегического варианта. От него будут ветвиться варианты использования уровня цели пользователя.

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

· На каждом шаге четко определяйте действующее лицо и его намерения.

· Для описания альтернативного поведения применяйте расширения, а не предложения типа «если … то … иначе» в теле главного варианта использования.

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

Пример 3.2.

Вариант использования “Принять программу в архив”.

Основное действующее лицо: Приемщик.

Область действия: Архив.

Уровень: Цель пользователя.

Основной сценарий:

1. Разработчик сообщает свои характеристики приемщику.

2. Приемщик проверяет полномочия разработчика.

3. Разработчик сообщает регистрационный номер программы.

4. Приемщик проверяет отсутствие программы в архиве.

5. Приемщик получает от разработчика:

ü носитель-оригинал с программой;

ü ведомость носителя, описывающую файлы, находящиеся на носителе-оригинале и их контрольные характеристики.

6. Приемщик контролирует соответствие содержимого носителя и его ведомости.

7. Приемщик копирует содержимое носителя-оригинала на проверенный и зарегистрированный архивный носитель.

8. Приемщик регистрирует копию в качестве подлинника программы.

9. Приемщик передает сведения о приеме программы в архив разработчику.

Расширения:

2а. Полномочия разработчика недостаточны для сдачи программы в архив:

2а1. Приемщик сообщает об этом разработчику, отказывает в приеме программы и переходит в исходное состояние.

4а. Программа уже находится в архиве:

4а1. Приемщик сообщает об этом разработчику, отказывает в приеме программы, выдает ему инвентарный номер, под которым программа принята в архив, и переходит в исходное состояние.

6а. Носитель содержит “лишние” файлы:

6а1. Разработчик уточняет состав файлов программы.

6а2. Приемщик переходит к пункту 7.

6б. Неверные контрольные характеристики файла (файлов):

6б1. Приемщик сообщает об этом разработчику, отказывает в приеме программы и переходит в исходное состояние.

Применение модели MSC UML

UML (Unified Modeling Language) – это унифицированный язык моделирования. UML представляет собой формальный искусственный язык, который постоянно развивается. Описание UML [3] по большей части формальное, но содержит и явно неформальные составляющие, что заметно отличает его от языков, которые, по общему мнению, являются образцами формализма. UML предназначен для моделирования. Сами авторы UML определяют его как графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке приложений.

Для общего представление функционального назначения системы в UML предназначены диаграмма использования (use case). Диаграмма использования призвана ответить на вопрос: что делает система во внешнем мире?

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

· ассоциация между действующим лицом и вариантом использования;

· обобщение между действующими лицами;

· обобщение между вариантами использования;

· зависимости (различных типов) между вариантами использования.

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

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

Пример 3.3

На рисунке 3.2 приведена диаграмма использования “Принять программу в архив”, описывающая процесс сдачи программы в архив организации-разработчика.

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

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

Рис. 3.2

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

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

3.6. Выявление требований на основе различных
точек зрения. Метод VORD

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

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

Существуют различные интерпретации понятия точки зрения. Приведем некоторые из них [9]:

Точка зрения – это источник информации о системных данных. В этом случае точка зрения – основа для построения модели создания и использования данных в системе.

Точка зрения – это особая часть модели системы и на основе различных точек зрения могут быть построены, например, модели сущность-связь или модели конечного автомата системы.

Точка зрения – это получатель системных сервисов. В этом случае точка зрения (точнее ее носитель) является внешним по отношению к системе и помогает определить данные, необходимые для выполнения системных сервисов и управления ими.

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

· более естественно структурировать процесс формирования требований (по точкам зрения);

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

· выявить нефункциональные требования.

На основе такого подхода к интерпретации и выбору опорных точек был разработан метод VORD (Viewpoint-Oriented Requirements Definition) для формирования и анализа требований.

Метод VORD состоит из четырех основных этапов:

1. Идентификация точек зрения.

2. Структурирование точек зрения.

3. Документирование точек зрения.

4. Отображение системы точек зрения.

Идентификация точек зрения

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

«Мозговой штурм» направлен на решение следующих задач:

· идентификация потенциальных опорных точек зрения;

· идентификация системных сервисов;

· определение входных системных данных;

· определение нефункциональных требований;

· выявление управляющих событий и исключительных ситуаций.

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

· документы, описывающие назначение системы,

· знания о предыдущих разработках,

· опыт пользователей,

· опрос менеджеров, персонала, консультантов, инженеров, клиентов, т.е. лиц, заинтересованных в системе.

Результат «мозгового штурма» – документ, идентифицирующий опорные точки зрения и сервисы системы (см. рис. 3.3).