Ieee 830-1993 Методика составления спецификаций требований к программному



страница4/4
Дата02.06.2018
Размер0,76 Mb.
1   2   3   4

5.3.3 Требования к рабочим характеристикам

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

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

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

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

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

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

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

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

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

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

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

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

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



5.3.4 Логические требования к базе данных

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

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

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

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

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

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

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

5.3.5 Проектные ограничения

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

5.3.5.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.2 Доступность

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

5.3.6.3 Защита

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

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

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

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

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

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

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

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

5.3.6.5 Мобильность

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

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

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

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

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

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

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

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

5.3.7.1 Режим системы

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

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

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

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

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

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

5.3.7.3 Объекты

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

5.3.7.4 Свойство

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



5.3.7.5 Стимул

с

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

5.3.7.6 Отклик

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

5.3.7.7 Функциональная иерархия

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

5.3.8 Дополнительные комментарии

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



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

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

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

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

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

В любой из схем, представленных в Приложениях с А..1 по А.8, разделы, озаглавленные "Функциональное требование", могут быть описаны на оригинальном языке (например, английском), в псевдокоде, на языке определений системы или в четырех подразделах, озаглавленных: Введение, Входные данные, Обработка и Выходные данные.



5.4 Вспомогательная информация

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



а) Содержание;

б) Алфавитный указатель;

в) Приложения.

5.4.1 Содержание и алфавитный указатель

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

5.4.2 Приложения

Приложения не всегда рассматриваются как часть фактической SRS и не всегда необходимы. Они могут включать:



а) Типовые форматы ввода/вывода, описания исследования калькуляции себестоимости или результаты пользовательских обзоров;

б) Дополнительную или предварительную информацию, которая может помочь читателям SRS;

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

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

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

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


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

о

Приложение А



(информационное)

Шаблоны SRS

А.1 Шаблон раздела 3 SRS, организованного по режимам: Версия 1

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Функциональные требования

3.2.1 Режим 1

3.2.1.1 Функциональное требование 1.1

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



(Пересмотр стандарта

IEEE 830-1993)




3.2.2

3.2.1.n Функциональное требование 1..п Режим 2



3.2..т Режим m

3.2.7m.1 Функциональное требование от m..1

3.2.т.п Функциональное требование т.п

  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

А.2 Шаблон раздела 3 SRS, организованного по режимам: Версия 2

3. Специфические требования 3.1 Функциональные требования 3.1.1 Режим 1

3.1.1.1 Внешние интерфейсы


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.1.1.2 Функциональные требования

3.1.1.2.1 Функциональное требование 1



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

21


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

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

3.1.1.2.n Функциональное требование п

3.1.1.3 Рабочие характеристики

3.1.2 Режим 2

3.1 Режим т


  1. Проектные ограничения

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

  3. Другие требования

А.З Шаблон раздела 3 SRS, организованного по классам пользователей

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Функциональные требования

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

3.2.1.1 Функциональное требование 1.1

3.2.1.п Функциональное требование 1.п 3.2.2 Класс пользователей 2

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

3.2.m.1 Функциональное требование т..1

3.2.m..n Функциональное требование т.п


  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

А.4 Шаблон раздела 3 SRS, организованного по объектам

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Классы/Объекты

3.2.1 Класс/Объект1

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

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



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

3.2.1.1 Атрибуты (прямые или унаследованные) 3.2.1.1.1 Атрибут 1

3.2.1.1.n Атрибут n

3.2.1.2 Функции (услуги, методы, прямые или унаследованные) 3.2.1.2.1 Функциональное требование 1.1

3.2.1.2.m Функциональное требование l.m

3.2.1.3 Сообщения (полученные или отправленные)

3.2.2 Класс/Объект 2

3.2..р Кл асе/Объект р


  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

А.5 Шаблон раздела 3 SRS, организованного по свойствам

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Свойства системы

3.2.1 Свойство системы 1



  1. Введение/Назначение свойства

  2. Последовательность стимулов/откликов

  3. Ассоциированные функциональные требования

3.2.1.3.1 Функциональное требование 1

3.2.1.3.n Функциональное требование п

3.2.2 Свойство системы 2

3.2.m Свойство системы т


  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

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

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



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

А.6 Шаблон раздела 3 SRS, организованного по стимулам

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Функциональные требования

3.2.1 Стимул 1

3.2.1.1 Функциональное требование 1.1

3.2.1.n Функциональное требование 1..п 3.2.2 Стимул 2

3.2.т Стимул m

3.2.7m.1 Функциональное требование т. 1

3.2.т.п Функциональное требование т.п


  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

А.7 Шаблон раздела 3 SRS, организованного по функциональной иерархии

3. Специфические требования

3.1 Требования к внешним интерфейсам


  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

3.2 Функциональные требования

3.2.1 Информационные потоки

3.2.1.1 Схема потока данных 1


  1. Информационные объекты

  2. Релевантные потоки

  3. Топология

3.2.1.2 Схема потока данных 2

  1. Информационные объекты

  2. Релевантные потоки

  3. Топология

3.2.1.n Схема потока данных п

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



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

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



(Пересмотр стандарта

IEEE 830-1993)



3.2.1.n.1 Информационные объекты

3.2.1.n..2 Релевантные потоки



3.2.1.n.З Топология

3.2.2 Описания процессов



3.2.2.1 Процесс 1

  1. Объекты входных данных

  2. Алгоритм или формула процесса

  3. Объекты обрабатываемых данных

3.2.2.2 Процесс 2

  1. Объекты входных данных

  2. Алгоритм или формула процесса

  3. Объекты обрабатываемых данных

  1. 3.2.3

  2. 3.2.2.m Процесс т

  3. 3.2.2.m..l Объекты входных данных m.1,

  4. 3.2.2.т.2 Алгоритм или формула процесса

  5. 3.2.2 тЗ Объекты обрабатываемых данных Спецификации структуры данных

  6. 3.2.3.1 Структура 1

  1. Тип записи

  2. Составляющие подя

  1. 3.2.3.2 Структура 2

  2. 3..2.3.2.1 Тип записи 3.2.3.2.2 Составляющие поля

  1. 3.2.3.p Структура р

  2. 3.2.3.p.1 Тип записи

  3. 3.2.3.p.2 Составляющие поля

  4. 3.2.4 Словарь данных

  5. 3.2.4.1 Элемент данных 1

  1. Имя

  2. Представление

  3. Единицы/Формат

  4. Разрядность/Точность

  5. Диапазон

  1. 3.2.4.2 Элемент данных 2

  1. Имя

  2. Представление

  3. Единицы/Формат

  4. Разрядность/Точность

  5. Диапазон

  1. 3.2.4.q Элемент данных q

  2. 3.2.4.q.1 Имя

  3. 3.2.4. q.2 Представление

  4. 3.2.4. q.3 Единицы/Формат

  5. 3.2.4. q.4 Разрядность/Точность

  6. 3.2.4. q.5 Диапазон

  1. Авторское право © 1998 IEЕЕ. Все права сохранены.

  2. 25

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

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

  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

  1. А.8 Шаблон раздела 3 SRS, показывающий множественную организацию

  2. 3. Специфические требования

  3. 3.1 Требования к внешним интерфейсам

  1. Интерфейсы пользователя

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

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

  4. Интерфейсы связи

  1. 3.2 Функциональные требования

  2. 3.2.1 Класс пользователей 1 3.2.1.1 Свойство 1.1

  1. Введение/Назначение свойства

  2. Последовательность стимулов/откликов

  3. Ассоциированные функциональные требования
    3.2.1.2 Свойство 1.2



  1. Введение/Назначение свойства

  2. Последовательность стимулов/откликов
    3.2.1.2..3 Ассоциированные функциональные требования

  1. 3.2.1.т Свойство 1..т

  2. 3.2.1. т..1Введение/Назначение свойства

  3. 3.2.1. т ..2Последовательность стимулов/откликов
    3.2.1. т.З Ассоциированные функциональные требования

  4. 3.2.2 Класс пользователей 2

  5. 3.2.n Класс пользователей п

  1. Требования к рабочим характеристикам

  2. Проектные ограничения

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

  4. Другие требования

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


Поделитесь с Вашими друзьями:
1   2   3   4


База данных защищена авторским правом ©grazit.ru 2017
обратиться к администрации

    Главная страница