Анализ требований

Требования (requirements) – это возможности или условия, которым должна соответствовать система или проект. Требования разделяются на следующие категории:

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

- удобство – человеческий фактор, справочная система, документация;

- надежность – частота сбоев, возможность восстановления и предсказуемость поведения;

- производительность – время отклика, точность, доступность, использование ресурсов;

- возможность поддержки – адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования;

- реализация – требования к ресурсам, языки и средства, аппаратное обеспечение;

- интерфейс – ограничения, накладываемые необходимостью взаимодействия с внешними системами;

- операции – управление системой и ее параметры;

- пакетирование;

- юридические вопросы – авторское право и т.п.

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

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

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

Вариант использования (use case) –это независящее от реализации высокоуровневое представление конкретной функции разрабатываемой системы. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое внешним объектом (действующим лицом).

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

Рисунок 4.5 – Диаграмма варианов использования

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

- для идентификации вариантов использования перечислите все внешние события, на которые система должна каким-то образом реагировать;

- не моделируйте связи между действующими лицами (они не входят в состав разрабатываемой системы);

- не соединяйте варианты использования непосредственно, чтобы показать последовательность действий (для этого используйте диаграмму деятельности);

- для указания связей между вариантами использования применяйте отношения «использование» (uses) и «расширение» (extends).

Для подробного описания процесса обработки данных, реализуемого в рамках варианта использования, разрабатывается документ, называемый «поток событий»(flow of events). Обычно этот документ включает:

- краткое описание варианта использования;

- предусловия;

- основной поток событий варианта использования;

- альтернативные потоки событий;

- постусловия.

Таким образом, данный документ будет подробно описывать, что будут делать действующие лица, а что – сама система.

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

Рисунок 4.6 – Диаграмма последовательности

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

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