![]() КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Анализ требованийТребования (requirements) – это возможности или условия, которым должна соответствовать система или проект. Требования разделяются на следующие категории: - функциональные требования – свойства, возможности, безопасность; - удобство – человеческий фактор, справочная система, документация; - надежность – частота сбоев, возможность восстановления и предсказуемость поведения; - производительность – время отклика, точность, доступность, использование ресурсов; - возможность поддержки – адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования; - реализация – требования к ресурсам, языки и средства, аппаратное обеспечение; - интерфейс – ограничения, накладываемые необходимостью взаимодействия с внешними системами; - операции – управление системой и ее параметры; - пакетирование; - юридические вопросы – авторское право и т.п. Обычно требования делят на две большие категории: функциональные (относящиеся к поведению) и нефункциональные (все остальные). Некоторые из этих требований (удобство, надежность, производительность и возможность поддержки) называются атрибутами качества (quality attributes).
Модель вариантов использования В рамках Унифицированного процесса функциональные требования исследуются и формулируются в модели вариантов использования. Вариант использования (use case) –это независящее от реализации высокоуровневое представление конкретной функции разрабатываемой системы. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое внешним объектом (действующим лицом). Диаграмма вариантов использования (рисунок 4.5) показывает взаимодействие между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя. Рисунок 4.5 – Диаграмма варианов использования Разрабатывая диаграммы вариантов использования, придерживайтесь следующих простых правил: - для идентификации вариантов использования перечислите все внешние события, на которые система должна каким-то образом реагировать; - не моделируйте связи между действующими лицами (они не входят в состав разрабатываемой системы); - не соединяйте варианты использования непосредственно, чтобы показать последовательность действий (для этого используйте диаграмму деятельности); - для указания связей между вариантами использования применяйте отношения «использование» (uses) и «расширение» (extends). Для подробного описания процесса обработки данных, реализуемого в рамках варианта использования, разрабатывается документ, называемый «поток событий»(flow of events). Обычно этот документ включает: - краткое описание варианта использования; - предусловия; - основной поток событий варианта использования; - альтернативные потоки событий; - постусловия. Таким образом, данный документ будет подробно описывать, что будут делать действующие лица, а что – сама система. Графически основной поток событий конкретного варианта использования отображается на диаграмме последовательности (рисунок 4.6). Стрелки на диаграмме соответствуют сообщениям, которыми обмениваются объекты для выполнения требуемой функции. Рисунок 4.6 – Диаграмма последовательности Для уточнения взаимодействия между объектами в рамках варианта использования можно также использовать диаграммы кооперации, состояния и деятельности. Прототип пользовательского интерфейса помогает в ходе определения требований понять и опрделить взаимодействие между действующими лицами – людьми и системой. При определении интерфейса используется модель интерфейса пользователя и эскизы экранных форм.
|