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

Обновлено: 28.04.2024

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

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

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

IEEE STD 830-1998

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

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

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

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

SyRS может содержать следующие разделы:
- 1. Назначение системы
- 2. Содержание системы (границы системы)
- 3. Обзор системы
  - 1. Содержание системы
  - 2. Функции системы
  - 3. Характеристики пользователей
  3. Системные требования
  - 1. Функциональные требования
  - 2. Требования к юзабилити
  - 3. Требования к производительности
  - 4. Интерфейс (взаимодействие) системы
  - 5. Операции системы
  - 6. Состояния системы
  - 7. Физические характеристики
  - 8. Условия окружения
  - 9. Требования к безопасности
  - 10. Управление информацией
  - 11. Политики и правила
  - 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  - 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке
  - 1. Предположения и зависимости
  - 2. Аббревиатуры и сокращений
  SRS может содержать следующие разделы:
  - 1. Назначение
  - 2. Содержание (границы)
    - 3. Обзор продукта
    - 1. Взаимодействие продукта (с другими продуктами и компонентами)
    - 2. Функции продукта (краткое описание)
    - 3. Характеристики пользователей
    - 4. Ограничения
    3. Детальные требования
    - 1. Требования к внешним интерфейсам
    - 2. Функции продукта
    - 3. Требования к юзабилити
    - 4. Требования к производительности
    - 5. Требования к логической структуре БД
    - 6. Ограничения проектирования
    - 7. Системные свойства ПО
    - 8. Дополнительные требования
    - 1. Предположения и зависимости
    - 2. Аббревиатуры и сокращений
    Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
    
    Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
    
    • Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
    • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):
    - 1. Цель.
    - 2. Краткая сводка возможностей.
    - 3. Определения, акронимы и сокращения.
    - 4. Ссылки.
    - 5. Краткое содержание.
    - 1. Обзор вариантов использований.
    - 2. Предположения и зависимости.
    - 1. Описание вариантов использования.
    - 2. Дополнительные требования.
    - 3. Другие функциональные требования.
    - 4. Нефункциональные требования.
    SWEBOK, BABOK и пр.
    
    SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
    
    Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.
    
    А как же Agile?
    
    Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
    
    Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.
    
    Заключение
    
    Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
    
    Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.
    
    Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
    
    Исходные данные: чертежи антенны-башни в формате TIF.
    Антенна-башня, предназначена для установки на палубе морских судов, которая представляет собой алюминиевую сварную пространственную трехгранную форму с основными несущими элементами из круглых профилей.
    
    Конструктивно сооружение состоит из:
    
    Соединение секций - фланцевое.
    Общая высота башни – 8,35 м.
    
    Материал башни – алюминий АМг6 или АМг5. Материал постамента – Сталь 3.
    Диапазон температур эксплуатации от минус 50°C до плюс 55°C;
    Относительная влажность воздуха 95% при температуре плюс 40°C;
    
    Задача:
    Выполнить расчёт антенны-башни. Определить выдерживает ли антенна-башня:
    - - ветровую нагрузку со скоростью потока до 50 м/с с любых направлений ;
    - - качку и длительные наклоны не менее чем до 45° с периодом качки 7-9 с в двух взаимно перпендикулярных эксплуатационных положениях;
    - - вибрации в диапазоне частот от 2 до 100Гц с амплитудой ±1 мм. – для частот тот от 2 до 13,2 Гц ускорения 0,7g(7 м/с2) для частот от 13,2 до 100 Гц ускорение 07g(7 м/с2) в трех взаимно перпендикулярных положениях.
    Состав работ:
    1. Изучение предоставленной Заказчиком проектной документации;
    2. Разработка пространственной конечно-элементной модели;
    3. Постановка граничных условий;
    4. Определение загружений расчетной модели;
    5. Тестирование расчетной модели;
    6. Конечно-элементное исследование напряженно-деформированного состояния модели;
    7. Оценка несущей способности конструктивных элементов;
    8. Анализ и инженерная интерпретация полученных результатов;
    9. Определение нагрузок на опорные конструкции;
    10. Составление технического отчета по результатам расчета пространственной модели.
    Результат, предоставляемый заказчику:
    Отчет, содержащий:
    - текстовую описательную часть;
    - расчеты;
    - графики;
    - эпюры;
    - выводы;
    - рекомендации по усилению конструкции, если потребуется.
    По итогам расчёта исполнитель, при необходимости, выполняет пересчёт конструкции при условии, что для его выполнения не требуется перестройка расчётной модели. В противном случае, Исполнитель выполняет пересчёт за дополнительную плату по согласованию с Заказчиком.
    
    Не указанные заказчиком данные остаются на усмотрение Исполнителя.
    
    Изменение или уточнение технического задания может повлечь изменение стоимости и срок выполнения работ.
    
    Необходимая информация для начала работ:
    
    СОГЛАСОВАНО:
    Исполнитель:
    ООО «Главконструктор»
    
    Техническое задание (техзадание, ТЗ) – спецификация, включающая в себя перечень требований, условий, целей, задач, предоставленных заказчиком в письменном виде, документально оформленных и переданных исполнителю.
    
    Структура разделов ТЗ
    
    Любое техническое задание должно содержать разделы, отражающие сведения:
    - что необходимо сделать;
    - какая цель преследуется;
    - в какой области применяется, какие задачи решает, какие функции выполняет;
    - технические требования;
    - экономические показатели;
    - алгоритм работ для выполнения;
    - порядок приема-сдачи результатов Заказчику;
    - каким образом должно быть задокументирован процесс проведения работ;
    - на основании каких нормативно-технических документов должны проводиться работы.
    Как составить хорошее ТЗ
    
    Оптимальное для дальнейшей работы ТЗ получается только в результате совместной проработки заказчиком и исполнителем. Для этого заказчик первоначально формирует базовое ТЗ, куда включает все свои мысли, пожелания и требования в свободной форме. После этого исполнитель формализует документ, добавляет необходимую для проектирования информацию. Документ неоднократно согласовывается, для того, чтобы все стороны пришли к однозначному его толкованию, и подписывается.
    
    Однако ни одно ТЗ, как бы тщательно не было составлено, если речь идет о разработке комплексного изделия, не сможет предусмотреть всех нюансов, которые появляются в процессе работы. Это нормально, и это риск как исполнителя, так и заказчика. Проектирование - творческий и иногда непредсказуемый процесс. Важен постоянный, хорошо налаженый диалог между заказчиком и исполнителем и готовность обеих сторон быстро адаптироваться к новым требованиям и условиям.
    
    Основные ГОСТы на ТЗ
    
    Перечисленные документы являются общими для всех предметных областей. Однако существуют и другие российские ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание» для своих узко-специфических отраслей.
    
    Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
    
    Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
    
    Время чтения: 7 минут.
    
    Отправная точка — требования
    
    Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
    
    К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег.
    
    Жутко правда? Бюджет уже потрачен и срок истек.
    
    Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
    
    Удобный вид требований — ТЗ
    
    Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
    
    Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
    
    Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.
    
    Рецепт грамотного ТЗ
    
    Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
    - Концептуальная модель
    - Функциональная карта
    - Путь пользователя
    - Пользовательский интерфейс
    - Программные интерфейсы
    - Нефункциональные требования
    Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
    
    Концептуальная модель
    
    В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
    
    Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
    
    Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
    
    Стоит рассказать о типах пользователей и их ключевых отличиях.
    
    Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
    
    И в завершении расскажите о компонентах вашего продукта.
    
    Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
    
    Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
    
    Функциональная карта
    
    Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
    
    Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
    
    Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
    
    Путь пользователя
    
    Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
    
    Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
    
    Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
    
    Например: на экране регистрации пользователь может:
    перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
    
    Пользовательский интерфейс
    
    Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
    
    Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
    
    Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
    
    Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
    
    Программные интерфейсы
    
    Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
    
    Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
    
    Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
    
    Нефункциональные требования
    
    Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
    
    Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим.
    
    Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации. Они требовали её ещё до появления самого интернета. Поэтому для расширения кругозора и для пользы представителей нецифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.
    
    Для чего нужно техническое задание?
    
    Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.
    
    Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее.
    
    Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.
    
    Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.
    
    Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат.
    
    Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.
    
    Кто должен составлять техническое задание
    
    Чтобы понять, как составить техзадание, важно определиться с тем, кто именно это будет делать. На этот вопрос нет однозначного ответа — ТЗ для задачи может составить заказчик или исполнитель, в отдельных случаях — это совместная работа.
    
    Заказчик
    
    В этом случае исполнитель будет четко понимать, что и когда ему потребуется делать. В результате получится точно рассчитать стоимость работ и срок, отведенный на их выполнение. Однако иногда составитель ТЗ не понимает того, что именно должен предоставить им исполнитель, из-за чего с составлением ТЗ возникают проблемы.
    
    Исполнитель
    
    Исполнитель, занимающийся составлением ТЗ, присылает заказчику бриф с вопросами по задаче. Так специалист выясняет цель работы и свою пользу для клиента. После этого проходит интервью, и в режиме диалога стороны уточняют рабочие нюансы. Исполнитель изучает конкурентов и целевую аудиторию, чтобы добавить эту информацию в техническое задание.
    
    Такой способ составления ТЗ удобен, когда заказчик полностью доверяет исполнителю, а исполнитель достаточно компетентен, чтобы разобраться в задаче самостоятельно.
    
    Совместно
    
    Совместное формулирование ТЗ начинается с того, что заказчик озвучивает исполнителю требования относительно будущего задания. Подрядчик, в свою очередь, предлагает, как улучшить проект, и только после этого составляется техническое задание. Этот способ, как и предыдущий, работает на доверии, этичности и профессионализме сторон.
    
    Как составить техническое задание
    
    Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ.
    
    В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России.
    
    Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.
    
    ГОСТ 19 был введён в 1980 году. Учитывая, что основные принципы программного обеспечения почти не поменялись, документ еще не утратил своей актуальности. Это можно сравнить со строительством зданий: меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.
    
    Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».
    
    Само техническое задание должно содержать следующие пункты:
    - Введение;
    - Основания для разработки;
    - Назначение разработки;
    - Требования к программе или программному изделию;
    - Требования к программной документации;
    - Технико-экономические показатели;
    - Стадии и этапы разработки;
    - Порядок контроля и приемки;
    - Приложения.
    Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.
    
    Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».
    
    Текст технического задания строится по структуре:
    - Общие сведения;
    - Назначение и цели создания (развития) системы;
    - Характеристика объектов автоматизации;
    - Требования к системе;
    - Состав и содержание работ по созданию системы;
    - Порядок контроля и приемки системы;
    - Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
    - Требования к документированию;
    - Источники разработки.
    Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.
    
    ISO/IEC/IEEE 29148
    
    Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
    
    Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.
    
    По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
    
    SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
    
    Общая схема строится следующим образом:
    - - Введение. Назначение продукта или системы, содержание, обзор функций и пользователей.
      - Системные требования. Требования к юзабилити и производительности системы, состоянию, физическим характеристикам, окружению и безопасности, правилам. Для приложений — требования к внешним интерфейсам, к производительности, структуре БД, функциям и юзабилити.
      - Тестирование и проверка. Процедуры тестирование по каждому из пунктов предыдущего раздела.
      - Приложения. Термины, схемы, история правок.
      Маркетинг
      
      Как отслеживать звонки с сайта: способы и пруфы
      
      Как отслеживать звонки с сайта: способы и пруфы
      
      Порядок документирования требований
      
      Выйдем немного за пределы тематики и скажем несколько слов о том, из чего состоит весь процесс документального сопровождения продукта. Ведь он не ограничивается техническим заданием. Сложность сопроводительной документации растёт вместе со сложностью и масштабом продукта.
      
      Разработка лендинга на Тильде или запуск таргетированной рекламы Вконтакте радикально отличаются от создания высоконагруженной биллинговой системы банка. Если первые два продукта способен создать один человек, то последний может потребовать команды из нескольких десятков специалистов из многих областей.
      
      В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.
      
      Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:
      - Цель и назначение продукта;
      - Предполагаемый бюджет; .
      Вопросов на которые отвечает заказчик, может быть до 20–30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.
      
      Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.
      
      Виджет обратного звонка, как инструмент, подходит не только для созвонов с партнерами, но и для клиентского сервиса. Это всплывающее окно предлагает указать контактный номер,по которому перезвонит сотрудник поддержки. С виджетом обратного звонка от Calltouch вы можете собирать заявки даже в нерабочее время, а также записывать и тегировать звонки.
      - Повысьте конверсию сайта на 30%
      - Экономьте на тарифах: от 5 рублей в минуту
      - Адаптируйте форму под ваш сайт. Без разработчика
      - Используйте гибкие настройки показа
      - Стройте отчеты по звонкам: от показа виджета до ключевого слова
      Технико-коммерческое предложение
      
      Здесь речь заходит о действительно крупных проектах. В противном случае нецелесообразно прилагать излишние усилия к созданию подобных документов.
      
      ТКП разрабатывается в рамках маркетинговых мероприятий, когда продукт предлагается потенциальным заказчиком. Если у вас есть собственная концепция, готовая к внедрению или масштабированию, на её основе можно сделать предложение.
      
      Документ содержит не просто идею и общее описание, но некоторые технические подробности. На их основе заказчику удобнее принимать решение, так как он сразу может увидеть, насколько характеристики продукта согласуются с той инфраструктурой, которая есть в наличии.
      
      Бесполезно предлагать промышленные системы вентиляции маленьким кофейням. В других случаях помещение может отвечать требованиям, но электроснабжение окажется несовместимым с требованиями оборудования по питанию.
      
      Технические требования
      
      Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.
      
      Техническое задание
      
      Собственно, предмет статьи. Предварительные сведения даны в предыдущих пунктах, а ценные советы ждут вас в следующем разделе.
      
      Технический проект
      
      Этап «живого» проектирования продукта. Здесь начинаются активные действия по разработке решений согласно ТЗ. В ходе работы уточняются и проясняются отдельные нюансы, требования, доработки.
      
      В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).
      
      Эксплуатация
      
      Важно помнить, что после сдачи проекта стороны распределяют между собой обязанности по поддержанию работоспособности системы. Это тоже должно быть прописано — например, в техническом задании, если не предусмотрено другого порядка.
      
      Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.
      
      Когда условия работы или технологии модифицируются, приходится вносить правки в документы и внедрять изменения в продукт.
      
      Рекомендации по составлению ТЗ
      
      Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.
      
      Дайте подрядчику общую информацию
      
      Подрядчик должен понимать, чем занимается компания и кто ваша целевая аудитория. Так исполнитель сможет глубже вникнуть в поставленную задачу и избежать элементарных ошибок. При озвучивании идеи важно отметить конкурентные преимущества и особенности проекта.
      
      Покажите конкурентов
      
      ТЗ должно содержать ссылки на похожие проекты с дополнительным описанием. Это поможет исполнителю оценить удачные примеры чужих разработок и избежать характерных проблем при реализации. Кроме того, выявление чужих особенностей позволяет создать собственное уникальное решение.
      
      Распишите сценарии использования продукта
      
      Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.
      
      Ведите историю правок
      
      В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие.
      
      Составляйте список терминов и сокращений
      
      Это правило грамотного подхода к формированию документа. Основной текст предваряется словарём, в котором записаны специальные термины, не являющиеся общеупотребимыми. Особенно уделите внимание тем аббревиатурам и словам, которые применяются только в данному проекту.
      
      Прописывайте каждую деталь
      
      Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.
      
      Пропишите периодичность и порядок оплаты сервера — передаст ли заказчик обязанность бухгалтерии или же вы будете получать ежемесячную абонентскую плату, из которой сами должны распределять средства на те или иные нужды.
      
      Позаботьтесь о пользователях. Продумайте, какими браузерами и устройствами они пользуются, какое у них разрешение. Адаптируйте сайт, если речь идёт о нём, под различные технические характеристики устройств.
      
      Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.
      
      Опишите требования к проверке проекта
      
      На этапе составления техзадания продумайте чек-лист, по которому заказчику будет понятна степень успешности реализованного проекта. Так можно быстро оценить проделанную работу и не забыть о значимых нюансах.
      
      Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.
      - Автоматически соберет данные с рекламных площадок, сервисов и CRM в 1 окне
      - Бесплатные интеграции c CRM и другими сервисами: более 50 готовых решений
      - Анализируйте воронку продаж от показов до кассы
      - Оптимизируйте свой маркетинг с помощью подробных отчетов: дашборды, графики, диаграммы
      - Кастомизируйте таблицы, добавляйте свои метрики. Стройте отчеты моментально за любые периоды
      Когда ТЗ не нужно
      
      Техническое задание требуется не каждому продукту. Иногда достаточно предпроектного исследования, чтобы изучить потребности клиентов вместе с аналитиком. После этого следует решать, есть ли необходимость в ТЗ.
      
      Зачастую более гибкие методологии, работающие на создание продукта, позволяют успешно и оперативно использовать ресурсы компании. Например, сначала формируется маленький прототип, который тестируют, и на основании обратной связи от клиентов корректируют до полноценного продукта.
      
      Выводы
      
      Техническое задание — важный этап подготовки к работе над проектами. Его составление помогает заказчику сформулировать суть задачи, а исполнителю дает понять, как ее выполнить. Составить ТЗ может заказчик, исполнитель или заказчик вместе с исполнителем. Выбор варианта сотрудничества зависит от сложности работ и навыков специалиста.
      
      Читайте также:

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

ГОСТ 34

ГОСТ 19

IEEE STD 830-1998

SWEBOK, BABOK и пр.

А как же Agile?

Заключение

Структура разделов ТЗ

Как составить хорошее ТЗ

Основные ГОСТы на ТЗ

Отправная точка — требования

Удобный вид требований — ТЗ

Рецепт грамотного ТЗ

Концептуальная модель

Функциональная карта

Путь пользователя

Пользовательский интерфейс

Программные интерфейсы

Нефункциональные требования

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

Кто должен составлять техническое задание

Заказчик

Исполнитель

Совместно

Как составить техническое задание

ISO/IEC/IEEE 29148

Порядок документирования требований

Технико-коммерческое предложение

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

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

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

Эксплуатация

Рекомендации по составлению ТЗ

Дайте подрядчику общую информацию

Покажите конкурентов

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

Ведите историю правок

Составляйте список терминов и сокращений

Прописывайте каждую деталь

Опишите требования к проверке проекта

Когда ТЗ не нужно

Выводы