1. Вопросы для самоконтроля

1. Каковы источники возникновения требований?

2. В чем разница между пользовательским и системным требованием?

3. В чем достоинства и недостатки разделения требований на пользовательские и системные требования?

4. В чем основные отличия в проведении интервью и совместных семинаров?

5. Как определяются роли во время сеансов ”мозговой штурма”?

6. Что такое вариант использования?

7. Как определить иерархию различных точек зрения?

8. Каковы основные требования к документированию пользовательских требований?

4. Разработка системных требований

   1. Детализация требований пользователей

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

Системные требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа, сформулированных в подробностях [10]

Модели могут представлять систему с разных точек зрения. Это может быть модель окружения (или рабочей среды системы), модель поведения системы или модель структуры системы, когда моделируются, например, структуры данных, обрабатываемые системой.

В основе моделирования лежат такие структурные методы, как структурный анализ систем и объектно-ориентированный анализ. Эти методы определяют процесс, который используется для построения моделей и набор правил их моделирования. Структурные методы анализа имеют и существенные недостатки, поскольку:

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

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

• выбор метода и типов моделей зависит от решаемой задачи и достаточно ответственен (и сложен).

2. Системные модели

В процессе анализа систем могут разрабатываться различные модели: модели системного окружения, поведенческие модели и модели данных [9].

Модели системного окружения

Модели системного окружения служат для определения границ системы и строятся на ранних этапах выявления требований. Трудоемкость построения модели зависит от характера разрабатываемого приложения.

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

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

Поведенческие модели

При разработке требований к программной системе часто проще ответить на вопрос “как работает система?”, чем “что делает система?”. Ответ на этот вопрос дает модель поведения. (Заметим, что поведение реальной программной системы определяется кодом ее программы, таким образом, модель поведения – это описание алгоритма работы системы). Требования, предъявляемые к модели поведения, используемой на этапе разработки требований можно сформулировать следующим образом:

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

2. Средства моделирования поведения должны быть знакомы и привычны для большинства заинтересованных лиц.

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

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

Рассмотрим основные модели, используемые для описания общего поведения системы.