4.5.3.Графические нотации

Для описания требований применяются различные графические нотации. Наиболее часто используются уже рассмотренные графические средства: диаграммы потоков данных, модели конечных автоматов, диаграммы “сущность-связь”, сценарии, варианты использования, диаграммы использования, диаграммы состояний и диаграммы последовательности UML.

4.6.Документирование системных требований

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

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

1. Для кого преимущественно создаются системные требования?

2. У типичной программы есть несколько требований. Какая важная проблема существует при создании и работе с требованиями?

3. Какие категории системных требований должны быть описаны в спецификации?

4. Какими желательными свойствами должны обладать системные требования?

5. Чем характеризуются системные модели, используемые на этапе анализа?

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

7. Как методика прототипирования (экспериментального и эволюционного) связана с видом прототипа?

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

5.Документирование требований

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

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

Спецификация требований – это собой итоговый набор расположенных по приоритетам требований, который является формальным соглашением заказчика с разработчиком системы.

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

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

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

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

Введение

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

Часто во введении приводят краткое описание концепции системы, перечисляют различные группы пользователей спецификации и приводится рекомендуемая последовательность чтения разделов для них.

Общее описание

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

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

Пользователи. Приводят перечисление классов предполагаемых пользователей и их характеристики.

Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.

Ограничения реализации. Перечисляют все факторы, ограничивающие возможности разработчика, например:

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

• ограничения операционной среды, аппаратуры;

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

• соглашения, связанные с пользовательским интерфейсом, форматом обмена данными и т.д.

Функции системы

Для каждой функции системы должно быть указано:

• название и приоритет;

• системные входные и выходные данные, или последовательности «воздействие – реакция»;

• детальные функциональные требования;

• реакция на ошибки ввода данных или неверные действия пользователя.

Внешний интерфейс

Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:

• ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;

• конфигурация экрана, стандартные кнопки и функции навигации;

• стандарты отображения сообщений и т.д.

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

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

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

Кроме перечисленной информации, в спецификацию требований часто включают словарь терминов, которые пользователю необходимо знать для понимания спецификации, список нерешенных проблем, связанных с требованиями и т.д.