1. Главная
  2. Блог
техническое задание стандарты разработки проектирование

Стандарты технического задания и разработки программ

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

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

ГОСТ 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. Алфавитный указатель

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

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. Приложения
    • Предположения и зависимости;
    • Аббревиатуры и сокращений;

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

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

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

  1. Введение
    • Назначение;
    • Содержание (границы);
    • Термины и определения;
  2. Ссылки
  3. Детальные требования
    • Требования к внешним интерфейсам;
    • Функции продукта;
    • Требования к юзабилити;
    • Требования к производительности;
    • Требования к логической структуре БД;
    • Ограничения проектирования;
    • Системные свойства ПО;
    • Дополнительные требования;
  4. Тестирование и проверка
  5. Приложения
    • Предположения и зависимости;
    • Аббревиатуры и сокращений;

RUP

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

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

  • Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт;
  • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):
  1. Введение
    • Цель;
    • Краткая сводка возможностей;
    • Определения, акронимы и сокращения;
    • Ссылки;
    • Краткое содержание;
  2. Обзор системы
    • Обзор вариантов использований;
    • Предположения и зависимости;
  3. Детальные требования
    • Описание вариантов использования;
    • Дополнительные требования;
    • Другие функциональные требования;
    • Нефункциональные требования;
  4. Вспомогательная информация

SWEBOK, BABOK

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

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

Если вы относитесь к числу мужчин, желающих получить удовольствие сексом с очаровательными индивидуалками, перейдите на веб-ресурс prostitutkibarnaulagid.date. Красивые индивидуалки со всего города готовы удовлетворить вас в кровати. | Установка натяжных потолков Иваново смотрите на http://www.ns-pro37.ru. | Построить натальную карту онлайн | Купить дом в сочи на http://www.kupit-dom-v-sochi.ru.