Гост 19.201 78 единая система программной документации. Как написать техническое задание по госту

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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. Алфавитный указатель

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

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

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
Правила составления Software requirements specification (читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из

Наименование:

Единая система программной документации.

Действует

Дата введения:

Дата отмены:

Заменен на:

Текст ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 19.201-78

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

Издание официальное

Стандартинформ

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

Unified system for program documentation.

Technical specification for development. Requirements for contents and form of pressentation

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 дата введения установлена

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в

документ не включать.

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

1.4. Техническое задание должно содержать следующие разделы: введение;

основания для разработки; назначение разработки;

требования к программе или программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки;

в техническое задание допускается включать приложения.

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

(Измененная редакция, Изм. № 1).

Издание официальное ★

Перепечатка воспрещена

) Издательство стандартов, 1978 © СТАНДАРТИНФОРМ, 2010

Издание (январь 2010 г.) с Изменением № 1, утвержденным в июне 1981 г. (ИУС 9-81).

С. 2 ГОСТ 19.201-78

2.1. В разделе “Введение” указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.2. В разделе “Основания для разработки” должны быть указаны: документ (документы), на основании которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения; наименование и (или) условное обозначение темы разработки.

2.1. 2.2. (Измененная редакция, Изм. № 1).

2.3. В разделе ’’Назначение разработки” должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел ’’Требования к программе или программному изделию” должен содержать следующие подразделы:

требования к функциональным характеристикам; требования к надежности; условия эксплуатации;

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

(Измененная редакция, Изм. № 1).

2.4.1. В подразделе ’’Требования к функциональным характеристикам” должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. и.

2.4.2. В подразделе ’’Требования к надежности” должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. и.).

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

2.4.4. В подразделе ’’Требования к составу и параметрам технических средств” указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5. В подразделе ’’Требования к информационной и программной совместимости” должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1).

2.4.6. В подразделе ’’Требования к маркировке и упаковке” в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе ’’Требования к транспортированию и хранению” должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

2.5а. В разделе ’’Требования к программной документации” должны быть указаны предварительный состав программной документации и, при необходимости, специальные требования к ней. (Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе ’’Порядок контроля и приемки” должны быть указаны виды испытаний и общие требования к приемке работы.

2.8. В приложениях к техническому заданию, при необходимости, приводят: перечень научно-исследовательских и других работ, обосновывающих разработку;

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

ГОСТ 19.001-77 Единая система программной документации. Общие положения
ГОСТ 19.005-85 Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения
ГОСТ 19.101-77 Единая система программной документации. Виды программ и программных документов
ГОСТ 19.102-77 Единая система программной документации. Стадии разработки
ГОСТ 19.103-77 Единая система программной документации. Обозначения программ и программных документов
ГОСТ 19.104-78 Единая система программной документации. Основные надписи
ГОСТ 19.105-78 Единая система программной документации. Общие требования к программным документам
ГОСТ 19.106-78 Единая система программной документации. Требования к программным документам, выполненным печатным способом
ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.202-78 Единая система программной документации. Спецификация. Требования к содержанию и оформлению
ГОСТ 19.301-79 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению
ГОСТ 19.401-78 Единая система программной документации. Текст программы. Требования к содержанию и оформлению
ГОСТ 19.402-78 Единая система программной документации. Описание программы
ГОСТ 19.403-79 Единая система программной документации. Ведомость держателей подлинников
ГОСТ 19.404-79 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению
ГОСТ 19.501-78 Единая система программной документации. Формуляр. Требования к содержанию и оформлению
ГОСТ 19.502-78 Единая система программной документации. Описание применения. Требования к содержанию и оформлению
ГОСТ 19.503-79 Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению
ГОСТ 19.504-79 Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению
ГОСТ 19.505-79 Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению
ГОСТ 19.506-79 Единая система программной документации. Описание языка. Требования к содержанию и оформлению
ГОСТ 19.507-79 Единая система программной документации. Ведомость эксплуатационных документов
ГОСТ 19.508-79 Единая система программной документации. Руководство по техническому обслуживанию. Требования к содержанию и оформлению
ГОСТ 19.601-78 Единая система программной документации. Общие правила дублирования, учета и хранения
ГОСТ 19.602-78 Единая система программной документации. Правила дублирования, учета и хранения программных документов, выполненных печатным способом
ГОСТ 19.603-78 Единая система программной документации. Общие правила внесения изменений
ГОСТ 19.604-78 Единая система программной документации. Правила внесения изменений в программные документы, выполненные печатным способом
ГОСТ 28195-89 Оценка качества программных средств. Общие положения
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ Р 56447-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для обработки и интерпретации данных сейсморазведки. Основные функциональные и технические требования
ГОСТ Р 56448-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для геологического моделирования месторождений. Основные функциональные и технические требования
ГОСТ Р 56450-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для гидродинамического моделирования систем сбора и подготовки углеводородов. Основные функциональные и технические требования
ГОСТ Р 55711-2013 Комплекс технических средств автоматизированной адаптивной ВЧ (КВ) дуплексной радиосвязи. Алгоритмы работы
ГОСТ Р 56566-2015 Информационные технологии. Оценка процессов. Часть 9. Профили целевого процесса
ГОСТ Р 55692-2013 Модули электронные. Методы составления и отладки тест-программ для автоматизированного контроля
ГОСТ Р 56449-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для гидродинамического моделирования месторождений. Основные функциональные и технические требования
ГОСТ Р 56413-2015 Информационные технологии. Европейские профили профессий ИКТ-сектора
ГОСТ Р ИСО/МЭК 15026-1-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь
ГОСТ Р ИСО/МЭК 15026-4-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла
ГОСТ Р 56920-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
ГОСТ Р 56921-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования
ГОСТ Р ИСО/МЭК 26555-2016 Системная и программная инженерия. Инструменты и методы технического менеджмента линейки продуктов
ГОСТ Р ИСО/МЭК 29155-1-2016 Системная и программная инженерия. Структура сопоставительного анализа эффективности выполнения проектов информационных технологий. Часть 1. Понятия и определения
ГОСТ Р 54360-2011 Лабораторные информационные менеджмент-системы (ЛИМС). Стандартное руководство по валидации ЛИМС
ГОСТ Р 54593-2011 Информационные технологии. Свободное программное обеспечение. Общие положения
ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р 53798-2010 Стандартное руководство по лабораторным информационным менеджмент-системам (ЛИМС)
ГОСТ Р ИСО/МЭК 15504-1-2009 Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь
ГОСТ Р ИСО/МЭК 15504-2-2009 Информационная технология. Оценка процесса. Часть 2. Проведение оценки
ГОСТ Р ИСО/МЭК 15504-3-2009 Информационная технология. Оценка процесса. Часть 3. Руководство по проведению оценки
ГОСТ Р 57098-2016 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса
ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры
ГОСТ Р 57101-2016 Системная и программная инженерия. Процессы жизненного цикла. Управление проектом
ГОСТ Р 57102-2016 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288
ГОСТ Р 57122-2016 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для проектирования строительства скважин. Основные функциональные и технические требования
ГОСТ Р 57193-2016 Системная и программная инженерия. Процессы жизненного цикла систем
ГОСТ Р ИСО/МЭК 15504-5-2016 Информационные технологии. Оценка процессов. Часть 5. Образец модели оценки процессов жизненного цикла программного обеспечения
ГОСТ 34009-2016 Средства и системы управления железнодорожным тяговым подвижным составом. Требования к программному обеспечению
ГОСТ Р 57318-2016 Системы промышленной автоматизации и интеграция. Применение и управление процессами системной инженерии
ГОСТ Р ИСО/МЭК 25001-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление
ГОСТ Р ИСО/МЭК 33004-2017 Информационные технологии. Оценка процесса. Требования к эталонным моделям процесса, моделям оценки процесса и моделям зрелости
ГОСТ Р ИСО/МЭК 15414-2017 Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия
ГОСТ IEC 60848-2016 Язык спецификаций GRAFCET для последовательных функциональных схем
ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию
ГОСТ Р ИСО/МЭК 33001-2017 Информационные технологии. Оценка процесса. Понятия и терминология
ГОСТ Р ИСО/МЭК 33002-2017 Информационные технологии. Оценка процесса. Требования к проведению оценки процесса
ГОСТ Р ИСО/МЭК 33003-2017 Информационные технологии. Оценка процесса. Требования к системам измерения процесса
ГОСТ Р ИСО/МЭК 33020-2017 Информационные технологии. Оценка процесса. Система измерения процесса для оценки возможностей процесса
ГОСТ Р 57640-2017 Информационные технологии. Эталонная модель процесса (ЭМП) для управления информационной безопасностью
ГОСТ Р ИСО/МЭК 30121-2017 Информационные технологии. Концепция управления рисками, связанными с проведением судебной экспертизы свидетельств, представленных в цифровой форме
ГОСТ Р 58041-2017 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Система стандартов по программному обеспечению для решения задач поиска, разведки и разработки месторождений. Основные положения и технические требования
ГОСТ Р 58042-2017 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Основные требования к исходным данным программных комплексов для решения задач поиска, разведки и разработки месторождений
ГОСТ Р ИСО/МЭК 10746-1-2004 Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения
ГОСТ Р ИСО/МЭК 10746-4-2004 Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

Единая система программной документации

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

United System for Program Documentation.
Technical specification for development.
Requirements to contents and form of presentation

ГОСТ
19.201-78*

(СТ СЭВ 1627-79)

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01.1980 г.

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют и верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

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

1.4. Техническое задание должно содержать следующие разделы:

наименование и область применения;

основание для разработки;

назначение разработки;

технические требования к программе или программному изделию;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

приложения.

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. №1).

2.2. В разделе «Основания для разработки» должны быть указаны:

документ (документы), на основании которых ведется разработка;

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. №1).

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

требования к функциональным характеристикам;

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

условия эксплуатации;

требования к составу и параметрам технических средств;

требования к информационной и программной совместимости;

требования к маркировке и упаковке;

требования к транспортированию и хранению;

специальные требования.

(Измененная редакция, Изм. №1).

2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.

2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5 В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. №1).

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

(Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8. В приложениях к техническому заданию, при необходимости, приводят:

перечень научно-исследовательских и других работ, обосновывающих разработку;

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

другие источники разработки.

* Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июне 1981 г. (ИЦС 9-81).

Стандарт полностью соответствует СТ СЭВ 1627-79.

Правила оформления

Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

Лист утверждения и титульный лист

Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.

Изменения и дополнения

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

Учесть все детали на начальном этапе разработки невозможно. На практике указанный подход применяется весьма часто. В разделе «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с Заказчиком».

Состав разделов технического задания

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

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

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

Задача рекомендаций - указать методику, дать практические рекомендации по разработке технического задания на программу (программное изделие) с учетом требований ГОСТ 19.201-78.

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

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

Введение

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

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

Наименование программы

Наименование – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

Программа предназначена к применению в профильных подразделениях на объектах Заказчика.

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

Основания для разработки

В разделе должны быть указаны:

документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.

В подразделе следует привести сведения, содержащиеся в Договоре.

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.

Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89 , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.

Функциональное назначение

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

В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т.д. – будут приведены ниже, в соответствующих разделах.

Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?

Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.

Применим формальный подход:

Требования к программе или программному изделию

Раздел должен содержать следующие подразделы:

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

Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

Требования к составу выполняемых функций

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

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

Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая действий оператора.

Требования к организации входных данных

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

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

Любой файл иного формата, но с расширением rtf, открываться не должен.

Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя, отформатированного, к примеру, в формате ext3, открываться не должны.

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

Требования к временным характеристикам программы не предъявляются.

Следует уточнить, предъявляет ли Заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если Заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств суперкомпьютер стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для Заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам (см. формулировку выше).

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

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

Надежность – вещь тонкая и очень опасная. Но перечень функций и видов их отказов, согласно п. 1.3.2. ГОСТ 24.701-86, обязан составить Заказчик и согласовать с Исполнителем. Скорее всего, дождаться от Заказчика чего-либо вразумительного не удастся. Стоит разъяснить Заказчику, что надежное функционирование программы зависит не столько от Исполнителя, сколько от надежности технических средств и операционной системы, а также предложить Заказчику ряд жестких мер для повышения надежности и устойчивости функционирования программы.

Требования к обеспечению надежного (устойчивого) функционирования программы

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

организацией бесперебойного питания технических средств;
использованием лицензионного программного обеспечения;
регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие компьютеpных виpусов.

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

Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТ) можно считать безотказное выполнение некой i-той функции в течение конкретного интервала времени. Предложим Заказчику считать критерием надежной работы программы следующий показатель: Заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст сбоев, требования по надежности считаются выполненными.

Если Заказчик, наконец, убедился, что надежность зависит не столько от Исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу:

Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.

Время восстановления после отказа

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

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

Перечень аварийных ситуаций ситуаций также составляет Заказчик и согласовывает с Исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.

Условия эксплуатации

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

Очень опасный подраздел.

Климатические условия эксплуатации

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

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90% и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но, как только в техническом задании окажется конкретика и задание будет утверждено, Заказчик получает отличный шанс заставить Исполнителя провести климатические испытания в полном объеме за счет Исполнителя.

Лет пятнадцать тому назад автор статьи, в силу своей молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал» на «климатику», причем «попал конкретно», на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!

Требования к видам обслуживания

или

Программа не требует проведения каких-либо видов обслуживания.

Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования».

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

Требования к численности и квалификации персонала

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

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

задача поддержания работоспособности технических средств;
задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
задача установки (инсталляции) программы.

Конечный пользователь программы (оператор) должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы.

Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).

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

Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к ПЭВМ и конторскому оборудованию. Мужики-то не знают, а прокурор - знает.

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

В подразделе указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
материнскую плату с FSB, ГГц - 5, не менее;
оперативную память объемом, Тб - 10, не менее;
и так далее…

Требования к информационным структурам и методам решения

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

или

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

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

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы. Допускается использование пакета обновления такого-то.

Требования к маркировке и упаковке

Программа поставляется в виде программного изделия - на дистрибутивном (внешнем оптическом) носителе (компакт-диске).

Речь идет о маркировке и упаковке дистрибутивного носителя - программного изделия (см. ГОСТ 19.004-80 ).

Требование к маркировке

Программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России (если таковой имеется).

Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.

Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача Исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).

Условия упаковывания

Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.

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

Порядок упаковки

Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.

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

Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.

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

На верхний слой прокладочного материала укладывается товаросопроводительная документация - упаковочный лист и ведомость упаковки.

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.

Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.

Габариты грузового места должны быть не более 1250 x 820 x 1180 мм.

Масса НЕТТО - не более 200 кг.

Масса БРУТТО - не более 220 кг.

В подразделе приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб.

Требования к транспортированию и хранению

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

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

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

Условия транспортирования и хранения

Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.

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

температура окружающего воздуха, °С - от плюс 5 до плюс 50;
атмосферное давление, кПа - такое-то;
относительная влажность воздуха при 25 °С - такая-то.

Требования к программной документации

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

ведомость эксплуатационных документов.

Программа и методики испытаний потребуются, чтобы показать Заказчику, что разработанная Исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний Заказчик и Исполнитель подпишут Акт приемки (сдачи) работы. И, тем самым, работа будет закрыта, условия Договора выполнены.

Ценное замечание поступило от Primadonna:

Согласно п. 2.6. ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов».

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

И еще одно ценное замечание от Primadonna:

Программная документация, входящая в предварительный перечень, должна быть оформлена согласно требований ГОСТ 19.106-78.

Технико-экономические показатели

Ориентировочная экономическая эффективность не рассчитываются.

Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

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

Идея позаимствована

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

$1500

$1000

$500

$11500

$1000

$10500

Стадии и этапы разработки

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

Стадии разработки и этапы регламентированы ГОСТ 19.102-77. ГОСТ 19.102-77 не препятствует исключению отдельных стадий работ, а также объединению отдельных этапов работ.

Стадии разработки

Разработка должна быть проведена в три стадии:

разработка технического задания;
рабочее проектирование;
внедрение.

Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

разработка программы;
разработка программной документации;
испытания программы.

На стадии внедрения должен быть выполнен этап разработки - подготовка и передача программы.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

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

На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 с требованием п. Предварительный состав программной документации настоящего технического задания.

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

разработка, согласование и утверждение программы (в ГОСТ, похоже, опечатка – «порядка») и методики испытаний;
проведение приемо-сдаточных испытаний;
корректировка программы и программной документации по результатам испытаний.

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

Порядок контроля и приемки

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

Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в сроки…

Приемо-сдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) Исполнителем и согласованной Заказчиком Программы и методик испытаний.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывают Акт приемки-сдачи программы в эксплуатацию.

Приложения

В приложениях к техническому заданию, при необходимости, приводят:

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

Если есть, почему не привести. И обязательно выложить перечень ГОСТ, на основании которых должна проводиться разработка. Например:

ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению;
и так далее...

Выводы

Настоящий стандарт, несмотря на свой 25-летний возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.

Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма и т.д. Указанные сведения должны быть отражены в Договоре.

Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».

Стандарт полностью соответствует СТ СЭВ 1627-79.

Правила оформления

Лист утверждения и титульный лист

Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Изменения и дополнения

Состав разделов технического задания

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

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

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

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

Введение

Наименование программы

Наименование – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

Программа предназначена к применению в профильных подразделениях на объектах Заказчика.

Основания для разработки

В разделе должны быть указаны:

Документ (документы), на основании которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения; наименование и (или) условное обозначение темы разработки.

В подразделе следует привести сведения, содержащиеся в Договоре.

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т. д.) № 000 от 01.01.01 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то марта 2008 .

Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.

Наименование и условное обозначение темы разработки

Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf».

Условное обозначение темы разработки (шифр темы) – «РТФ-007».

Назначение разработки

В разделе должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Функциональное назначение

В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т. д. – будут приведены ниже, в соответствующих разделах.

Резина одного типоразмера может успешно эксплуатироваться на Жигулях и Волгах, но не на КаМАЗе. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.

Применим формальный подход:

Эксплуатационное назначение

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

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

Требования к программе или программному изделию

Раздел должен содержать следующие подразделы:

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

Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию, к примеру, «ГОСТ. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

Требования к функциональным характеристикам

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

Требования к составу выполняемых функций

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

1. функции создания нового (пустого) файла.

2. функции открытия (загрузки) существующего файла.

4. функции редактирования текущего файла с применением буфера обмена операционной системы.

5. функции сохранения файла с исходным именем.

6. функции сохранения файла с именем, отличным от исходного.

7. функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы.

8. функции вывода оперативных справок в строковом формате (подсказок).

9. функции интерактивной справочной системы.

10. функции отображения названия программы, версии программы, копирайта и комментариев разработчика.

Требования к организации входных данных

Любой файл иного формата, но с расширением rtf, открываться не должен.

Файлы http:///file. rtf или ftp:///file. rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя, отформатированного, к примеру, в формате ext3, открываться не должны.

Требования к организации выходных данных

См. Требования к организации входных данных.

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

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

Требования к временным характеристикам программы не предъявляются.

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

Требования к обеспечению надежного (устойчивого) функционирования программы

Организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения; регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 01.01.01 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; регулярным выполнением требований ГОСТ. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие компьютеpных виpусов.

Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.

Время восстановления после отказа

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

Перечень аварийных ситуаций также составляет Заказчик и согласовывает с Исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.

Отказы из-за некорректных действий оператора

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

Условия эксплуатации

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

Климатические условия эксплуатации

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90% и атмосферном давлении 462 мм. рт. ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но, как только в техническом задании окажется конкретика и задание будет утверждено, Заказчик получает отличный шанс заставить Исполнителя провести климатические испытания в полном объеме за счет Исполнителя.

Требования к видам обслуживания

См. Требования к обеспечению надежного (устойчивого) функционирования программы.

Программа не требует проведения каких-либо видов обслуживания.

Требования к численности и квалификации персонала

Задача поддержания работоспособности технических средств; задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы; задача установки (инсталляции) программы.

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

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

Процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее; материнскую плату с FSB, ГГц - 5, не менее; оперативную память объемом, Тб - 10, не менее; и так далее…

Требования к информационной и программной совместимости

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

При необходимости должна обеспечиваться защита информации и программ.

Требования к информационным структурам и методам решения

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

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider.

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

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

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

Требования к маркировке и упаковке

Речь идет о маркировке и упаковке дистрибутивного носителя - программного изделия (см. ГОСТ 19.004-80).

Требование к маркировке

Требования к упаковке

Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя.

Именно предприятия-изготовителя. Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель тары.

Условия упаковывания

Порядок упаковки

Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 79согласно чертежам предприятия-изготовителя тары.

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

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ.

Габариты грузового места должны быть не более 1250 x 820 x 1180 мм.

Масса НЕТТО - не более 200 кг.

Масса БРУТТО - не более 220 кг.

Требования к транспортированию и хранению

Условия транспортирования и хранения

температура окружающего воздуха, °С - от плюс 5 до плюс 50; атмосферное давление, кПа - такое-то; относительная влажность воздуха при 25 °С - такая-то.

Специальные требования

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

Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.

Требования к программной документации

Состав программной документации предусмотрен ГОСТ 19.101-77.

Предварительный состав программной документации

Состав программной документации должен влючать в себя:

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

Технико-экономические показатели

Ориентировочная экономическая эффективность не рассчитываются.

Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

Экономические преимущества разработки

Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:

число рабочих мест

разработка

экономические преимущества

Стадии и этапы разработки

Стадии разработки

Разработка должна быть проведена в три стадии:

Разработка технического задания; рабочее проектирование; внедрение.

Этапы разработки

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

Разработка программы; разработка программной документации; испытания программы.

На стадии внедрения должен быть выполнен этап разработки - подготовка и передача программы.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

Постановка задачи; определение и уточнение требований к техническим средствам; определение требований к программе; определение стадий, этапов и сроков разработки программы и документации на неё; выбор языков программирования; согласование и утверждение технического задания.

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

Разработка, согласование и утверждение программы (в ГОСТ, похоже, опечатка – «порядка») и методики испытаний; проведение приемо-сдаточных испытаний; корректировка программы и программной документации по результатам испытаний.

Порядок контроля и приемки

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

Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в сроки…

Общие требования к приемке работы

Приложения

В приложениях к техническому заданию, при необходимости, приводят:

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

ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению; и так далее...

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.

ГОСТ 19.201-78

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

United System for Program Documentation.
Technical specification for development.
Requirements to contents and form of presentation

ГОСТ
19.201-78

с 01.01.1980 г.

1 . ОБЩИЕ ПОЛОЖЕНИЯ

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

1.4 . Техническое задание должно содержать следующие разделы:

наименование и область применения;

основание для разработки;

назначение разработки;

технические требования к программе или программному изделию;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

приложения.

2 . СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1 . В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.2 . В разделе «Основание для разработки» должны быть указаны:

документ (документы), на основании которых ведется разработка;

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки.

2.3 . В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4 . Раздел «Технические требования к программе или программному изделию» должен содержать следующие подразделы:

требования к функциональным характеристикам;

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

условия эксплуатации;

требования к составу и параметрам технических средств;

требования к информационной и программной совместимости;

требования к маркировке и упаковке;

требования к транспортированию и хранению;

специальные требования.

2.4.1 . В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.

2.4.2 . В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

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

2.4.4 . В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

При необходимости должна обеспечиваться информации и программ.

2.4.6 . В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7 . В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

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

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

2.7 . В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8 . В приложениях к техническому заданию, при необходимости, приводят:

перечень научно-исследовательских и других работ, обосновывающих разработку;

другие источники разработки.