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

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

Шаблон SRS, предложенный в RUP ^{1http://www-306.ibm.com/software/rational/} , по сути представляет собой контейнер, в который необходимо "упаковать" артефакты, полученные в процессе специфицирования требований (см. материалы "Классификация и специфицирование требований" ). Кроме того, SRS частично перекликается с документом "Видение" (см. материалы "Формирование видения" ). Шаблон удобен своей компактностью и лаконизмом.

1. Введение.

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

   1.2. Краткая сводка возможностей.

   1.3. Определения, акронимы и сокращения.

   1.4. Ссылки.

   1.5. Краткое содержание.
2. Обзор системы

   2.1. Обзор прецедентов. Содержит список имен и кратких описаний вариантов использования и акторов с иллюстрациями в виде диаграмм прецедентов.

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

   Предположением (assumption) называется положение, которое считается истинным при отсутствии доказательства или определяющей информации. [1].

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

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

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

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

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

1. Введение

   1.1 Назначение документа.

   1.2. Поддерживаемые соглашения.

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

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

   1.5. Ссылки.
2. Общее описание.

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

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

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

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

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

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

   2.6 Документация для пользователей.

   2.7 Предположения и зависимости
3. Функции системы

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

   З.i Наименование i-й функции системы.

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

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

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