Моделирование требований пользователей

Статья
02/20/2013

Microsoft Visual Studio Ultimate помогает понимать и обсуждать потребности пользователей, а также информировать о них других. Для этого можно составлять схемы о деятельности пользователей и о том, как система помогает им в достижении целей.Модель требований — это набор этих схем, каждая из которых иллюстрирует отдельный аспект потребностей пользователей.

Видеодемонстрация доступна на странице Modeling the Business Domain.

Модель требований помогает:

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

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

Примечание
В этих разделах под термином "система" подразумевается система или приложение в разработке.Это может быть крупная коллекция множества компонентов программного и аппаратного обеспечения, одно приложение или компонент программного обеспечения внутри более крупной системы.Во всех этих случаях модель требований описывает поведение, видимое вне системы (через пользовательский интерфейс или API).

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

Общие задачи

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

Схема или документ	Что описывает в модели требований	Раздел
Схема вариантов использования	Кто использует систему, и какие действия они в ней совершают.	Описание использования системы
Концептуальная схема классов	Глоссарий типов, используемых для описания требований; типы видны в интерфейсе системы.	Определение терминов для описания требований
Схема деятельности	Рабочий процесс и обмен сведениями в процессе взаимодействия пользователей и системы или ее частей.	Отображение рабочего процесса между пользователями и системой
Схема последовательностей	Последовательность взаимодействий между пользователями и системой или ее частями.Альтернативное представление схемы деятельности.	Отображение взаимодействий между пользователями и системой
Дополнительные документы или рабочие элементы	Критерии производительности, безопасности, полезности и надежности.	Описание требований к качеству обслуживания
Дополнительные документы или рабочие элементы	Ограничения и правила, не относящиеся к конкретному варианту использования.	Отображение бизнес-правил

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

Описание использования системы

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

Например, система продажи еды через Интернет должна позволять клиентам выбирать элементы меню, а ресторанам-поставщикам — обновлять меню.Это можно объединить в схеме вариантов использования.

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

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

Система, участвующая в платеже, но не в доставке.

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

Кроме того, это помогает команде разработчиков обсуждать, что будет включено в последующие выпуски.Например, можно обсудить, будет ли компонент "Оплата еды" в первоначальном выпуске системы функционировать непосредственно между рестораном и клиентом (а не обрабатываться в системе).В этом случае в начальном выпуске можно переместить компонент "Оплата еды" за пределы прямоугольника системы Dinner Now.

Схема вариантов использования предоставляет только сводку вариантов использования.Чтобы предоставить более подробные описания, можно связать варианты использования на схеме с отдельными документами и другими схемами.Сведения об этом см. в разделе Практическое руководство. Связывание варианта использования с документами и схемами.

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

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

Дополнительные сведения см. в следующих разделах:

Подробнее о следующем	Прочитайте
Более подробные сведения о создании вариантов использования.	UML-схемы вариантов использования: правила работы
Элементы схемы вариантов использования.	UML-схемы вариантов использования: справочные материалы
Разработка кода из вариантов использования.	Моделирование архитектуры программной системы

Определение терминов для описания требований

UML-схемы классов можно использовать для создания согласованного словаря бизнес-понятий, которые будут использоваться:

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

Если понятия используются с этой целью, содержимое UML-схемы классов называется концептуальной схемой классов.(Она также называется моделью домена или моделью классов анализа).

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

Например, можно изобразить следующие концептуальные классы для системы Dinner Now.

Классы Menu, Order, Menu Item, Order Item.

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

Клиент выбирает меню для формирования заказа, а затем создает в заказепункты заказа, выбирая из менюпункты меню.

Обратите внимание, что термины, используемые в этом описании, являются именами классов в модели.Схема устраняет неоднозначности в отношениях между этими классами.Например, на схеме хорошо видно, что каждый заказ связан только с одним меню.

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

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

Например, в разных частях системы и в разных интерфейсах, связывающих эти части, заказы могут быть представлены в форматах XML, SQL, HTML и C#.Связь между заказом и меню можно представить по-разному, например с помощью ссылок в коде C#, отношений в базе данных или ИД перекрестных ссылок в XML.Несмотря на эти различия, концептуальная модель предоставляет важные сведения, истинные во всех частях программного обеспечения.Схема классов в этом примере показывает, что в каждой реализации заказ связан только с одним меню.

Создание схемы классов требований позволяет команде разработчиков:

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

Дополнительные сведения см. в следующих разделах:

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

В концептуальной схеме классов обычно не стоит изображать стрелки, указывающие на ассоциации, чтобы показать возможности перехода.На схеме не представляется реализация.Ассоциации представляют связи между объектами реального мира.Следующее расширение Visual Studio делает ненаправленные стрелки стрелками по умолчанию: Sample: UML Domain Modeling features.

Отображение бизнес-правил

Бизнес-правило — это требование, не связанное с определенным вариантом использования, которое необходимо соблюдать во всех частях системы.

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

Правило в комментарии, вложенном в класс Order.

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

Например, многие динамические правила можно сформулировать более эффективно и в более общем виде, заменив их статическими правилами.Например, в класс в концептуальной модели классов можно добавить логический атрибут "Logged In".Тогда Logged In будет добавляться в качестве постусловия варианта использования "вход в систему" и предусловия большинства других вариантов использования.Благодаря этому подходу можно не определять все возможные комбинации последовательностей событий.Кроме того, этот подход является более гибким при необходимости добавить в модель новые варианты использования.

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

Дополнительные сведения см. в следующих разделах:

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

Описание требований к качеству обслуживания

Существует несколько категорий требований к качеству обслуживания.Среди них можно выделить следующие.

Производительность
Безопасность
Полезность
Надежность
Устойчивость

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

Если ресторан удалит пункт меню, пока клиент заказывает еду, любые пункты заказа, связанные с этим пунктом меню, будут выделены красным.

Дополнительные сведения см. в следующих разделах:

Подробнее о следующем	Прочитайте
Более подробные сведения о записи требований к качеству обслуживания.	Guidelines for Defining Quality of Service Requirements
Присоединение дополнительных документов к вариантам использования.	Практическое руководство. Связывание варианта использования с документами и схемами
Разработка кода в соответствии с требованиями к качеству обслуживания.	Моделирование архитектуры программной системы

Отображение рабочего процесса между пользователями и системой

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

Например:

Активность с тремя действиями и циклом.

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

Варианты использования для предыдущих действий

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

Дополнительные сведения см. в следующих разделах:

Подробнее о следующем	Прочитайте
Дополнительные сведения о способах определения рабочих процессов в бизнесе.	UML-схемы деятельности: рекомендации
Элементы схемы деятельности.	UML-схемы деятельности: справочные материалы
Разработка кода из схем деятельности.	Моделирование архитектуры программной системы

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

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

Например:

Схема последовательностей с системой и субъектами.

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

Дополнительные сведения см. в следующих разделах:

Подробнее о следующем	Прочитайте
Дополнительные сведения о способах определения взаимодействий.	UML-схемы последовательностей: правила работы
Элементы схемы последовательностей.	UML-схемы последовательностей: справочные материалы
Разработка кода из схем последовательностей.	Моделирование архитектуры программной системы

Использование модели для уменьшения числа несоответствий

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

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

Для каждого класса в модели требований необходимо задать вопрос "Какой вариант использования создает экземпляры данного класса?". Например, для службы заказа еды через Интернет можно спросить: «Какой вариант использования создает экземпляры класса "Меню ресторана"?» Это позволит начать обсуждение о том, как новый ресторан подписывается на работу со службой и предлагает свое меню.Аналогичные вопросы можно задавать о том, что создает или изменяет атрибуты и ассоциации.
Для каждого варианта использования в модели требований попытайтесь описать результат (или постусловие) каждого варианта использования с помощью слов, предоставленных схемами классов.Во многих случаях рекомендуется показывать следствие варианта использования, составляя эскиз экземпляров классов до и после вхождения варианта использования.Например, если постусловие варианта использования гласит "пункт меню добавляется в заказ клиента", необходимо составить эскизы экземпляров для классов "пункт заказа" и "пункт меню".Покажите следствия варианта использования, например новую ссылку или новый объект, на новом рисунке или выделите их другим цветом.Часто это позволяет начать обсуждение о том, какие сведения необходимы в модели.Хотя классы требований не связаны напрямую с реализацией, они описывают сведения, которые потребуется хранить и передавать в системе.
Задайте вопрос об ограничениях атрибутов и ассоциаций. Особое внимание уделите ограничениям, распространяющимся на несколько атрибутов или ассоциаций.
Задайте вопрос о допустимых и недопустимых последовательностях вариантов использования, проиллюстрировав их с помощью схем последовательностей или схем деятельности.

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