Как сделать простое техническое задание и не потерять деньги и нервы

Почему нужно обязательно составлять техническое задание на разработку интернет-сайта

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

Неважно также, во сколько обойдется создание веб-ресурса

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

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

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

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

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

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

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

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

Как лучше всего выявить требования клиента? Обычно исполнители предлагают заполнить бриф, на основе которого составляется техническое задание на разработку сайта.

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

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

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

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

Помимо ответов на вопросы вы можете указать свои требования в пункте «Дополнительная информация».

Как правильно составлять техническое задание на разработку сайта

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

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

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

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

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

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

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

Счетчики от Яндекса и Google

На новый сайт обязательно нужно добавить коды счетчиков основных поисковых систем. Зачем они нужны?

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

Заводим новые счетчики для нового сайта в Яндексе и Google. Размещаем их как можно выше к верху шаблона сайта в блоке head.

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

Скрытие страниц от индексирования

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

Закрывать можно несколькими способами:

• через rel Canonical — но теперь это работает только в Google (Google такие страницы не индексирует, а Яндекс часто Canonical игнорирует, поэтому в индекс такие страницы попадают),
• через файл роботс с помощью оператора Disallow,
• через мета тег роботс noindex nofollow.

Внешние ссылки

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

Мы рекомендуем:

• Ссылки на свои соцсети оставлять открытыми.
• Ссылки на разработчиков и продвиженцев можем тоже оставлять открытыми (это на усмотрение и договоренности), но лучше закрывать nofollow.
• Ссылки на авторитетные сайты типа Яндекса, Google, Википедии и аналогичных из контентной части можно не закрывать, если они дополняют контент (и при этом не сквозные), так как считается, что это может «хорошо» влиять на ранжирование самой страницы, если вы ссылаетесь на авторитетные ресурсы.
• Другие внешние ссылки закрывать в noindex nofollow: <a href=»http://site.ru» rel=»nofollow»><noindex>Анкор</noindex></a> (<!— noindex —><!—/ noindex —> — валидный код)
• Все ссылки на сторонние сайты должны открываться в новом окне.

Важно! При закрытии ссылки в rel=nofollow донор все равно теряет ссылочный вес, хоть он и не передается сайту-акцептору

Система администрирования сайта

Система администрирования сайта (CMS, ЦМС, админка): важный момент при создании. Систем существует большое количество, есть даже «самописные», то есть программисты могут создать что-то свое. Но нужно понимать, что не все админки могут быть хорошо, удобно и понятно редактируемыми. Какие-то могут иметь ограниченный функционал: если вдруг мы захотим что-то добавить на сайте, система может не поддерживать такую возможно. В этом случае могут быть два варианта:

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

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

Обзор хороших систем администрирования сайта, которые мы рекомендуем:

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

Сбор и анализ требований

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

1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

ТЗ — обязательное условие для успешного выполнения работы!

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

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

Бриф на разработку сайта (DOC-файл, 264.5 КБ)

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

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

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

Далее будут приведены примеры тех.задачний из интернета.

Зачем нужно

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

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

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

Код в шаблоне (валидность кода)

Шаблоны страниц должны строиться по правилам HTML с правильным синтаксисом. Код должен быть валидным. Валидность — это соответствие кода существующим стандартам HTML.

Шаблон страницы строится по правилам:

• Все открывающиеся теги должны иметь закрывающиеся.
• Вложенность должна быть логичная и конечная.
• Если не будет каких-то важных тегов или закрывающих — может поехать верстка. Могут быть проблемы валидации кода, могут не читаться какие-то важные моменты типа микроразметки.
  Например, недавно на одном сайте нашлось, что нет открывающегося тега body, который является обязательным в HTML шаблоне — и у нас не читалась из-за этого микроразметка.
  На другом сайте нашли, что вообще нет открывающегося тега html — что тоже плохо.
• Все основные теги — html, head, body должны быть в каждом шаблоне.
• Необходимо убирать все ненужные блоки html кода, которые не несут полезной нагрузки для страниц.
• Скрипты нужно подгружать из отдельных js-файлов (за исключением скриптов метрики).
• Не оставлять больших кусков закомментированного кода в верстке (оптимально – удалять все комментарии на этапе вывода html-кода).
• Не использовать теги визуального и логического выделения (strong, b, i, em) для оформления в блоках дизайна.
• Не использовать теги заголовков H1-H6 для визуального оформления в дизайне.
• Отказаться от рopup, clickup, bodyclick и popunder (всплывающие, выпрыгивающие окна).
• Все CSS стили должны быть вынесены из тела страницы в отдельные файлы.
• Размер страницы: контент, файлы стилей CSS, графика и изображения, файлы JavaScrip — не должны в сумме превышать 10 Mб т.к. в противном случае страница может быть не проиндексированна.

Как искать «сломанные» теги

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

Из чего состоит ТЗ

Общая информация

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

Статус текущего документа и конфиденциальность.

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

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

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

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

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

Информационная архитектура и интерфейс

1. Структуру сайта. Это так называемые высокоуровневые прототипы.
2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
3. Опись контента. Табличное описание содержания каждой страницы сайта.

Структура сайтаGarrett

• Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг то друга. Это поможет читабельности карты.
• Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
• Выравнивайте «квадратики» страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
• Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
• Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
• Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

Пример карты сайта.Шаблоны страниц

1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

ОговоркаПример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).Описание контента

Требования

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

Необходимо ответственно подойти к написанию ТЗ на сайт

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

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

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

Формирование ЧПУ для страниц

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

Основные моменты при формировании чпу:

1. адрес страниц не должен быть длинным;
2. ЧПУ должен состоять либо только из латинских букв, символов и цифр, либо должен быть написан русскими словами;
3. слова в адресе разделять дефисом. Пробелы и нижние подчеркивания (_) не использовать, так как поисковые системы могут плохо читать такие урлы (в частности, Google может игнорировать написание через нижнее подчеркивание);
4. не использовать символы ! % ( ) » ‘;
5. использовать ключевые запросы в ЧПУ;
6. однотипные ЧПУ с параметрами нужно писать по маске, например параметры типа «290х95х82» можно представлять как: 290х95х82 или 290-95-82.

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

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

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

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

–

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

–

Финальная часть

Тестирование

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

Прочая информация

Укажите, что не подходит под вышеперечисленные пункты.

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

Это сокращает денежные расходы, временные затраты и, что немало важно, сохраняет в целости нервы

Наше сегодняшнее время подходит к концу. Напоследок хочу рассказать о выражении Теодора Рузвельта: «Не ошибается тот, кто ничего не делает». Простая, но очень мудрая мысль. Если вы ошибаетесь в чём-то, это не значит, что вы чего-то не умеете. Это говорит о том, что вы к чему-то стремитесь и совершенствуетесь.

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

Антон 7838

В сухом остатке.

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

Полезные ссылки:

• ГОСТ 34.602-89.
• Нотация Гарретта.

Юрий Шиляевпроектировщик сайтов, консультант.
Директор минского офиса компании Artics Internet Solutions.yuri.shilyaev.com/archives/2007/03/21/356/chto-takoe-%c2%abhoroshee%c2%bb-tz-na-sayt.html

Кто должен составлять ТЗ

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

Рассмотрим на примерах, чем будут различаться их задания.

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

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

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

• перечень страниц сайта;

• краткое описание блоков страниц;

• данные о полях для ввода (например, поля в личном кабинете и т. д.);

• информацию о ссылках и переходах;

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

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

Техническое задание от исполнителя

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

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

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/.

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru.

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

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

Что мы имеем в итоге?

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

• Что нужно сделать в рамках проекта;
• Зачем это нужно, и для каких конкретно целей;
• Где будет использоваться результат проекта (читай, разработка программ), в какой сфере деятельности, и на каком уровне;
• Какие требования должна удовлетворять разработка программ;
• Что нужно сделать в процессе работы над проектом;
• Как будет оцениваться результат со стороны Заказчика;
• Какими документами устанавливается порядок взаимодействия по проекту;
• На чем основана инициация работы над проектом по разработке программ.

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

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

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

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

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