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

Заказчик может сформировать задачу в собственных терминах и определениях - на языке бизнеса. Чтобы определить отношения между потребностями заказчика в терминах понятных для разработки программного обеспечения. Мы документируем требования заказчика в виде требований к программному обеспечению - далее системе.

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

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

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

Целями сбора и анализа требований являются:

Роли в процессе сбора и анализа требований Для достижения поставленных целей мы разрабатываем следующие документы: После согласования заказчиком вышеукзанных документов, для уточнения требований разрабатываются следующие документы:

Порядок проведения анализа.

1. Разработка документа Описание системы.

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

2. Построение модели требований

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

3.Уточнение требований

Цели процесса

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

После завершения сбора требований к системе происходит оценка стоимости разработки программного обеспечения.
Разработка программ   Электронные аукционы  Питательные среды  Новинки кино