Тема 2.6.3 Спецификация прецедентов. Построение модели требований. Самостоятельная работа № 31 (2 часа)

Тема: Сбор и анализ требований.

Теоретические сведенья

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

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

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

• заказчик не всегда способен четко сформулировать, чего он хочет от системы;

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

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

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

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

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

• достижение лучшего понимания разработчиками того, что должна делать система;

• определения системной функциональности;

• создание базиса для планирования разработки проекта;

Роли в процессе сбора и анализа требований

Аналитик - наш специалист, который выполняет работу по выявлению и моделированию требований.

Заинтересованные лица - представители заказчика, предоставляющие информацию.

Эксперт - представители заказчика, участвующий в разработке требования, специалист в предметной области.

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

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

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

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

Спецификация требований (Software Requirements Specification SRS) или Техническое задание основной документ, используемый при проектировании и разработке программного обеспечения. Документ включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному программного продукта, но не к процессу его разработки и не содержат деталей реализации требований. Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса системы.

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

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

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

Результат: Документ Описание системы.

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

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

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

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

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

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

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

Задание

Студентам необходимо:

• ознакомится с теоретическими сведениями;

• сделать конспект изложенного материала;

• ответить на контрольные вопросы.

Контрольные вопросы

1. Определение требования.

2. Функциональные требования.

3. Нефункциональные требования.

4. Роли в процессе сбора и анализа требований.

5. Модель требований.

6. Спецификация требований.

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