Атрибуты требований
Атрибут требования является основной составляющей «хорошего» требования. С помощью атрибутов осуществляется управление требованиями, отслеживание состояний требований, задание дополнительной информации, расширяющей текстовое содержание требования. Чтобы не перегружать формулировку требования излишними деталями, специалисты рекомендуют выносить всю дополнительную информацию в атрибуты, жестко привязанные к требованию [2]. Используя содержимое атрибутов, намного легче обрабатывать требования, осуществлять поиск, выборку и сортировку.
Выявление требований
После того, как проектная команда научилась применять основные методы выявления требований, необходимо познакомится с методами, которые относятся не только к выявлению, но также затрагивают документирование и анализ требований. К данным методам относятся варианты использования и прототипы.
Варианты использования
Подход на основе вариантов использования (UseCaseDrivenApproach) позволяет не только описывать пользовательские требования, он лежит в основе объектно-ориентированного подхода к разработке программного обеспечения. Это метод анализа и проектирования сложных систем, представляющий собой способ описания поведения системы с точки зрения того, как различные пользователи взаимодействуют с ней для достижения своих целей. Такой ориентированный на пользователя подход позволяет исследовать различные варианты поведения системы при привлечении пользователя на ранних этапах разработки.
На основе варианта использования в дальнейшем строятся модели анализа и проектирования. Создание моделей и сценариев вариантов использований является трудной задачей и требует от аналитика большого практического опыта.
Далее я приведу некоторые рекомендации того, как необходимо применять и разрабатывать варианты использования.
Для начала необходимо создать системную диаграмму, которая должна содержать в себе границы разрабатываемой системы и основных действующих лиц. Далее размешать на диаграмме в виде вариантов использования пользовательские требования. Вариант использования обычно записывается в виде связки «глагол + существительное», которые характеризуют действие, выполняемое пользователем, и объект, над которым выполняется действие. Например, пользовательское требование «Пользователь должен с помощью системы оплачивать покупку в интернет - магазине», можно записать в виде следующих вариантов использования: «Оплатить покупку в интернет - магазине» или «Оплата покупки в интернет - магазине».
Если система большая и охватывает множество функциональных областей, системную диаграмму можно представить в виде пакетов вариантов использования. Пример системной диаграммы представлен на рисунке 4. В таком случае можно разделить работу между проектной командой и назначить отдельных людей за сбор и документирование требований определенной области.
Рисунок 4. Системная диаграмма для крупномасштабной системы
На рисунке 4 четко отображены границы системы и выполняемый ею функционал. Пользователи системы изображены в виде действующих лиц и находятся вне границ системы.
Каждая функциональная область далее должна быть представлена в виде отдельной диаграммы вариантов использования, как изображено на рисунке 5.
Рисунок 5. Пример диаграммы вариантов использования для подсистемы
Каждый вариант использования должен быть описан в виде сценария взаимодействия пользователя и системы. Система на уровне абстракции вариантов использования представляет собой «черный ящик», т.е. при описании сценария автор варианта использования должен описывать «что» делает система в ответ на запрос пользователя, а не то «как» система это делает. Сценарий варианта использования можно описывать в виде диаграммы деятельности или с помощью текстового описания.
При описании в виде диаграммы деятельности рекомендуется разбивать ее на части (swimlines), характеризующие пользователя и систему. Так как сценарий необходимо согласовывать с пользователями и заказчиками, которые могут быть не знакомы с UML, понимание варианта использования может затрудниться. В таких случаях лучше описывать сценарий с помощью текста.
Текстовое описание варианта использования может быть представлено различными способами: в виде плоского текста, в табличном виде или в структурированном виде. Наиболее удобным, на мой взгляд, является, представление сценария в структурном виде с использование специального шаблона.
Как видим из представленных выше рисунков, модель вариантов использования позволяет структурировать пользовательские требования к разрабатываемой системе.