Методы определения требований в программной инженерии

Отношения между сценариями.Между сценариями задаются отношения пунктирными стрелками с указанием названия типа отношений.

Для сценариев можно задавать два типа отношений:

1. отношение "расширяет" означает, что функция одного сценария является дополнением к функции другого и используется при наличии нескольких вариантов одного и того же сценария (рис. 3.5).
   

   
   Рис. 3.5. Пример отношения "расширяет" Инвариантная часть сценария изображается в виде основного сценария, а отдельные варианты как расширения. При этом основной сценарий является устойчивым, не меняется при расширении вариантов функций и не зависит от них.
2. отношение "использует" означает, что некоторый сценарий может быть использован как расширение нескольких других сценариев (рис. 3.6).
   

   
   Рис. 3.6. Пример отношения "использует"

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

Инженерия требований завершается построением модели требований, которая включает в себя:

1. описание требований и основных понятий ПрО;
2. модель сценариев;
3. интерфейсы сценариев.

Модель сценариев - это неформальное описание каждого из входящих в нее диаграмм сценариев.

Описание сценария задается последовательностью следующих элементов:

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

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

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

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

3.2.2. Описание требований прецедентами

Альтернативным термином для сценария являются прецеденты. Как и в случае сценариев, задача описания требований прецедентами сводится к анализу дерева целей системы и к описанию реакции системы в случае недостижимости той или иной поставленной цели к проектируемой системе. Основным условием описания требований с помощью прецедентов является полнота системных требований, касающихся интерфейса пользователя, протоколов и форматов ввода-вывода [3.2,3.5].

Содержательной стороной системной части требований является описание функций, данных и принципов функционирования. Методология формирования требований с помощью прецедентов реализована в среде Rational Rose (www.rational.com.uml) и включает построение ряда моделей на основе прецедентов.

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

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

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

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

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

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

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

С синтаксической точки зрения эта модель имеет следующий вид.

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

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

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

Контрольные вопросы и задания

1. Приведите классификацию требований.
2. Определите назначение функциональных и нефункциональных требований.
3. Назовите источники сведений для задания требований.
4. Приведите задачи обследования, анализа и сбора требований.
5. Определите инженерию требований.
6. Дайте определение спецификации требований.
7. Приведите задачи трассировки требований.
8. Определите сущность объектно-ориентированной инженерии требований.
9. Назовите роли действующих лиц формирования требований.
10. Определите понятие актора.
11. Назовите виды отношений объектов в модели.
12. Определите виды отношений в сценарном подходе.
13. Определите представление модели ПрО прецедентами.