Тз как приложение к тз

Обновлено: 07.01.2025

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

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

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

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

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

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

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

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

Стейкхолдеры со стороны бизнеса: собственники, руководители, акционеры.

Стейкхолдеры со стороны разработки: разработчики, PM-менеджеры, QA-специалисты.

Стейкхолдеры со стороны внешних систем (от бизнеса или команды исполнителя) — архитекторы ПО либо разработчики.

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

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

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

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

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

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

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

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

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

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

Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.

Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.

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

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

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

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

Заказчик

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

Исполнитель

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

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

Совместно

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

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

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

В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 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 рублей в минуту
- Адаптируйте форму под ваш сайт. Без разработчика
- Используйте гибкие настройки показа
- Стройте отчеты по звонкам: от показа виджета до ключевого слова
Технико-коммерческое предложение

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

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

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

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

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

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

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

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

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

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

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

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

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

Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.

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

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

Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.

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

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

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

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

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

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

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

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

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

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

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

Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.

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

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

Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

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

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

Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.

Сквозная аналитика
- Автоматически соберет данные с рекламных площадок, сервисов и CRM в 1 окне
- Бесплатные интеграции c CRM и другими сервисами: более 50 готовых решений
- Анализируйте воронку продаж от показов до кассы
- Оптимизируйте свой маркетинг с помощью подробных отчетов: дашборды, графики, диаграммы
- Кастомизируйте таблицы, добавляйте свои метрики. Стройте отчеты моментально за любые периоды
Когда ТЗ не нужно

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

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

Выводы

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

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, 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.

Система разработки и постановки продукции на производство

Требования к содержанию и оформлению

System of products development and launching into manufacture. Technical assignment. Requirements to contents and form of presentation

Дата введения 2017-09-01

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"

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

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении" (ВНИИНМАШ)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа по стандартизации

Минэкономики Республики Армения

4 Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. N 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Июль 2020 г.

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

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

1 Область применения

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

2 Нормативные ссылки

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

ГОСТ 2.001 Единая система конструкторской документации. Общие положения

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.103 Единая система конструкторской документации. Стадии разработки

ГОСТ 2.105 Единая система конструкторской документации. Общие требования к текстовым документам

ГОСТ 2.116 Карта технического уровня и качества продукции

ГОСТ 2.118 Единая система конструкторской документации. Техническое предложение

ГОСТ 2.119 Единая система конструкторской документации. Эскизный проект

ГОСТ 2.120 Единая система конструкторской документации. Технический проект

ГОСТ 2.301 Единая система конструкторской документации. Форматы

ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы*

* В Российской Федерации действует ГОСТ Р 2.601-2019.

ГОСТ 3.1001 Единая система технологической документации. Общие положения

ГОСТ 3.1102 Единая система технологической документации. Стадии разработки и виды документов. Общие положения

ГОСТ 14.201 Обеспечение технологичности конструкции изделий. Общие требования

ГОСТ 15.012 Система разработки и постановки продукции на производство. Патентный формуляр

ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 27.003 Надежность в технике. Состав и общие правила задания требований по надежности

ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 16504 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения

ГОСТ 19433 Грузы опасные. Классификация и маркировка

ГОСТ 21964 Внешние воздействующие факторы. Номенклатура и характеристики

ГОСТ 28934 Совместимость технических средств электромагнитная. Содержание раздела технического задания в части электромагнитной совместимости

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 техническое задание (ТЗ): Исходный технический документ для проведения работы, устанавливающий требования к создаваемому изделию (его СЧ или КИМП) и технической документации на него, а также требования к объему, срокам проведения работы и форме представления результатов.

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

3.3 разработчик: Предприятие (организация, объединение, юридическое или физическое лицо), осуществляющее разработку продукции в установленном порядке.

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

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

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

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

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

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

3.10 рабочая конструкторская документация (РКД): Совокупность конструкторских документов, предназначенных для изготовления, контроля, приемки, поставки, эксплуатации и ремонта изделия.

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

4 Сокращения

В настоящем стандарте применены следующие сокращения:

ЕСКД - единая система конструкторской документации;

ЕСПД - единая система программной документации;

ЗИП - запасной инструмент и принадлежности;

КД - конструкторские документы (документация);

КИМП - комплектующие изделия межотраслевого применения;

МГС - Межгосударственный совет по стандартизации, метрологии и сертификации;

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

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

коротко о структуре ТЗ на разработку отчета

1. Контактная информация инициатора работы

Тут все просто - разработчику нужна контактная информация для связи с заказчиком. Её содержание и объем определяется весьма индивидуально.

Нам достаточно следующих полей: Инициатор разработки, подразделение, должность, телефон, e-mail.

2. Требования к срокам реализации

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

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

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

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

3. Требования к отчету

Название отчета

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

Назначение отчета

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

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

Тут же можно использовать рекомендации agile-сообщества в части формирования user story:

Я как, <роль пользователя>, <хочу получить отчет>, <с такой-то целью> .

Источники данных

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

Логика работы отчета

Описание логики выборки данных, условий и формул расчета

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

Описание требований к пользовательским настройкам и интерфейсным решениям отчета

Визуальный макет

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

Внешний вид отчета прикладывается как приложение.

4. Порядок сдачи-приемки работ

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

Работа сдается заказчику путем формирования отчетной формы на рабочей базе заказчика. При этом заказчиком проверяется соответствие внешнего вида отчетной формы и корректности её заполнения.

5. Ограничения и гарантии

Перечень условий, необходимых для корректного формирования отчета (расчет себестоимости и т.д.).

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

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

Теперь перейдем к согласованию требований и сдаче работ

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

при согласовании требований - от заказчика к исполнителю

при сдаче работ - обратно от исполнителя к заказчику.

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

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

Отдельно остановлюсь на мысли из единственной (до текущей) на сегодня на Инфостарте публикации по этой тематике.

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

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

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

Не все поданные пользователями заявки должны быть выполнены.

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

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

Поэтому первый пункт листа согласования:

Дата рассмотрения требования:

(принято/не принято + код причины отказа)

Определение плановой даты разработки отчета

Помните в начале мы говорили про “Требования к срокам реализации”. Так вот, их тоже нужно согласовать. То что заказчик отразил как желаемая дата реализации - это всего лишь желаемая дата реализации. Реальная календарная плановая дата разработки зависит от трех параметров:
1. Трудоемкость разработки (оценка работ - большая отдельная тема)
2. Приоритет работы (в корп секторе должна быть метода определения приоритетности работ)
3. Процент времени специалиста, отведенного под разработку (особенно, если мы говорим про отделы сопровождения, у вашего отдела ведь тоже решение текущих вопросов (инцидентов) - это первоочередной тип работ?!)
То есть если трудоемкость разработки отчета 8 часов и заявлена она с самого утра, то это вовсе не значит, что вечером будет готово. Именно поэтому понятия трудоемкость и календарная дата реализации нужно разносить.

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

Резюме:

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

В первом описывается “хотелка” заказчика, во втором - её формализация. Первое понятно заказчику, второе - разработчику. Контрольный пример - приземляет первые две сущности.

Остается только работать по принципу: сделал - молодец, не сделал - не молодец. Как определить что сделал?

Все остальное философия.

Вот и всё. Так просто и так сложно одновременно. Главное быть последовательным и все будет хорошо. Или как говорится “Нормально делай - нормально будет”.

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

Читайте также: