Данный подход полезен для создания нефункциональных требований, с которыми можно связать какой-либо сервис. Многократно повторяющиеся разные точки зрения позволяют сформировать для сервисов различные нефункциональные требования
На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис. 5.3.
1. Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения.
2. Структурирование точек зрения — создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня.
3. Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов.
Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.
Рис. 5.3. Метод VORD
Точки зрения и информация о сервисах в методе VORD собираются с помощью стандартных форм (шаблонов точек зрения и шаблонов описания сервисов). В методе VORD также используются различные графические представления, включая диаграммы иерархии точек зрения и сценарии событий.
Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы управления банкоматами. Банкомат имеет встроенное программное обеспечение для управления аппаратными средствами и для связи с центральной базой данных банковских счетов.
Банкомат принимает запросы клиента, выдает наличные деньги, информацию о счете, изменяет данные в базе данных банка и т.д. Банкоматы одного банка могут позволить клиентам других банков использовать какую-то часть своих сервисов (обычно это снятие со счета наличных денег и запрос о текущем балансе счета).
Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда определяются потенциальные системные сервисы и организации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения.
Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и исключительные ситуации. Источниками информации, которые можно использовать в создании этого начального образа системы, могут служить документы, описывающие назначение системы, знания инженеров-программистов из предыдущих проектов или опыт клиентов банка. Может быть проведен опрос менеджеров банка, обслуживающего персонала, консультантов, инженеров и клиентов.
Следующей стадией процесса формирования требований будет идентификация опорных точек зрения и сервисов. Сервисы должны соответствовать опорным точкам зрения (рис. 5.4).
Рис. 5.4. Сервисы, соотнесенные с точками зрения.
Точки зрения также определяют входные данные и управляющую информацию для сервисов. Например, банкомат должен определять остаток денег после выдачи наличных. На ранних этапах процесса формирования требований эти данные и управляющая информация идентифицируются просто по имени. На рис. 5.5 представлена управляющая информация для точки зрения владельца счета, сервисы которой показаны на рис. 5.4. Управляющая информация вводится с помощью кнопок на панели банкомата, данные — посредством клиентской карточки или клавиатуры банкомата.
Следующая стадия процесса формирования требований — получение более детальной информации относительно сервисов, используемых сервисами данных, и управляющих данных. Эта информация извлекается из мнений лиц, формирующих требования, связанные с каждой опорной точкой зрения. Для этого используются шаблоны точек зрения и описания сервисов в виде сценариев событий. Эти сценарии обсуждаются в следующем разделе. Шаблоны точек зрения, описания сервисов и сценарии событий разрабатываются для всех идентифицированных опорных точек зрения и сервисов.
Рис. 5.5. Данные и управляющая информация
Люди обычно легче воспринимают примеры из реальной жизни, чем абстрактные описания. Они легко понимают и могут оценить сценарии взаимодействия с программной системой. Специалисты могут использовать информацию, полученную из обсуждения сценариев взаимодействия с системой, для формулирования требований.
Сценарии особенно полезны для детализации уже сформулированных требований, поскольку описывают последовательность интерактивной работы пользователя с системой. Каждый сценарий описывает одно или несколько возможных взаимодействий. В настоящее время разработаны многочисленные формы сценариев, которые предоставляют различную информацию на разных уровнях детализации системы.
Варианты использования.Варианты использования (use-case) — это методика формирования требований, основанная на сценариях. Они стали основой нотаций в языке моделирования UML при описании объектных моделей систем. В самой простой форме в варианте использования определены действующие лица (в UML они называются актерами), т.е. пользователи, вовлеченные во взаимодействие, и имена типов взаимодействия.
Варианты использования в первую очередь предназначены для определения функциональных требований к системе, они управляют всем процессом ее разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование, выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять, как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы для того, чтобы реализовать нужную для пользователя функциональность.
Понятие «вариант использования» впервые ввел А. Якобсон и затем придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта.
Варианты использования в языке UML представляют в виде диаграмм прецедентов.
Диаграмма прецедентов (Use Case Diagram)– это описание множества действий, которые система может осуществлять в ответ на воздействия, оказываемые на эту систему со стороны внешних по отношению к ней сущностей.
