Гост 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. Краткий обзор
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
- 2. Функциональные требования
- 3. Требования к производительности
- 4. Проектные ограничения (и ссылки на стандарты)
- 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
- 6. Другие требования
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.
Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
- Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
- Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
- Правила составления Software requirements specification (читать вместе с комментариями)
- Примеры ТЗ и другой документации по разработке АС для МЭР
- ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
- Шаблоны документов для бизнес-аналитиков из
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79.
Правила оформления
Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
Лист утверждения и титульный лист
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Изменения и дополнения
Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Учесть все детали на начальном этапе разработки невозможно. На практике указанный подход применяется весьма часто. В разделе «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с Заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Строго по согласованию с Заказчиком. Согласие Заказчика обязательно должно быть отражено в тексте технического задания.
В качестве учебно-тренировочной будем использовать реальную программу с графическим пользовательским интерфейсом, обеспечивающую возможность выполнения нескольких шаблонных функций (например, несложный текстовый редактор).
Введение
В разделе указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
Основное правило работы с текстом – детализация, дробление текста на структурные единицы, подразделы, пункты и подпункты. Оглавление текста будет иметь четкую структуру, способствующую легкому поиску требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах Заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. Правку можно будет внести на этапе согласования технического задания с Заказчиком.
Основания для разработки
В разделе должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
В подразделе следует привести сведения, содержащиеся в Договоре.
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 15 марта 2004 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то марта 2008.
Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.
Постановлением Государственного комитета СССР по стандартам от 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.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
^
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
(Измененная редакция, Изм. № 1)
2.2. В разделе «Основания для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
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 г (ИУС 7-81)
ГОСТ 19.201-78
Группа Т55
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Единая система программной документации
ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
Unified system for program documentation. Technical specification for development. Requirements for contents and form of pressentation
МКС 35.080
Дата введения 1980-01-01
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79*.
________________
* Доступ к международным и зарубежным документам, упомянутым здесь, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru . - Примечание изготовителя базы данных.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68 , как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 .
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
(Измененная редакция, Изм. N 1).
2.1. В разделе "Введение" указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
2.2. В разделе "Основание для разработки" должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
2.1, 2.2 (Измененная редакция, Изм. N 1).
2.3. В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел "Требования к программе или программному изделию" должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
(Измененная редакция, Изм. N 1).
2.4.1. В подразделе "Требования к функциональным характеристикам" должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.
2.4.2. В подразделе "Требования к надежности" должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе "Условия эксплуатации" должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе "Требования к составу и параметрам технических средств" указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5 В подразделе "Требования к информационной и программной совместимости" должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
(Измененная редакция, Изм. N 1).
2.4.6. В подразделе "Требования к маркировке и упаковке" в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе "Требования к транспортированию и хранению" должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе "Требования к программной документации" должны быть указаны предварительный состав программной документации и, при необходимости, специальные требования к ней.
(Введен дополнительно, Изм. N 1).
2.5. В разделе "Технико-экономические показатели" должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6. В разделе "Стадии и этапы разработки" устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
2.7. В разделе "Порядок контроля и приемки" должны быть указаны виды испытаний и общие требования к приемке работы.
2.8. В приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. -
М.: Стандартинформ, 2010
Ключевым документом взаимодействия сторон (заказчик-исполнитель) является ТЗ – техническое задание на создание ПС. ТЗ является основным исходным документом для создания ПС и его приемки, определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик, но формально выдает ТЗ разработчику заказчик.
Техническое задание должно содержать следующие разделы:
· Введение.
· Основания для разработки.
· Назначение разработки.
· Требования к программе или программному изделию.
· Требования к программной документации.
· Стадии и этапы разработки.
· Технико-экономические показатели.
· Порядок контроля и приёмки.
В техническое задание допускается включать приложения.
В разделе «Основание для разработки» должны быть указаны:
· документ (документы), на основании которых ведется разработка;
· организация, утвердившая этот документ и дата его утверждения;
· наименование и (или) условное обозначение темы разработки.
Применительно к специфике учебного процесса основанием может служить задание на курсовое или дипломное проектирование, приказ по университету № _____ от ________ , договор № _____ от ________, и т.п.
В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное – чётко определить, для чего нужна эта программа. Например: программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
· требования к функциональным характеристикам;
· требования к надежности;
· условия эксплуатации;
· требования к составу и параметрам технических средств;
· требования к информационной и программной совместимости;
· требования к маркировке и упаковке;
· требования к транспортированию и хранению;
· специальные требования.
Иными словами, описывается то, что должна делать программа и как она должна выглядеть.
Требования к функциональным характеристикам
Здесь должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам. Описывается диагностика состояния системы и сообщения обо всех возникших ошибках. Например:
Программа должна позволять … вычислять … строить… создавать …
Исходные данные: текстовый файл с заданной …
Выходные данные: графическая и текстовая информация – результаты анализа системы…; текстовые файлы – отчеты о …
Сообщения об ошибках: ошибки ввода данных …; ошибки распределения памяти …; ошибки при обращении к аппаратуре …
Требования к надежности
Должны быть указаны требования к обеспечению надёжного функционирования: обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п. Например: программа должна работать с заданной расширенной матрицей инциденций исследуемого графа в соответствии с алгоритмом функционирования, выдавать сообщения об ошибках при неверно заданных исходных данных, поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
В простом случае (например, в программе для лабораторных работ) может использоваться вариант, при котором программа работает только с абсолютно корректными данными.
Условия эксплуатации
Должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала. Например: условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК. Программа должная быть рассчитана на непрофессионального пользователя и т.п.
Требования к составу и параметрам технических средств
Указываются необходимый состав технических средств с указанием их технических характеристик. Например:необходимо наличие IBM PC-совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 6 Мб, объём свободной оперативной памяти – не менее 1 Мб. Желательно наличие драйвера EMS и манипулятора типа «мышь».
Технические требования завышать не следует.
Требования к информационной и программной совместимости
Особенности те же, что и в предыдущем пункте. Здесь должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ. Например: программа должна работать автономно под управлением ОС Windows 95/98/XP. Базовый язык программирования – Delphi Pascal 6.0.
Требования к маркировке и упаковке
и требования к транспортированию и хранению
В общем случае здесь указывают требования к маркировке программного изделия, варианты и способы упаковки. А в требованиях к транспортированию и хранению должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
Специальные требования
Зачастую подразумеваются требования к временным и ёмкостным характеристикам ПС. Например: специальных требований к временным характеристикам программы не предъявляется. Специальных требований к ёмкостным характеристикам программы не предъявляется.
В разделе «Требования к программной документации» определяется предварительный состав программной документации и, при необходимости, специальные требования к ней.
В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также сроки разработки и состав исполнителей.
Здесь описываются стандартные этапы. Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.
Эскизный проект . На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатывается общее описание алгоритма, сам алгоритм, структура программы. Разрабатываются план мероприятий по разработке и внедрению программы.
Технический проект . Содержит разработанный алгоритм решения задачи, а также методы контроля исходной информации. Здесь же разрабатываются средства обработки ошибок и выдачи диагностических сообщений, определяются формы представления исходных данных и конфигурация технических средств.
Рабочий проект . На этой стадии осуществляется программирование и отладка программы, разработка программных документов, программы и методики испытаний. Подготавливаются контрольно-отладочные примеры. Окончательно оформляются документация и графический материал. Обычно указывается, что в ходе разработки программы должна быть подготовлена следующая документация:
· текст программы;
· описание программы;
· программа и методика испытаний;
· описание применения;
· руководство пользователя.
Графического материала в ТЗ может и не быть. Особенно тогда, когда не предусмотрен публичный доклад о результатах работы (например, в лабораторных работах). Но для курсовых и дипломных проектов этот пункт обязателен. Например: в ходе разработки программы должен быть подготовлен следующий графический материал:
· структура программы;
· формат представления входных данных программы;
· общая схема алгоритма (2 листа формата А0);
· основные вычислительные алгоритмы;
· пример работы программы.
Раздел «Технико-экономические показатели» в ТЗ присутствует далеко не всегда. Он нужен, прежде всего, тогда, когда целью является обоснование огромной эффективности и важности выполняемой работы. В этом разделе должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность (например: предполагаемое число обращений к комплексу в целом в год – 365 сеансов работы), экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Помимо этого желательно привести определение как сметной стоимости разработки программы, так и определение трудоёмкости программирования.
В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приёмке работы. Например: контроль и приемка разработки осуществляются на основе испытаний контрольно-отладочных примеров. При этом проверяется выполнение всех функций программы.
В Приложениях к техническому заданию, при необходимости, приводят:
· перечень научно-исследовательских и других работ, обосновывающих разработку;
· схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
· другие источники разработки.
В зависимости от размера и особенностей программы или программного изделия, допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.