Классификация и специфицирование требований

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

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

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

Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (Use case), предложенный И.Якобсоном (см., например, [8.1]).

Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов ^{1В различных русскоязычных текстах автору приходилось видеть следующие переводы термина "actor": актор, актер, актант, агент, субъект, пользователь. Так как все они либо неблагозвучны, либо неточны, за неимением лучшего далее по тексту будем пользоваться переводом, наиболее близким к транскрипции.} (actors) и вариантов использования.

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

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

Глоссарий

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

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

Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей" (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

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

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

• Свободный формат,
• Полный формат (предложенный А. Коберном),
• Таблица в две колонки,
• Таблица в три колонки,
• Стиль RUP.

Кроме того, иногда целесообразно использовать:

• Псевдокод,
• Диаграмму активности UML (см. "Расширенный анализ требований. Моделирование" ),
• Другие графические модели.

Свободный формат

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