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

Описание требований к системе в соответствие с ГОСТ 34.602-89

ГОСТ разделяет все требования к системе на три класса:

• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения.

Среди требований к системе в целом (системные требования) указываются требования к:

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

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

Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на:

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

Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает математическое, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое.

Шаблон SRS, предложенный в RUP ¹⁾, по сути представляет собой контейнер, в который необходимо "упаковать" артефакты, полученные в процессе специфицирования требований (см. материалы лекции 8). Кроме того, SRS частично перекликается с документом "Видение" (см. материалы лекции 7). Шаблон удобен своей компактностью и лаконизмом.

1. Введение.

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

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

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

1.4. Ссылки.

1.5. Краткое содержание.

1. Обзор системы

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

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

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

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

1. Описание требований

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

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

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

Дата добавления: 2014-11-29