Основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

  1. Общие сведения
  2. Назначение и цели создания (развития) системы
  3. Характеристика объектов автоматизации
  4. Требования к системе
  5. Состав и содержание работ по созданию системы
  6. Порядок контроля и приемки системы
  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
  8. Требования к документированию
  9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

  1. Введение;
  2. Основания для разработки;
  3. Назначение разработки;
  4. Требования к программе или программному изделию;
  5. Требования к программной документации;
  6. Технико-экономические показатели;
  7. Стадии и этапы разработки;
  8. Порядок контроля и приемки;
  9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

  1. Введение
  2. Назначение
  3. Область действия
  4. Определения, акронимы и сокращения
  5. Ссылки
  6. Краткий обзор

  7. Общее описание

  8. Взаимодействие продукта (с другими продуктами и компонентами)
  9. Функции продукта (краткое описание)
  10. Характеристики пользователя
  11. Ограничения
  12. Допущения и зависимости

  13. Детальные требования (могут быть организованы по разному, н-р, так)

  14. Требования к внешним интерфейсам
  15. Интерфейсы пользователя
  16. Интерфейсы аппаратного обеспечения
  17. Интерфейсы программного обеспечения
  18. Интерфейсы взаимодействия
  19. Функциональные требования
  20. Требования к производительности
  21. Проектные ограничения (и ссылки на стандарты)
  22. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  23. Другие требования

  24. Приложения

  25. Алфавитный указатель

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

  1. Введение

  2. Назначение системы

  3. Содержание системы (границы системы)
  4. Обзор системы
  5. Содержание системы
  6. Функции системы
  7. Характеристики пользователей
  8. Термины и определения

  9. Ссылки

  10. Системные требования

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

  12. Требования к юзабилити
  13. Требования к производительности
  14. Интерфейс (взаимодействие) системы
  15. Операции системы
  16. Состояния системы
  17. Физические характеристики
  18. Условия окружения
  19. Требования к безопасности
  20. Управление информацией
  21. Политики и правила
  22. Требования к обслуживанию системы на протяжении ее жизненного цикла
  23. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

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

  25. Приложения

  26. Предположения и зависимости

  27. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

  1. Введение

  2. Назначение

  3. Содержание (границы)
  4. Обзор продукта
  5. Взаимодействие продукта (с другими продуктами и компонентами)
  6. Функции продукта (краткое описание)
  7. Характеристики пользователей
  8. Ограничения
  9. Термины и определения

  10. Ссылки

  11. Детальные требования

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

  13. Функции продукта
  14. Требования к юзабилити
  15. Требования к производительности
  16. Требования к логической структуре БД
  17. Ограничения проектирования
  18. Системные свойства ПО
  19. Дополнительные требования

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

  21. Приложения

  22. Предположения и зависимости

  23. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

  1. Введение.

  2. Цель.

  3. Краткая сводка возможностей.
  4. Определения, акронимы и сокращения.
  5. Ссылки.
  6. Краткое содержание.

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

  8. Обзор вариантов использований.

  9. Предположения и зависимости.

  10. Детальные требований

  11. Описание вариантов использования.

  12. Дополнительные требования.
  13. Другие функциональные требования.
  14. Нефункциональные требования.

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

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.


Источник