Многие шаблоны спецификации требований основаны на стандартах IEEE 830. Структура спецификации требований, определенная IEEE 830-1993 приведена на рис. 5.1.

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

Рис. 5.1

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

Раскроем подробнее содержание основных разделов спецификации, определенное в IEEE 830-1993.

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

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

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

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

· Описать функции каждого компонента большой системы и определить их интерфейсы.

· В общих чертах определить внешний интерфейс данного продукта.

· Выполнить обзор аппаратных средств, на которых будет функционировать продукт.

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

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

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

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

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

Содержит общее описание элементов, ограничивающих действия разработчиков:

· аппаратные ограничения;

· интерфейсы с другими приложениями;

· функции контроля;

· требования к языку и т.д.

Стандарт IEEE 830-1998 предполагает несколько способов структурирования функциональных требований. Требования могут быть организованы при помощи следующих классификаций.

1.По основным свойствам. Предоставляемые программой сервисы определяются с помощью пар «стимул – реакция».

2.По режиму работы, например, демонстрационный, нормальный или аварийный режимы;

3.По вариантам использования, или сценариям. Особенность такой организации требований в том, что наиболее подробные требования являются частью варианта использования;

4.По классам. В этом объектно-ориентированном способе требования классифицируются по классам.

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

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

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

Организация требований по классам

В настоящее время наиболее востребован объектно-ориентированный стиль проектирования. В этом случае обычно используется организация требований по классам.

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

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

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

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

Такая организация требований может быть описана при помощи шаблона, приведенного на рис. 5.2.

Рис. 5.2

В литературе [1, 4, 6, 9, 10] приведено большое число шаблонов спецификации требований. Например [10], шаблон, в котором интерфейсные требования привязаны к отдельным функциональным требованиям или шаблон, где все требования определены в связи с отдельными функциональными требованиями.

Большое число шаблонов, а также возможность добавления, объединения и исключения разделов стандартов IEEE 830 позволяет выбрать или построить шаблон спецификации требований для каждого конкретного проекта.

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

1.Какая информация вносится в спецификацию требований?

2.Кто основные читатели спецификации?

3.Какие рекомендации по документированию требований должны быть выполнены?

4.Зачем разрабатываются шаблоны спецификации?

5.От чего зависит тип применяемого шаблона?

6.На основе каких стандартов разрабатываются шаблоны?

7.Какие классификации могут быть использованы для организации требований?

8.В чем особенности организации требований по классам?

6. Анализ спецификации требований

Изучив тему, Вы будете знать:

§ характеристики качества, предъявляемые спецификации требований;

§ методы;

§ методику тестирования требований.

При освоении темы необходимо акцентировать внимание:

§ на определении характеристик качества;

§ на методах и средствах аттестации требований;

§ на методах планирования тестирования требований.

6.1. Оценка качества спецификации требований

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