Введение


Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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. Введение
  • 1. Назначение
  • 2. Область действия
  • 3. Определения, акронимы и сокращения
  • 4. Ссылки
  • 5. Краткий обзор

2. Общее описание
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователя
  • 4. Ограничения
  • 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)
  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3. Требования к производительности
  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

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. Введение

  • 1. Назначение системы
  • 2. Содержание системы (границы системы)
  • 3. Обзор системы
    • 1. Содержание системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки

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

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

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

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

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

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

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

1. Введение

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

2. Ссылки

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

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

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

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

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

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

RUP


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

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

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

1. Введение.

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

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

  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

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

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

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

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.


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

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

А как же Agile?


Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение


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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Поделиться с друзьями
-->

Комментарии (18)


  1. LynXzp
    17.05.2017 00:35
    +1

    I want to.
    Удивительно что такие стандарты существуют. А по моему скромному опыту проблем больше с договорами, на которые уделяют гораздо меньше внимания.


    1. Carbonade
      17.05.2017 12:24
      +1

      Это лучше, чем ТЗ в устном виде, переданном через цепь «заказчик — инженер внедрения — разработчик».


  1. tas
    17.05.2017 11:25
    +1

    Естественно ГОСТ 34 (и 19) уже устарели


    Да ладно! Может Вы их просто готовить не умеете?

    Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно, расширяя и дополняя то, что есть, тем, чего не хватает!

    Вопрос разработки документации по ГОСТ больше в том — на сколько полной должна быть формализация проекта и хватит ли на это ресурсов?


    1. bocharovf
      17.05.2017 13:33

      Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно

      Поддерживаю.
      Во-первых никто не запрещает вводить дополнительные пункты или подпункты ТЗ.
      Во-вторых я лично для некоторых бессмысленных в рамках разработки ПО разделов типа «Требования к упаковке» пишу что-то вроде «По согласованию с клиентом пункт исключен из ТЗ» или «Специальные требования не предъявляются»


    1. bas
      17.05.2017 14:13
      +1

      Я то как раз умею их готовить. А вот многие начинающие (и не только) Аналитики с трудом справляются с ГОСТом. Чего только стоит посмотреть выложенные ТЗ для МЭР. Я просто люблю более конкретные (западные) шаблоны, которые ориентированы на коммерческие реалии. Вот дано вы писали требования к метрологическому обеспечению, транспортабельности или защите от влияния внешних воздействий?

      И опять же фраза вырванная из контекста не дает полное представление о том, что я хотел донести. Вот например в конце я пишу:

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

      содержание (наполнение) в ТЗ — самое главное!


  1. UporotayaPanda
    17.05.2017 12:24

    Добрый вечер!
    Спасибо за статью, очень во время. Для диплома осталось оформить правильно ТЗ на ПО, уже начал по крупицам собирать информацию, а тут сборка основных стандартов!


  1. md_axel
    17.05.2017 12:24

    В фармацевтике используется руководство GAMP5( http://www.ispe.org/gamp-5), в котором есть много чего и тоже есть требования к написанию ТЗ, которое называется URS. По ссылке http://www.gmpua.com/GAMP/GAMP.htm есть перевод приложения из GAMP, относящегося к URS.


  1. hdg_79
    17.05.2017 12:24

    Все проблемы с договорами вытекают из-за непроработанного ТЗ или вообще от его отсутствия.


  1. bas
    17.05.2017 15:11

    .


  1. SW39
    17.05.2017 15:11
    +1

    К ГОСТ 34 обязательно добавлять РД50, где приводится содержание документов, указанных в ГОСТ.


    1. bas
      17.05.2017 15:11

      Как РД50 относится к ТЗ?


      1. SW39
        17.05.2017 15:38

        Приложение №1 — проведение работ перед созданием ТЗ. Часто результатом является раздел ТЗ с описанием-постановкой задачи.

        Так же часто Эскизный проект (разделы 2.1-2.6 РД50) является синонимом ТЗ в понимании заказчика, если это не гос.заказчик.


  1. Little_CJIOH
    17.05.2017 17:45
    +1

    Long time ago in far galaxy…
    http://gaperton.livejournal.com/49867.html


    1. bas
      17.05.2017 17:45

      Спасибо. Дополню ссылкой


  1. alexhott
    17.05.2017 17:52

    На моей практике все ТЗ были по структуре ближе к ГОСТам.
    Самая основная проблема это всегда функциональные требования.
    В большинстве случаев они меняются очень сильно после появления прототипа.
    И это закладывается во все более менее крупные проекты, иначе созданное ПО тупо будет выброшено в помойку.


  1. peacemakerv
    17.05.2017 20:44

    А моя задумка формализовать составление ТЗ в виде иерархического списка (ht_tps://androrder.xyz/h4w), похоже, фигня — пользователи регистрируются, пробуют создать тестовый проект, и бросают…


    1. bas
      26.05.2017 17:44

      А какую проблему вы пытались решить? Ворд не подходит для этого?


      1. peacemakerv
        26.05.2017 17:50

        Подходит, а проблема тут одна — сподвигнуть заказчиков хоть в каком-то виде описать то, что им нужно. Вот думал может хоть разбивая на мелкие куски будет им проще, но… failed.