Wiki для разработчиков технической документации

Техническое задание

wiki → Техническое задание  
Чтобы стать редактором Wiki оставьте заявку в произвольной форме на форуме 



Техническое задание

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

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

Общие положения

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:


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

Содержание разделов

Раздел: Наименование и область применения

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

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

  • документ (документы), на основании которых ведется разработка;
  • организация, утвердившая этот документ, и дата его утверждения;
  • наименование и (или) условное обозначение темы разработки.
Например, Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___., и т.п.





Раздел: Назначение разработки

В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное – четко определить, для чего нужна эта программа.

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

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

В этом разделе должны содержаться следующие подразделы:

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

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

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

Например: Программа должна позволять … вычислять … строить… создавать …

Исходные данные : текстовый файл с заданной …

Выходные данные : графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

Здесь "выгадать" что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.

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

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

С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.

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

Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

Специальные требования – это весьма ответственная вещь. Их лучше, по возможности, всячески избегать. И заявить об этом сразу.

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

Здесь описываются стандартные этапы. Главное – грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.

Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.

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

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

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

o текст программы;

o описание программы;

o программа и методика испытаний;

o описание применения;

o руководство пользователя.

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

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

Например: В ходе разработки программы должен быть подготовлен следующий графический материал:

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

o структура программы;

o формат представления входных данных программы;

o общая схема алгоритма (2 листа);
o основные вычислительные алгоритмы;
o пример работы программы.

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

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

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

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

Шаблон технического задания

Скачать шаблон "Технического задания"

Это нравится:0Да/0Нет
Теги: шаблоны

Страницы: 1 2 След.
Это нравится:0Да/0Нет
Гость
Обсуждаем как правильно составлять требования и разрабатывать техническое задание (ТЗ)Как написать техническое задание ? С чего начать оформление? Есть ли стандартные образцы, формы или госты?
Есть ли шаблон(план) выполнения ТЗ. Может пример? Хочу сделать сайт и понадобилось техническое задание. Спасибо.


Обсуждение ЧТЗ (Частного технического задания) здесь
Это нравится:0Да/0Нет
Gert
Цитата
Есть ли шаблон(план) выполнения ТЗ. Может пример? Хочу сделать сайт и понадобилось техническое задание. Спасибо.
Это нравится:0Да/0Нет
Vadim
Посмотрите:  ГОСТ 34.602-89  
Статус НД: Действует
Взамен: ГОСТ 24.201-85
Заглавие: Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
Объем: 12 стр.
Введен: 01.01.1990
Коды КГС: П87 Автоматизированные системы управления

Коды ОКС: 35.080 Программное обеспечение *Включая разработку программного обеспечения, документацию, интернет-приложения и использование

Область применения: Настоящий стандарт распространяется на автоматизированные системы для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа "Техническое задание на создание (развитие или модернизацию) системы".
Это нравится:0Да/0Нет
latex
Цитата
Заменен на ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
Смотри также: ГОСТ 19.201-78 ЕСПД. Техническое задание  
УДК 65.011.56:681.3:002:006.354
Группа Т52




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

--------------------------------------------------------------------------------
Система технической документации на АСУ
ГОСТ 24.201-79
   
ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ»  
   
System of technical documentation for computer control systems. Requirements to document «Technical Directions»    

--------------------------------------------------------------------------------

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен

с 01.07 1980 г.

Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами.

В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. ТЗ является основным исходным документом для создания АСУ, на соответствие которому проверяется созданная АСУ.

1.2. ТЗ следует разрабатывать на основании результатов работ, проводимых на предпроектной стадии с учетом технико-экономического обоснования (ТЭО) и требований, изложенных в ГОСТ 15.001—73.

1.3. ТЗ на АСУ является частью задания на создание объекта управления, если АСУ создают одновременно и совместно с ним.

1.4. На части АСУ допускается разрабатывать отдельные технические задания.

2. СОСТАВ ТЕХНИЧЕСКОГО ЗАДАНИЯ
2.1. Техническое задание на создание АСУ должно содержать следующие разделы:

введение;
характеристика объекта управления;
назначение АСУ;
основные требования к АСУ;
технико-экономические показатели АСУ;
состав, содержание и организация работ по созданию АСУ;
порядок приемки АСУ.
2.2. Допускается расширять перечень разделов ТЗ, установленных настоящим стандартом, в зависимости от специфических особенностей создаваемых АСУ.

3. СОДЕРЖАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ
3.1. «Введение» должно содержать:

полное наименование и условное обозначение АСУ;
основание для создания АСУ (перечень документов);
наименование и условное обозначение темы или разработки;
сроки начала и окончания работы по созданию АСУ;
наименование организаций, участвующих в создании АСУ (исполнителей, соисполнителей), и их реквизиты;
сведения об источниках и порядке финансирования.
3.2. Раздел «Характеристика объекта управления» должен содержать:

описание состава объекта управления (производственную или иную структуру) в зависимости от его типа;
характеристики входных и выходных материальных потоков;
описание особенностей объекта управления, определяющих основные требования к создаваемой АСУ (регламент, режим работы и т. п.).
3.3. Раздел «Назначение АСУ» должен содержать:

назначение АСУ, основные цели ее создания, критерии эффективности функционирования объекта в условиях автоматизированного управления;
перечень выполняемых функций, необходимых для достижения целей;
описание общей структуры системы управления объектом с указанием места АСУ в ней;
взаимосвязи создаваемой АСУ с системами управления других уровней;
перспективы развития АСУ.
3.4. Раздел «Основные требования к АСУ» должен содержать следующие подразделы:

требования к системе и ее частям;
требования к качеству выполнения функции АСУ;
требования к видам обеспечения АСУ.
3.4.1. Подраздел «Требования к системе и ее частям» должен содержать:

основные показатели (параметры), которые должны быть достигнуты в условиях автоматизированного управления объектом;
структуру АСУ и входящих в нее частей;
требования к функционированию АСУ или ссылку на документы, регламентирующие:
режим работы,
способы обмена информацией со смежными системами с указанием режима обмена, объема, содержания, системы кодирования и, при необходимости, формы представления информации;
эргономические требования в части рациональной компоновки технических средств, удобств обслуживания, комфортности пунктов управления и, при необходимости, эстетического решения;
требования к сохранности информации при авариях в система энергоснабжения.
3.4.2. Подраздел «Требования к качеству выполнения функций АСУ» должен содержать перечень функций управления и решаемых задач или комплекса задач с указанием для каждой задачи основных входных и выходных показателей и потребителя информации.

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

3.4.3. Подраздел «Требования к видам обеспечения АСУ» должен содержать требования к программному, информационному, организационному, техническому и другим видам обеспечения в соответствии с требованиями, установленными стандартами на АСУ конкретных видов.

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

3.4.4. Состав требований к частям системы, разрабатываемым по отдельным техническим заданиям, определяют в зависимости от выделяемой части системы: подсистемы АСУ, ИВЦ, банка данных и т. п.

3.4.5. В разделе «Основные требования к АСУ» допускается приводить дополнительные требования, не указанные в пп. 3.4.1-3.4.4, а также ссылки на нормативно-техническую документацию, которой должна соответствовать техническая документация на АСУ.

3.5. Раздел «Технико-экономические показатели АСУ» должен содержать:

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

3.6. Раздел «Состав, содержание и организация работ по с озданию АСУ» должен содержать:

перечень стадий и этапов выполнения работ;
перечень работ по стадиям и этапам, сроки их выполнения и организации - исполнители работ;
форму завершения стадий и этапов создания АСУ.
Стадии, этапы и перечень выполняемых работ указывают в соответствии с нормативно-технической документацией на АСУ конкретного вида. Кроме того, в разделе необходимо приводить перечень мероприятий по подготовке объекта к внедрению АСУ с указанием сроков выполнения работ и исполнителей.

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

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

3.7. Раздел «Порядок приемки АСУ» должен содержать указания о составе и объеме приемо-сдаточных испытаний, которые проводят при вводе системы в эксплуатацию или предъявлении системы Государственной (межведомственной, внутриведомственной) комиссии. Состав и объем испытаний определяют по нормативно-технической документации на АСУ конкретного вида.


--------------------------------------------------------------------------------

Переиздание. Июнь 1982 г.
Это нравится:0Да/0Нет
Lub
Можно и тут попробовать глянуть...
Там же и шаблон ТЗ скачать можно, если это то, что вам нужно
Это нравится:0Да/0Нет
Сергей
Всем, огромное
спасибо!
Это нравится:0Да/0Нет
lera
Добрый день, в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?
Заранее большое спасибо.
Светлана.
Это нравится:0Да/0Нет
lera
Цитата
Цитата
... в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?

ГОСТ 27.002-89
Надежность в технике. Основные понятия. Термины и определения

P. S.  ГОСТы серии 24 отменены (недействительны).
Спасибо!
Это нравится:0Да/0Нет
basseyn
Видимо, ГОСТ 24.701 не подошел потому, что требуется указать ссылку на ОТРАСЛЕВОЙ стандарт...
ГОСТ - это государственный стандарт, а не отраслевой
Это нравится:0Да/0Нет
Гость
Цитата
... в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?

ГОСТ 27.002-89
Надежность в технике. Основные понятия. Термины и определения

P. S.  ГОСТы серии 24 отменены (недействительны).
Страницы: 1 2 След.
Зарегистрируйтесь