Стандарт ieee 830-1998

(Пересмотр стандарта IEEE 830-1993)

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

Этот подраздел должен:

а) Представить полный список всех документов, на которые делаются ссылки в других местах SRS;

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

в) Определить источники, из которых могут быть получены ссылки.

Эту информацию можно обеспечить ссылкой на приложение или другой документ.

Этот подраздел должен:

а) Описать, какие оставшиеся части содержатся в SRS;

б) Объяснить, как организована SRS.

Этот раздел SRS должен описывать общие факторы, которые влияют на программное изделие (-я) и требования, предъявляемые к нему. Этот раздел не устанавливает конкретные требования. Вместо этого, он обеспечивает предварительные сведения о тех требованиях, которые подробно определяются в разделе 3 SRS, и делает их более простыми для понимания.

Этот раздел обычно состоит из шести подразделов, а именно:

а) Перспектива изделия;

б) Функции изделия;

в) Характеристики пользователей;

г) Ограничения;

д) Допущения и зависимости;

е) Разделение требований.

5.2.1 Перспектива изделия ( Подраздел 2.1 SRS)

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

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

12 Авторское право © 1998 IEEE. Все права сохранены.

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993).

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

а) Системные интерфейсы;

б) Интерфейсы пользователя;

в) Аппаратные интерфейсы;

г) Интерфейсы программного обеспечения;

д) Интерфейсы связи;

е) Память;

ж) Операции;

з) Требования по адаптации места использования.

5.2.1.1 Системные интерфейсы

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

Этот подраздел должен указывать следующее:

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

б) Все аспекты оптимизации интерфейса с пользователем, который должен использовать систему.

Они могут просто включать список разрешений и запрещений различных способов представления системы пользователю. Одним из примеров может быть требование, предъявляемое к опции длинных или коротких сообщений об ошибках. Подобно всем другим, эти требования должны быть проверяемыми, например, "машинистка 4-го класса может выполнить задачу X через Z минут после 1 часа тренировки", а не "машинистка может выполнить задачу Х" (Это также может быть определено в Атрибутах Системы Программного Обеспечения в разделе, озаглавленном Простота использования)

5.2.1.3 Аппаратные интерфейсы

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

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

• 
  Имя;
  
• 
  Мнемонический код;
  
• 
  Номер спецификации;
  
• 
  Номер версии;
  
• 
  Источник.
  

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

Для каждого интерфейса необходимо обеспечить следующее:

а) Обсуждение назначения интерфейса программного обеспечения в отношении программного изделия.

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

Этот подраздел должен определять различные интерфейсы связи, такие как локальные сетевые протоколы и т.д.

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

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

а) Различные режимы операций в организации пользователя (например, операции, инициализируемые пользователем);

б) Периоды интерактивных операций и периоды автоматических операций;

в) Функции поддержки обработки данных;

г) Операции по резервированию и восстановлению.

ПРИМЕЧАНИЕ - Этот подраздел иногда указывается как часть раздела Интерфейсы пользователя.

5.2.1.8 Требования к адаптации места использования

Этот подраздел должен:

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

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

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

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

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

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

14 Авторское право © 1998 IEEE. Все права сохранены.

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

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

а) Регулирующие политики;

б) Аппаратные ограничения (например, требования к синхронизации сигналов);

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

г) Параллельные операции;

д) Функции контроля;

е) Функции управления;

ж) Требования к языку более высокого порядка;

з) Протоколы квитирования сигналов (например, XON-XOFF..ACK-NACK);

и) Требования к надежности;

к) Критичность применения;

л) Критерии безопасности и защиты.

5.2.5 Допущения и зависимости (Подраздел 2.5 SRS)

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

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

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

а) Специфические требования должны быть сформулированы в соответствии со всеми характеристиками, описанными в пункте 4.3.

б) Специфические требования должны иметь перекрестные ссылки к более ранним документам, к которым они имеют отношение.

в) Все требования должны быть однозначно идентифицируемы.

г) Необходимо уделить особое внимание оформлению требований, чтобы максимизировать их удобочитаемость.

Авторское право © 1998 IEEE. Все права сохранены. 15

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

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

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

Он должен включать содержание и формат следующим образом:

а) Наименование позиции;

б) Описание назначения;

в) Источник входных данных или адресат выходных данных;

г) Допустимый диапазон, точность и/или допуск;

д) Единицы измерения;

е) Синхронизация;

ж) Связи с другими входами/выходами;

з) Форматы/организация экрана;

и) Форматы/организация окна;

к) Форматы данных;

л) Форматы команд;

м) Сообщения о конце.

5.3.2 Функции

Функциональные требования должны определять фундаментальные операции, которые должны выполняться программным обеспечением при принятии и обработке входных данных и обработке и генерации выходных данных. Они обычно перечисляются как формулировки типа "должно", начинающиеся с "Система должна ....,".

Они включают:

а) Проверку достоверности по входам;

б) Точную последовательность операций;

в) Отклики на ненормальные ситуации, включая:

1. 
   Переполнение
   
2. 
   Средства связи
   
3. 
   Обработка и устранение ошибок;
   

д) Связь выходов с входами, включая:

1. 
   Последовательности ввода/вывода
   
2. 
   Формулы для преобразования ввода-вывода..
   

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

а) Число поддерживаемых терминалов;

б) Число одновременно поддерживаемых пользователей;

в) Количество и тип обрабатываемой информации.

15 Авторское право © 1998 IEEE. Все права сохранены.

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

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

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

Все эти требования должны быть установлены в измеряемых терминах. Например,

95 % групповых операций должно обрабатываться не более чем за 1 с. а не

Оператор не должен ждать завершения групповой операции.

ПРИМЕЧАНИЕ - Числовые ограничения, применяемые к одной определенной функции, обычно указываются как часть описания подпункта по обработке этой функции.

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

а) Типы информации, используемой различными функциями;

б) Частота использования;

в) Возможности доступа;

г) Информационные объекты и их связи;

д) Ограничения целостности;

е) Требования к сохранности данных.

Здесь должны указываться проектные ограничения, которые могут налагаться другими стандартами, аппаратными ограничениями и т.д.

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

а) Формат отчета;

б) Поименование данных;

в) Процедуры учета;

г) Контроль трассировки.

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

5.3.6 Атрибуты системы программного обеспечения

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

Авторское право © 1998 IEEE. Все права сохранены. 17

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

5.3.6.1 Надежность

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

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

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

а) Использовании некоторых методов криптографии;

б) Сохранении специфического файла регистрации или наборов данных истории;

в) Назначении некоторых функций различным модулям;

г) Ограничении связи между некоторыми областями программы;

д) Проверке целостности данных для критических переменных.

5.3.6.4 Удобство сопровождения

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

Этот подраздел должен определять атрибуты программного обеспечения, которые относятся к простоте перенесения программного обеспечения на другие главные машины и/или операционные системы. Они могут включать следующее:

а) Процентное соотношение компонентов с кодом, зависящим от главной машины;

б) Процентное соотношение кода, зависящего от главной машины;

в) Использование языка переноса программ;

г) Использование определенного компилятора или подмножества языка;

д) Использование определенной операционной системы.

5.3.7 Организация специфических требований

Для нетривиальных систем имеется тенденция к расширению детализированных требований. По этой причине рекомендуется тщательно рассмотреть их организацию таким способом, который будет оптимальным для понимания. Не существует одного оптимального способа организации для всех систем. В разделе 3 SRS представлены различные способы организации требований для различных классов систем. Некоторые из них описаны в пунктах с 5.3.7.1 по 5.3.7.7.

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

18 Авторское право © 1998 IEEE. Все права сохранены.

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

5.3.7.2 Класс пользователей

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

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

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

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