Что такое техническое задание? Как его делать и для чего оно нужно? Примеры, образцы, советы и рекомендации.

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

Проблема восприятия информации, вечная. Эффект “сломанного телефона”, частое явление. А что говорить о том, если ты просто не умеешь ставить задачу? Да, такое тоже бывает и с этим нужно как-то работать, но как? Для того чтобы результаты задач, которые вы ставите, соответствовали вашим ожиданиям, пишите техническое задание.

Что такое техническое задание

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

Конструкторское бюро

Документ этот может занимать, как одну страницу А4, так и целый том, все зависит от задач и пожеланий которые в него входят. К примеру, вы можете написать техническое задание на небольшой landing page (одностраничный сайт) или же на сложное программное обеспечение с машинным обучением и прочими фишками.

Для чего нужно техническое задание

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

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

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

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

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

Если мы говорим об игре “по-взрослому”, например, техническое задание на разработку мобильного приложения или сайта, то это отдельная работа, за которую платятся немалые деньги. Вы привлекаете человека, как правило, это бывший или действующий технический директор (Chief Technical Officer) и просите его помочь вам.

Наличие бороды необязательно

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

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

Из чего состоит техническое задание

Все будет зависеть от шаблона, который вы выберете (чуть дальше я дам несколько ссылок на шаблоны/примеры), но есть базовые блоки, которые входят в техническое задание:

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

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

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

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

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

ТЗ на разработку интернет магазина

ТЗ на разработку мобильного приложения

ТЗ на сайт

ТЗ на сервисы/обновления

Если нужно больше образцов, просто погуглите.

Главная рекомендация, это делать. Беда в том, что лень-матушка одолевает каждого и сопротивляться ей не просто. Соберите всю волю в кулак и начинайте писать техническое задание, просто пишите и не останавливайтесь. Не переживайте, что не получается “идеально”, открою тайну, такого и не бывает. Просто пишите, с каждым разом будет получаться лучше и лучше.

Вот так надо

Мои первые зачатки по написанию ТЗ начали появляться несколько лет назад. Я работал с дизайнерами и ставил задачу на создание креативов для рекламных кампаний. Бессвязное хочу это и это превращалось в кучу потраченного времени и объяснений. Со временем постановка задач начала превращаться в какие-то смысловые блоки, а потом уже и в подобие технического задания.

Например для задачи “Кнопка лайк на сайте”:

Описание: необходимо создать кнопку “Лайк” на нашем сайте.
Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17), разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

Ну вот

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

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

Зачем нужно Техническое задание?

Многие Разработчики часто недооценивают важность технического задания, однако, ТЗ является важным, можно сказать, краеугольным документом при разработке информационных систем, сайтов, инженерных систем, да и всего чего угодно.
Сегодня, когда в моде Agile, может показаться, что ТЗ документ избыточный, но это до того момента, когда вы не столкнётесь с разработкой действительно серьёзных информационных систем, крупных программных продуктов или порталов. Объяснить на пальцах, чего бы хотелось Заказчику можно, если в системе 3-5 сущности-предмета, а если значительно больше, то обязательно что-нибудь забудется. Потом начнётся рисование на бумажке, записи на салфетках в кафе, сообщения в ватсап: «А вот неплохо было бы сделать, чтобы синие иконочки в правом углу и когда мышкой наводишь, они бы такие выезжали на центр и увеличивались!». Для того чтобы формализовать этот процесс и создаётся техническое задание, то есть документ о том, как всё должно быть.
Техническое задание выполняет ряд важных функций:

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

В общем, при разработке системы обязательно составляйте Техническое задание! Именно оно вас убережёт от проблем.

Кто составляет ТЗ?

Техническое задание - это работа не одного человека, а группы лиц:

Аналитиков со стороны Заказчика - они определяют необходимость системы, выдвигают в письменном виде требования к новой программе.
Аналитиков со стороны Разработчика - они должны обследовать область, по которой будет разрабатываться программа, или компанию. Учесть все схемы, алгоритмы и нюансы работы, которую будет выполнять система.
Технический писатель - сотрудник, который соберёт все данные аналитиков и запишет их согласно ГОСТу.

Чаще всего Техническое задание, выполненное по ГОСТу - это требование органов государственной власти или крупных государственных компаний.
Написание Технического задания работа долгая и сложная. ТЗ не один раз согласовывается у руководства заказчика и разработчика, а также не раз правится и переписывается. Чтобы написать хорошее ТЗ иногда уходит месяц и больше, но лучше потратить побольше времени на написание Технического задания, чем потом доказывать, что вы хотели не так и имели в виду совершенно другое. Ведь все ошибки в Техническом задании будут стоить денег и времени Разработчику /Заказчику.

По каким ГОСТам пишется ТЗ?

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

В России Техническое задание пишется согласно двум ГОСТам:

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

Какой ГОСТ для Технического задания выбрать?

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

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

Чем отличаются ГОСТ 34 от ГОСТа 19 при написании ТЗ

Для удобства ниже представлена таблица пунктов и для написания Технического задания.

ГОСТ 19	ГОСТ 34
1. Введение	1. Общие сведения
2. Основания для разработки	1. Общие сведения
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надёжности	4.1.4. Требования к надёжности
	4. 1.5. Требования к безопасности
	4.1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4.1.10. Требования по сохранности информации при авариях
	4.1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4.1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4.1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приёмки	6. Порядок контроля и приёмки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

Ниже рассмотрим каждый ГОСТ и пункты ГОСТ по отдельности.

ГОСТ 19 для Технического задания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ 34 для Технического задания

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

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

В ТЗ могут включаться приложения.

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

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

В разделе 1 «Общие сведения » указывают:

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

Раздел 2 «Назначение и цели создания (развития) системы » состоит из подразделов:

назначение системы;
цели создания системы.

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

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

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

В разделе 3 «Характеристики объекта автоматизации » приводят:

краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Раздел 4 «Требования к системе » состоит из следующих подразделов:

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

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

В подразделе 4.1 «Требования к системе в целом » указывают:

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

В требованиях к структуре и функционированию системы приводят (пункт ТЗ 4.1.1):

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

В требованиях к численности и квалификации персонала на АС приводят (пункт ТЗ 4.1.2):

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

В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы её назначению (пункт ТЗ 4.1.3).

Для АСУ указывают:

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

В требования к надёжности включают (пункт ТЗ 4.1.4):

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

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

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

Для подвижных АС в требования к транспортабельности (пункт ТЗ 4.1.7) включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают (пункт ТЗ 4.1.8):

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

В требования к защите информации от несанкционированного доступа (пункт ТЗ 4.1.9) включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

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

В требованиях к средствам защиты от внешних воздействий приводят (пункт ТЗ 4.1.11):

требования к радиоэлектронной защите средств АС;
требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

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

В дополнительные требования включают (пункт ТЗ 4.1.14):

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

В подразделе 4.2 «Требование к функциям (задачам) », выполняемым системой, приводят:

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

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

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

Для информационного обеспечения системы приводят требования (пункт ТЗ 4.3.2):

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

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

Для программного обеспечения (пункт ТЗ 4.3.4) системы приводят перечень покупных программных средств, а также требования:

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

Для технического обеспечения (пункт ТЗ 4.3.5) системы приводят требования:

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

В требованиях к метрологическому обеспечению (пункт ТЗ 4.3.6) приводят:

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

Для организационного обеспечения приводят требования (пункт ТЗ 4.3.7):

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

Для методического обеспечения САПР (пункт ТЗ 4.3.8) приводят требования к составу нормативно-технической документации системы (перечень применяемых при её функционировании стандартов, нормативов, методик и т. п.).

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

В данном разделе также приводят:

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

В разделе 6 «Порядок контроля и приёмки системы » указывают:

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

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

В перечень основных мероприятий включают:

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

Например, для АСУ приводят:

изменения применяемых методов управления;
создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

В разделе 8 «Требования к документированию » приводят:

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

В разделе 9 «Источники разработки » должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчёты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

В состав ТЗ на АС при наличии утверждённых методик включают приложения , содержащие:

расчёт ожидаемой эффективности системы;
оценку научно-технического уровня системы.

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

Заключение

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

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

Надеюсь, с помощью этой статьи написать Техническое задание вам будет немножко легче!

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

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

ЛАБОРАТОРНАЯ РАБОТА № 1.

Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия «Техническое задание»

Цель работы: ознакомиться с правилами написания технического задания.

Теоретическая часть. Разработка технического задания

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

Порядок разработки технического задания

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

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

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

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

Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата А4 и АЗ по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:

введение;

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

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

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

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

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

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

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

приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Порядок выполнения работы

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

Оформить работу в соответствии с ГОСТ 19.106-78.

Сдать и защитить работу.

УТВЕРЖДАЮ

Зав. каф. ПЗ,

д.т.н., проф. ___________

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

Руководитель

к.т.н., доц. ХХХХХХХ

Исполнитель

ст. гр. ____ ХХХХХХХ

Винница, 20__

Введение

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

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

Программа разрабатывается на основе учебного плана кафедры «Программного обеспечения».
Наименование работы:

«Программа сортировки одномерного массива».

Исполнитель: компания ХХХХХХХ.

Соисполнители: нет.

Назначение

Программа предназначена для использования школьниками при изучении темы «Обработка одномерных массивов» в курсе «Информатика».

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

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

ввод размера массива и самого массива;

хранение массива в памяти;

выбор метода сортировки;

вывод текстового описания метода сортировки;

вывод результата сортировки.

Исходные данные:

размер массива, заданный целым числом;

Организация входных и выходных данных

Входные данные поступают с клавиатуры.

Выходные данные отображаются на экране и при необходимости выводятся на печать.

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

Предусмотреть контроль вводимой информации.

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

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

Система должна работать на IBM-совместимых персональных компьютерах.

Минимальная конфигурация:

тип процессора. Pentium и выше;

объем оперативного запоминающего устройства 32 Мб и более;

объем свободного места на жестком диске 40 Мб.

тип процессора. Pentium II 400;

объем оперативного запоминающего устройства 128 Мб;

объем свободного места на жестком диске 60 Мб.

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

Программа должна работать под управлением семейства операционных систем Win 32 (Windows 95/98/2000/МЕ/ХР и т. п.).

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

Министерство образования Украины

Винницкий национальный технический университет

Кафедра программного обеспечения

УТВЕРЖДАЮ

Зав. каф. ПЗ,

д.т.н., проф. ___________

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

на разработку «ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ»

Винница 20__

1. Введение

Работа выполняется в рамках проекта «ХХХХХХХХХХХХХХХХХХ».

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

Основанием для данной работы служит договор № ХХХХ от __ _____ 20__ г.
Наименование работы:

«ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ».

Исполнители: ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ.

Соисполнители: нет.

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

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

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

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

Разрабатываемое ПО должно обеспечивать:

сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков 5А-94 на всех тепловых выходах;

сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);

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

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

визуализацию информации по расходу теплоносителя:

текущую, аналогично показаниям счетчиков;

с накоплением за прошедшие сутки, неделю, месяц - в виде почасового графика для информации за сутки и неделю;

суточный расход - для информации за месяц.

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

По отдельному запросу осуществляются внутренние настройки.

В конце отчетного периода система должна архивировать данные.

Организация входных и выходных данных.

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

Основной режим использования системы - ежедневная работа.

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

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

Условия эксплуатации и требования к составу и параметрам технических средств.

Для работы системы должен быть выделен ответственный оператор.

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

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

Программа должна работать на платформах Windows .

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

Программа поставляется на лазерном носителе информации.

Программная документация поставляется в электронном и печатном виде.

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

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

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

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

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

Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.

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

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

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

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

Календарный план работ

Сидоров С. В.

Название этапа	Сроки этапа	Чем заканчивается этап
Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы	01.02.200_-28.02.200_	Предложения по работе системы. Акт сдачи-приемки
Разработка программного модуля по сбору и анализу информации со счетчиков и устройств управления. Внедрение системы для одного из корпусов МИЭТ	01.03.200 -31.08.200_	Программный комплекс, решающий поставленные задачи для пилотного корпуса МИЭТ. Акт сдачи-приемки
Тестирование и отладка модуля. Внедрение системы во всех корпусах МИЭТ	01.09.200 -30.12.200_	Готовая система контроля теплообеспечения МИЭТ, установленная в диспетчерском пункте. Программная документация. Акт сдачи-приемки работ

Руководитель работ

Контрольные вопросы

Приведите этапы разработки программного обеспечения.

Что включает в себя постановка задачи и предпроектные исследования?

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

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

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

ЛАБОРАТОРНАЯ РАБОТА № 2.

Структурный подход к программированию. Стадия «Эскизный проект»

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

Теоретическая часть.

Разработка спецификаций

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

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

Структурный анализ предполагает использование следующих видов моделей:

диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

диаграмм «сущность-связь» (ERD - Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

f V

диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

функциональных диаграмм (методика SADT);

спецификаций процессов;

словаря терминов.

Спецификации процессов

Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси - Шнейдермана.

Словарь терминов

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

Диаграммы переходов состояний

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

Функциональные диаграммы

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

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

Диаграммы потоков данных

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

Диаграммы «сущность-связь»

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

Порядок выполнения работы

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

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

Определить диаграммы потоков данных для решаемой задачи.

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

Определить функциональные диаграммы.

Определить диаграммы переходов состояний.

Определить спецификации процессов.

Добавить словарь терминов.

Контрольные вопросы

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

Что такое жизненный цикл программного обеспечения?

В чем заключается постановка задачи и предпроектные исследования?

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

Перечислите составляющие эскизного проекта.

Охарактеризуйте спецификации и модели.

ЛАБОРАТОРНАЯ РАБОТА № 3. Структурный подход к программированию. Стадия «Технический проект»

Цель работы: изучить вопросы проектирования программного обеспечения.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Проектирование программного обеспечения» учебной дисциплины «Технология разработки программного обеспечения».

Изучить соответствующие разделы в изданиях .

Ознакомиться с разд. 4.1-4.3 настоящего пособия.

Теоретическая часть. Составляющие технического проекта

ПРОЕКТ ТЕХНИЧЕСКИЙ - образ намеченного к созданию объекта, представленный в виде его описания, схем, чертежей, расчетов, обоснований, числовых показателей.

Технический проект

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

Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием.

Технический проект программной системы подробно описывает:

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

соответствующие им документы;

структуры обрабатываемых баз данных;

взаимосвязи данных;

алгоритмы их обработки.

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

При разработке технического проекта оформляются:

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

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

описание систем классификации и кодирования;

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

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

описание используемого программного обеспечения. Перечень программного обеспечения и СУБД, которые планируется использовать для создания информационной системы;

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

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

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

Структурная схема

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

Функциональная схема

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

Разработка алгоритмов

Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма.

Структурные карты

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

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

Порядок выполнения работы

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

На основе уточненных и доработанных алгоритмов разработать структурную схему программного продукта (разд. 4.1.1).

Разработать функциональную схему программного продукта (разд. 4.1.2).

Представить структурную схему в виде структурных карт Константайна (см. разд. 4.2).

Представить структурную схему в виде структурных карт Джексона (см. разд. 4.3).

Оформить результаты, используя MS Office или MS Visio в виде технического проекта.

Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен состоять из:

Структурной схемы программного продукта.

Функциональной схемы.

Алгоритма программы.

Структурной карты Константайна.

Структурной карты Джексона.

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

УТВЕРЖДАЮ

Руководитель (заказчика ИС)

Личная подпись Расшифровка подписи _

Печать Дата « » 20__ г.

УТВЕРЖДАЮ

Руководитель (разработчика ИС)

Личная подпись Расшифровка подписи

Печать Дата « » 20__ г.

Эскизный проект на создание информационной системы

Система Управления Базой Данных

(наименование вида ИС)

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

(наименование объекта информатизации)

СУБД «Библиотека»

(сокращенное наименование И С)

На 8 листах

Павел Молянов

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
Менеджерам проектов.
Руководителям диджитал-студий.
Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

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

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

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

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

Пишите однозначно и точно

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

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

Сайт должен понравиться заказчику. А если у него будет плохое настроение?
Сайт должен быть удобным. Что это значит? Удобным для чего?
Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
Качественный экспертный контент. Ну, вы поняли.

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

Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
Большие нагрузки → 50 тысяч посетителей одновременно.
На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

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

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

Действие пользователя.
Ответное действие сайта.
Результат.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

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

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

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

Комментарии разработчиков

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

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

Информацию о компании и цель сайта.
Требования к дизайну, цветовую гамму.
Используемые технологии и CMS.
Кто занимается контентом - мы или клиент.
Структуру сайта вплоть до каждой страницы.
Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

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

Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.