lekciya_8

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

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

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

• Описывать только внешнее поведение системы.

• Указывать ограничения, накладываемые на процесс реализации cистемы.

• Предусматривать возможность внесения изменений в спецификацию.

• Служить справочным средством в процессе сопровождения системы.

• Отображать весь жизненный цикл системы.

• Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. В монографии описаны некоторые из этих стандартов, а также проведено их сравнение. Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 .

1. Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

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

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

5. Указатели

Хотя стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации - разработчике ПО. В табл. 5.4 описаны возможные разделы спецификации, построенной на основании стандарта IEEE.

Таблица 5. 4. Структура спецификации требований

Раздел	Описание
Предисловие	Здесь определяется круг лиц, на которых рассчитан данный документ. Описываются предыдущие версии разрабатываемого программного продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта
Введение	Здесь более развернуто обосновывается необходимость создания системы. Кратко перечисляются системные функции и объясняется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы "вписывается" в общую бизнес-стратегию компании, заказывающей программный продукт
Глоссарий	Дается описание технических терминов, используемых в документе. Здесь не делается каких-либо предположений об уровне знаний или практическом опыте читателя документа
Пользовательские требования	Описываются сервисы, предоставляемые пользователям, и нефункциональные системные требования. Это описание может быть сделано на естественном языке с использованием диаграмм, блок-схем и других форм записи, понятных заказчику программной системы. Здесь также должны быть приведены стандарты на программный продукт и процесс его разработки
Системная архитектура	Здесь приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (т.е. уже существующие) компоненты
Системные требования	Подробно описываются функциональные и нефункциональные требования. Если необходимо, нефункциональные требования дополняются описанием интерфейсов других систем
Системные модели	Здесь представлено несколько системных моделей, показывающих взаимоотношения между системными компонентами и между системой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных
Эволюция системы	Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п.
Приложения	Здесь приводится специализированная информация, относящаяся к разрабатываемой системе, например описание аппаратных средств или базы данных, с которыми должна работать система. При описании аппаратных средств необходимо показать минимальную и оптимальную конфигурации, при которых может работать программная система. Описание базы данных должно отображать логическую структуру данных, с которыми будет работать система, и отношения между ними
Указатели	В документе возможно использование различных указателей. Это может быть обычный алфавитный указатель, указатель диаграмм или указатель системных функций

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

Содержание