Тез задание. Стандарты и шаблоны для тз на разработку по. Нужно ли качественно оформлять ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. введение;
2. основания для разработки;
3. назначение разработки;
4. требования к программе или программному изделию;
5. требования к программной документации;
6. технико-экономические показатели;
7. стадии и этапы разработки;
8. порядок контроля и приёмки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приёмки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

1. О чем статья

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

ВНИМАНИЕ: ЦЕЛЬ ЭТОЙ СТАТЬИ - НЕ ЗАМЕНИТЬ ГОСТ, А РАЗЪЯСНИТЬ НЕКОТОРЫЕ ЕГО ПОЛОЖЕНИЯ.

2. Характерные особенности Технического задания по ГОСТ 34

2.1. По какому стандарту составляется ТЗ?

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

Действительно, в стандарте используется много непонятных терминов. Что, например, имеется в виду под лингвистическим обеспечением? Для прояснения использующихся понятий следует обратиться к ГОСТ 34.003-90 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».

2.2. Зачем нужен ГОСТ на Техническое задание?

2.3. Какую роль Техническое задание занимает в проекте?

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

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

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

2.4. Насколько ГОСТ 34.602-89 устарел и есть ли более новые стандарты?

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

• IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению.
• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
• ISO/IEC/IEEE 29148-2011. Systems and software engineering - Life cycle processes - Requirements engineering.
• ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.
• Ну и ГОСТы серии 34.

3. Общие принципы составления ТЗ по ГОСТ 34

3.1. Какой специалист должен составлять Техническое задание по ГОСТ 34?

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

3.2. Какая сторона должна составлять Техническое задание?

Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34-602-89. На самом деле, у заказчика, как правило, отсутствуют соответствующие специалисты. Но ТЗ в обязательном порядке прорабатывается и согласовывается заказчиком. И вот здесь нужно обязательно добиться того, чтобы согласование не было формальным. Я всегда стараюсь настоять на том, чтобы мы вместе с заказчиком подробно разобрали каждый пункт. Ваша цель - вовлечь заказчика в проект. Иначе он так и не сформирует свои ожидания от системы, а значит, во-первых, будет недоволен любым результатом, а, во-вторых, не сможет провести необходимые организационные мероприятия.

3.3. Насколько далеко можно отходить от ГОСТ 34?

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

Не верите? Тогда читайте пункт 2.2 ГОСТ 34.602-89 (кстати, цифры после дефиса - год публикации стандарта или его редакции): «В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы».

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

3.4. Зачем в ТЗ по ГОСТ 34 описывается так много требований, напрямую не относящихся к функциям системы?

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

Во-вторых , составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система - это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. И правда, отбери у бухгалтеров компьютеры, они с трудом, но смогут выполнять свою работу, пусть и с бумажными реестрами. А вот 1С без бухгалтера самостоятельно работать не будет. Отсюда и множество разделов ТЗ, посвященных организационным мерам. Как говорят, ИТ-система на 20% - это ИТ, все остальное - организационные мероприятия. То есть ТЗ - это документ, в котором прописывается все необходимое для внедрения системы, от А до Я.

В-третьих , обратите на само название ГОСТа 34.602-89: «Техническое задание на создание автоматизированной системы». ТЗ не на систему, а на создание системы. В чем отличие? Отличие в том, что ТЗ устанавливает не только требования к самой системе, но и регламентирует процесс ее создания, то есть в документе приводятся требования ко всем организационным мерам, выполнение которых необходимо для достижения результата. Ведь при реализации проекта автоматизации зачастую следует перестроить ряд процессов, обучить персонал, подготовить аппаратную часть.

В-четвертых , ТЗ представляет собой документ, по которому можно ставить галочки: приняли мы во внимание данное требование или нет. Может, вы поставите 10 галочек чисто автоматически, потому что это будут стандартные решения. Но галочка номер 11 выявит очень большую проблему, и если эту проблему сейчас пропустить, то она всплывет где-то в процессе внедрения, когда уже определены все сроки и бюджеты.

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

3.5. Зачем в разных разделах говорится об одном и том же?

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

3.6. Нужно ли качественно оформлять ТЗ?

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

Приведем несколько пожеланий к оформлению больших документов, как ТЗ.

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

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

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

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

Заметим, что, по строгим правилам, ТЗ оформляется без рамки (об этом сказано в п. 3), а вот остальные документы - с рамкой. Это установлено в ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов (с Изменениями № 1, 2)». Данный стандарт устанавливает правила оформления всех документов, кроме ТЗ и документов, создаваемых на предпроектных стадиях. Хотя лично мне рамка не нравится ни в каких документах.

4. Раздел 1. «Общие сведения» /п. 2.3 ГОСТ 34.602-89/

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

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

5. Раздел 2. «Назначение и цели создания (развития) системы» /п. 2.4 ГОСТ 34.602-89/

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

С целью все по-другому. Цель - это ради чего мы затеваем проект. Можно назвать это бизнес-целями. Я выделяю следующие возможные цели проектов автоматизации:

1. Выполнение внешних требований (требования закона, стандарта и т.д.)
2. Обеспечение работы нового технологического процесса (например, создаем интернет-магазин, организуем новый отдел, новый бизнес).
3. Снижение операционных расходов (уменьшение количества персонала, увеличение выпуска продукции при использовании тех же мощностей, повышение эффективности).
4. Повышение качества работы: снижение количества ошибок, ускорение принятия решений.
5. Снижение рисков, повышение надежности. Это касается не только технической стороны, но также исключения опасности в случае болезни или увольнения ключевых, «незаменимых», сотрудников.

6. Раздел 3. «Характеристики объекта автоматизации» /п. 2.5 ГОСТ 34.602-89/

Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.

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

В данном разделе следует приводить:

1. Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
2. Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
3. Описание автоматизируемых объектов. Например, если мы автоматизируем склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
4. Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии - обязательно. Только тогда нам становится ясно, какие должны иметься функции.
5. Перечень документов, в которых приводится подробное описание объекта автоматизации.

7. Раздел 4 «Требования к системе»

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

7.1. Подраздел 4.1. «Требования к системе в целом» /п. 2.6.1 ГОСТ 34.602-89/

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

7.1.1. Пункт 4.1.1. «Требования к структуре и функционированию системы» /п. 2.6.1.1 ГОСТ 34.602-89/

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

В данном пункте я обычно привожу:

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

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

… или так:

2. Требования к способам и средствам связи для информационного обмена между компонентами системы.

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

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

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

• по готовности к эксплуатации: штатный режим, аварийный режим, режим технического обслуживания (например, в аварийном режиме должна присутствовать заставка на сайте, нагрузка переводиться на другой сервер, выводиться особые сообщения при обращении к данной системе по API, в режиме технического обслуживания некоторые функции могут быть доступны);
• по готовности к эксплуатации частей системы: как должна функционировать система, если, например, недоступен один из внешних или внутренних сервисов;
• по графику работы: 24/7 или пятидневка (от этого зависит как минимум работа технической поддержки);
• по возможности изменения данных: режим просмотра или редактирования;
• по уровню доступа к данным и операциям системы: режим авторизованного пользователя, режим администратора, гостевой режим (для неавторизованных пользователей);
• по средству доступа к системе: через веб-приложение, через толстый клиент, через мобильное приложение (согласитесь, что функциональность может несколько отличаться, эти ограничения можно описать здесь);
• по виду взаимодействия: диалоговый (через интерфейс), взаимодействие посредством изменения настроек в конфигурационных файлах или иным способом, неавтоматизированный (например, информация передается другому сотруднику, который вносит данные в систему, производится ручной съем показаний);
• по степени автоматизации: автоматический или полуавтоматический режим, «режим советчика»;
• по видимости приложения: диалоговый или фоновый режим;
• по возможному воздействию на систему: штатный, обучающий, тестовый режимы.

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

6. Перспективы развития, модернизации системы.

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

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

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

7.1.2. Пункт 4.1.2. «Требования к численности и квалификации персонала» /п. 2.6.1.2 ГОСТ 34.602-89/

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

Понятно, что требования к персоналу часто устанавливаются заказчиком, зачем их тогда приводить? Но, во-первых, мы уже говорили, что ТЗ составляется для обеих сторон, а во-вторых, так исполнитель будет защищен: не выполнено условие по подбору персонала, чего же тогда заказчик хочет, если система не внедрена?

7.1.3. Пункт 4.1.3. «Требования к показателям назначения» /п. 2.6.1.3 ГОСТ 34.602-89/

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

К показателям назначения можно отнести:

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

7.1.4. Пункт 4.1.4. «Требования к надежности» /п. 2.6.1.4 ГОСТ 34.602-89/

Основным понятием, которое можно применить для автоматизированных систем, является коэффициент готовности: 99%, 99,9%, 99,99%. Каждое количество «девяток» обеспечивается определенными мерами.

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

7.1.5. Пункт 4.1.5. «Требования к безопасности» /п. 2.6.1.5 ГОСТ 34.602-89/

7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/

Обычно в этом пункте пишется, что у системы должен быть удобный и красивый интерфейс. Но как измерить удобство и красоту? Поэтому либо данное требование опускаем, либо говорим о том, что интерфейс будет соответствовать разработанному позже дизайн-проекту, либо приводим стандарты, например, так называемые «гайдлайны» для разработки мобильных приложений: Material Design для Android и Human Interface Guidelines для iOS.

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

7.1.7. Пункт 4.1.7. «Требования к транспортабельности для подвижных АС» /п. 2.6.1.7 ГОСТ 34.602-89/

7.1.8. Пункт 4.1.8. «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению» /п. 2.6.1.8 ГОСТ 34.602-89/

7.1.9. Пункт 4.1.9. «Требования к защите информации от несанкционированного доступа» /п. 2.6.1.9 ГОСТ 34.602-89/

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

Так, для финансовых систем следует использовать «Стандарт безопасности данных индустрии платежных карт» (PCI DSS). Для систем, в которых хранятся персональные данные, - Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». В вашей предметной области могут иметься и другие стандарты.

В общем и целом, средства защиты можно разделить на следующие типы:

1. Средства, обеспечиваемые создаваемым программным продуктом.
2. Меры, обеспечиваемые системным администратором.
3. Меры физической защиты.
4. Общие организационные меры.
5. Меры, принимаемые в процессе разработки программного обеспечения.

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

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

• Ограничение доступа в критические помещения.
• Отключение сетевых разъемов в общедоступных местах.
• Установка камер видеонаблюдения за критически важными помещениями.

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

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

7.1.10. Пункт 4.1.10. «Требования по сохранности информации при авариях» /п. 2.6.1.10 ГОСТ 34.602-89/

• потеря питания;
• выход из строя сервера;
• выход из строя устройства хранения (жесткого диска).

7.1.11. Пункт 4.1.11. «Требования к защите от влияния внешних воздействий» /п. 2.6.1.11 ГОСТ 34.602-89/

7.1.12. Подраздел 4.1.12. «Требования по патентной чистоте» /п. 2.6.1.12 ГОСТ 34.602-89/

7.1.13. Пункт 4.1.13. «Требования к стандартизации и унификации» /п. 2.6.1.13 ГОСТ 34.602-89/

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

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

7.1.14. Пункт 4.1.14. «Дополнительные требования» /п. 2.6.1.14 ГОСТ 34.602-89/

7.2. Подраздел 4.2. «Требования к функциям (задачам), выполняемым системой» /п. 2.6.2 ГОСТ 34.602-89/

7.2.1. Структура функционального описания

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

7.2.2. Виды функций с точки зрения их выполнения

• Ввод сведений. Иногда называют также «учет сведений».
• Вывод информации.
• Автоматическая обработка информации.

7.2.3. Виды функций с точки зрения их роли

7.2.4. Требование, а не сценарий

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

7.2.5. Оформление функциональных требований

1. Требования к функциям и задачам обычно следует выносить в приложение. Таким образом документ органично делится на нефункциональную и функциональную части. Кроме того, приложение всегда можно распечатать и рассматривать отдельно.
2. Избегайте больших абзацев. Лучше всего, если требования разбиты по пунктам и подпунктам: так легче их воспринимать и контролировать их выполнение (галочки ставить). Если приводится перечень требований или сведений, пусть он приводится нумерованным или маркированным списком.
3. Для функций, назначение которых не очевидно из их названия, следует обязательно указать цель и решаемую задачу. В противном случае даже составитель ТЗ рискует забыть, зачем он описывал ту или иную функциональность.

7.2.6. Пример описания функции

5.6. Регистрация транспортного средства в Системе

Предъявляются следующие требования:

1) Система должна позволять учитывать следующие общие сведения:

• государственный регистрационный знак (ГРНЗ);
• ФИО собственника;
• адрес собственника;
• данные от сервиса получения данных о ТС (см. п. 3.3, Приложение Б);
• примечание.

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

• текущий класс ТС (см. п. 3.3, Приложение А);
• текущий тариф (см. п. 5.1, Приложение А);
• текущий договор (см. п. 5.5, Приложение А);
• класс ТС по сведениям из системы МВД РК;
• сведения о лицевом счете и его состоянии (см. п. 3.6, Приложение А);
• сведения о нахождении в реестре ТС с льготным проездом (см. п. 3.5, Приложение А).

3) Система должна позволять регистрировать и изменять сведения о ТС следующими способами:

• вручную оператором;
• при поступлении сведений из системы регистрации RFID-меток (см. п. 1.1, Приложение Б);
• при идентификации ТС с помощью камеры ГРНЗ.

4) При регистрации в системе нового ТС система должна запрашивать данные о ТС от сервиса получения данных о ТС (см. п. 3.3, Приложение Б). Должна иметься возможность обновить указанные сведения отдельного ТС.

7.3. Подраздел 4.3. «Требования к видам обеспечения» /п. 2.6.3 ГОСТ 34.602-89/

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

При чтении данного подраздела задаешься вопросом, что имели в виду составители стандарта под «математическим обеспечением», «лингвистическим обеспечением», «информационным обеспечением» и т.д. Ответы следует искать в ГОСТ 34.003-90, где расшифровываются все эти термины.

7.3.1. Пункт 4.3.1 «Математическое обеспечение» /п. 2.6.3.1 ГОСТ 34.602-89/

7.3.2. Пункт 4.3.2 «Информационное обеспечение» /п. 2.6.3.2 ГОСТ 34.602-89/

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

Таким образом, в данном пункте имеет смысл указать требования к входящей информации и информации, передающейся от компонента к компоненту системы в неавтоматизированном виде. Автоматизированная обработка информации, использование СУБД, информационный обмен внутри системы вполне описываются в других разделах.

7.3.3. Пункт 4.3.3 «Лингвистическое обеспечение» /п. 2.6.3.3 ГОСТ 34.602-89/

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

7.3.4. Пункт 4.3.4 «Программное обеспечение» /п. 2.6.3.4 ГОСТ 34.602-89/

7.3.5. Пункт 4.3.5 «Техническое обеспечение» /п. 2.6.3.5 ГОСТ 34.602-89/

7.3.6. Пункт 4.3.6 «Метрологическое обеспечение» /п. 2.6.3.6 ГОСТ 34.602-89/

7.3.7. Пункт 4.3.7 «Организационное обеспечение» /п. 2.6.3.7 ГОСТ 34.602-89/

7.3.8. Пункт 4.3.8 «Методическое обеспечение» /п. 2.6.3.8 ГОСТ 34.602-89/

7.3.9. Другие виды обеспечения

8. Раздел 5 «Состав и содержание работ по созданию (развитию) системы» /п. 2.7 ГОСТ 34.602-89/

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

• Наименование этапа (подэтапа).
• Содержание работ (краткое описание, перечень задач).
• Результат работ (утвержденные документы, разработанные и сданные решения).
• Проектная, рабочая или отчетная документация.
• Ответственные (кто выполняет данную работу: заказчик, исполнитель или иное лицо). Если обе стороны должны выдать совместный результат, указываются роли.
• Длительность (сроки, даты, начало отсчетов сроков).

9. Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

9.1. Подраздел 6.1. «Виды, состав, объем и методы испытаний системы и ее составных частей» /п. 2.8.1 ГОСТ 34.602-89/

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

Давайте попробуем разобраться в том, какие бывают испытания:

1. Испытания делятся на следующие виды:

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

• Автономные (без интеграции со смежными системами).
• Комплексные (в комплексе со смежными системами).

Давайте попробуем описать процесс испытаний простыми словами:

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

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

3. Предварительные комплексные испытания. Система испытывается в комплексном режиме, то есть во взаимодействии со смежными системами. В таком виде система передается заказчику для опытной эксплуатации.

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

5. Приемочные испытания. Это последний вид проверки. Скажете, а почему опытная эксплуатация после устранения всех недостатков плавно не перейдет в промышленную? Так оно обычно и происходит. Но ведь высоким дядям надо увидеть, что система реально работает, «пощупать» ее. Для них, для высокой комиссии и предназначены приемочные испытания. Таким образом, приемочные испытания отличаются от предварительных в первую очередь статусом комиссии.

Также в этом пункте указываются документы, в которых будут приведены методы испытаний:

• Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце - в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно - в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
• Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

1. На чьей территории и на чьем оборудовании будут проводиться испытания: заказчика или исполнителя.
2. Общее описание, каким образом будут проводиться испытания (например, что будут проверяться документы, наличие элементов пользовательского интерфейса, отрабатываться сценарии).
3. Список участников.
4. Перечень документов, которыми оформляют результат испытаний:
   • Для предварительных и приемочных испытаний это протокол испытаний, в котором приводится перечень проверок и их результаты.
   • Для опытной эксплуатации - журнал опытной эксплуатации.

10. Раздел 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» /п. 2.9 ГОСТ 34.602-89/

При подготовке объекта, как правило, следует выполнить следующие работы:

1. Проведение реорганизации, набор нового персонала, в случае необходимости.
2. Обучение персонала.
3. Для веб-приложений: разработка общих разделов сайта и пользовательского соглашения (согласия на обработку персональных данных).
4. Заполнение справочников и иных исходных сведений.
5. Перенос данных из прежней системы.
6. Развертывание системы на промышленных серверах.
7. Настройка интеграции со смежными системами.
8. Настройка системы доступа и создание учетных записей.

11. Раздел 8 «Требования к документированию» /п. 2.10 ГОСТ 34.602-89/

Документирование проекта автоматизации по ГОСТ 34 регламентируется следующими стандартами:

• ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем.
• РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
• Для Технического задания - ГОСТ 34.602-89, который мы сейчас и обсуждаем.

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

11.1 Особенности структуры документации

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

1. Для каждого из этапов предназначен свой комплект документации.

Для каждого из этапов предназначен свой комплект документации. Это очень важно уяснить. Не надо прописывать разработку эксплуатационных документов на проектных стадиях и наоборот. Получаются чисто формальные бумаги, на которые вы потратите значительное время. И если «Руководство пользователя» до окончания разработки системы обычно никто не составляет (хотя встречал и таких деятелей), то «Описание автоматизированных функций», в котором обычно приводятся сценарии для программистов, постоянно составляют уже после окончания разработки. Также при чтении РД 50-34.698-90 может создаться впечатление, что у некоторых документов содержание пересекается: это тоже связано с тем, что документы предназначаются для различных этапов.

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

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

2. Документы делятся на темы (части проекта).

В ГОСТе 34 имеются документы, описывающие общесистемные решения, а также организационное, техническое, математическое, программное, информационное обеспечение (о видах обеспечения мы говорили ). В РД 50-34.698-90 данные документы приводятся именно с разбивкой по частям проекта (темам). На это всегда следует обращать внимание, чтобы определить предназначение документа.

3. Документы можно объединять.

В ГОСТ 34.201-89 прямо указывается, в каких случаях один документ включается в состав другого. Это сделано для того, чтобы не оставалось вырожденных документов, с одной или двумя страничками. Если что-то требуется описать, но объем очень маленький, лучше всего включить текст в другой документ. В большинстве случаев имеется такой документ как «Пояснительная записка к техническому проекту», в который можно добавлять разделы.

4. Эксплуатационная и проектно-сметная документация выделены отдельно.

Составители ГОСТ 34.201-89 в отдельных столбцах таблицы с перечнем документов обозначили принадлежность к эксплуатационной и проектно-сметной документации.

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

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

11.2 Особенности оформления списка документов

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

• Этап.
• Наименование документа.
• Примечание: указывается стандарт разработки, назначение, краткое содержание и основные особенности документа.

11.3 Пример перечня документации

12. Раздел 9 «Источники разработки» /п. 2.11 ГОСТ 34.602-89/

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

• Материалы с описанием аналогов (прототипов) разрабатываемой системы.
• Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
• Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
• Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
• Материалы и стандарты, содержащие требования к общей и информационной безопасности.

Заключение

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

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

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

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

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

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

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

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

• Рассказать подробнее о компании, предлагаемых товарах или услугах, целевой аудитории;
• Уточнить о проблемах, с которыми целевая аудитория (ЦА) будет приходить к клиенту и их решения;
• Узнать, что именно клиент хочет получить от сайта;
• Попросить привести примеры удачных сайтов конкурентов.

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

Чёткость формулировок в ТЗ

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

Главный критерий качества ТЗ - чёткие формулировки, отсутствие двусмысленных трактовок.

Конкретика в техническом задании - главное условие качества, например:

• Каждая страница должна провериться на GTmetrix или GoogleSpeed с показателем скорости не менее 80/100 по Google Page Speed.
• Ресурс должен выдерживать до 20 тыс. посетителей одновременно.
• На главной должны выводиться новости и ниже отображаться форма с кнопкой «Подписаться» с возможностью отправить e-mail адрес.
• Список партнеров в виде карусели логотипов, отзывы клиентов в слайдере с горизонтальной прокруткой по 1-му отзыву на слайд.

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

Структура сайта – фундамент. Решите, какие страницы необходимо создать и продумайте навигацию на них. По нашему опыту клиент проще воспринимает блок-схему, нарисованную в XMind. Но если вы считаете, что работа в XMind займет слишком много времени, то просто перечислите секции в word файле. Кстати, не лишним будет предварительно собрать , которое поможет в определении структуры и разделов на основании реальных запросов потенциальных клиентов в вашем сегменте.

Пример структуры ТЗ по договору

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

Страница «Главная»

• Секция «Меню» с разделами и выпадающим списком подразделов:
  • Логотип и слоган;
  • «Главная»;
  • «Проекты»;
  • «Каталог продукции» с выпадающим списком разделов «Трубы SML», «Фитинги SML», «Соединительные хомуты»;
  • «Производство»;
  • «О компании»;
  • «Проектировщикам»
  • «База знаний / FAQ»;
  • «Контакты»;
  • Ссылка на скачивание катала продукции в.pdf;
  • Контактный телефон компании;
  • Кнопка «Заказать звонок».
• Секция «Слайдер» с фотографией по ширине экрана и кнопкой обратной связи с запросом на просчёт проекта / запроса на полный прайс-лист продукции.
• Секция «Преимущества» с указанием ключевых выгод для клиентов;
• Секция «Производство» с кратким описанием и информацией про систему контроля качества, со ссылкой на раздел «Производство» и кнопкой с записью на поездку на завод;
• Секция «Продукция» с текстовым описанием преимуществ, ссылками на сертификаты, ссылкой на «Каталог продукции»;
• Секция «Наши проекты» (с переходом в раздел «Все проекты»);
• Секция «Компания в цифрах» с цифрами достижений и ссылкой на раздел «О компании»;
• Секция «Видео-инструкции» с текстовым описанием и ссылкой в раздел «Все видео»;
• Секция «Подвал»:
• Контакты, телефон, адрес, электронная почта;
• Кнопка обратной связи;
• Ссылка на YouTube канал и на социальные сети компании.

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

Функционал сайта

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

• CMS система Вордпресс, Битрикс и тп.
• Формы заявок с возможностью оставить заявку
• Модальные окна
• Слайдеры
• Модули галереи
• Модули SEO оптимизации и страниц
• Модули кеширования и сжатия
• Онлайн-карта с гео-метками
• с расчетом цены

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

Отдельно.

Помните, что сайт - это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.

Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.

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

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

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

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

• Общая концепция.
• Структура сайта и страниц.
• Требования к хостингу.
• Прототипы страниц.
• Требования к вёрстке и работоспособности.
• Функциональная часть.
• Требования к дизайну и контенту.

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

Если вам нужен новый сайт, то вы можете создание сайта или технического задания в нашей веб-студии.

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

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

Проблема

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

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

Переводим на понятный язык

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

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

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

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТЗ на сайт

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

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

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

Вот так надо

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

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

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

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

Ну вот

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