Документирование требований на основе IEEE Standard 830-1998

Рассмотрим шаблон документа описания требований, составленный К.Вигерсом [11.1] на основе стандарта [11.2]. Данный стандарт содержит развернутое описание требований, которое может быть оптимизировано для нужд конкретной организации.

1.3. Предполагаемая аудитория и рекомендации по последовательности работы с документом для каждого класса читателей.

1.4. Границы проекта. Здесь содержится ссылка на документ "Концепция", если таковой имеется, либо краткое резюме продукта.

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

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

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

2.4. Операционная среда. Рассматривается среда функционирования АИС, включая аппаратные средства, операционные системы, для распределенных систем - географическое расположение пользователей и серверов, топология сети.

2.5. Ограничения проектирования и реализации. Рассмотрим классификацию ограничений [11.1]:

Для каждой i-й функции составляется следующее описание.

З.i.1 Описание и приоритеты. Приводится краткое описание функции и указывается ее приоритет (степень важности/очередности реализации).

З.i.2 Последовательности "воздействие - реакция". Необходимо перечислить последовательность воздействий, оказываемых на систему (действия пользователей, сигналы внешних устройств и др.), и отклики системы, определяющие реакцию конкретной функции.

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

4. Требования к внешнему интерфейсу Ниже рассмотрены конкретные рекомендации по написанию разделов этого параграфа, согласно [11.1]: 4.1 Интерфейсы пользователя Основные характеристики UI:

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

4.2 Интерфейсы оборудования Опишите характеристики каждого интерфейса между компонентами ПО и оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые будут использоваться. 4.3 Интерфейсы ПО Опишите соединения продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Укажите назначение элементов сообщений, данных и элементов управления, обмен которыми происходит между компонентами ПО. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, к которым будут иметь доступ компоненты ПО. 4.4 Интерфейсы передачи информации Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности взаимодействия или шифрования, частоты передачи данных и механизмов синхронизации. 5. Другие нефункциональные требования В этом разделе описываются остальные нефункциональные требования, не относящиеся к требованиям к интерфейсу, которые представлены в разделе 4, и к ограничениям, описываемым в разделе 2.5. 5.1 Требования к производительности Укажите специальные требования к производительности для различных системных операций. Обоснуйте их необходимость для того, чтобы помочь разработчикам принять правильные решения, касающиеся дизайна. Например, из-за жестких требований к времени отклика базы данных разработчики могут зеркализовать базу данных в нескольких географических местоположениях или денормализовать связанные таблицы баз данных для получения более быстрого ответа на запрос.

Приложение А. Словарь терминов(глоссарий).
Приложение Б. Модели анализа. В этот раздел помещаются все модели, построенные в процессе анализа требований (см. материалы лекции 9).
Приложение В. Список вопросов.

Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные как "ТВD" (to be determined - необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п. Документирование требований в MSF В начале фазы проектирования проектная группа работает с проектными требованиями. Они подразделяются на:

бизнес-требования,
требования к эксплуатации,
системные требования,
требования пользователя.

Одним из основных результатов фазы проектирования является функциональная спецификация, которая служит:

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

С шаблонами соответствующих документов можно ознакомиться на сайте Microsoft, [11.3].