Гост 34.602-89 техническое задание на создание автоматизированной системы (взамен гост 24.201-85)

Основные принципы

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

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

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

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

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

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

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

Пример

Статика

Страница “Раздел каталога”

  1. “Хлебные крошки”
  2. “Дерево каталога”
  3. “Фильтрация. Общие положения”
  4. “Фильтрация. Текст”
  5. “Фильтрация. Текст и изображение”
  6. “Фильтрация. Диапазон”
  7. “Сортировка. По умолчанию”
  8. “Сортировка. По возрастанию цены“
  9. “Сортировка. По убыванию цены”
  10. “Превью товара. Плитка”
  11. “Пагинация. Постраничная”
  12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

Динамика

Функционал “Фильтрация. Общие положения”

  • выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
  • название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
  • цвет кнопки фильтра меняется на вид используемого фильтра
  • в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
  • у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
  • пагинация сбрасывается

Функционал “Превью товара. Плитка”

  1. Цена (целое число в рублях РФ)
  2. Название товара
  3. Метка “В магазине” или “С витрины”
  4. Изображение
  5. Размер
  6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
  7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

Административная панель

Товар

  1. Название (текст)
  2. Бренд (радио)
  3. Изображения
  4. Цена (целое число)
  5. Описание (текстовый блок)
  6. Тип (магазин/витрина, радио)
  7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
  8. Статус. Возможны варианты:
    1. на продаже
    2. на модерации
    3. на доработке
    4. отклонен
    5. продан
    6. не прошел проверку
    7. отменен Продавцом
  9. Размер с бирки (необязательное). Текстовое поле без валидации

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

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

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

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

  1. Организация
  2. Информация
  3. Коммуникация
  4. Юрисдикция.

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

Информационная составляющая ТЗ должна быть полной, но сжатой.

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

С коммуникациями несколько сложнее. Почему? Да потому что коммуникации, да ещё и в процессе относительно творческом, сложны всегда. Особенно, если говорить на разных языках. А языков тут может быть несколько, более точно – по числу участников проекта под кодовым названием «разработка программ».

Проще говоря:

  1. Клиент, он же Заказчик
  2. Менеджер проекта
  3. Исполнители проекта, они или он: программист(ы)
  4. Другие возможные участники, имеющие мнение: как сделать, как сделать лучше, и чем всё должно закончиться.

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

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

Техническое задание программного продукта пример. Пишем техническое задание

Что такое техническое задание на разработку программного обеспечения?

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

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

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

Как написать ТЗ на разработку программного обеспечения?

Нет стандартного метода написания ТЗ, но мы можем дать несколько советов:

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

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

Вот пример простого плана ТЗ на ПО:

  1. Сфера применения
  2. Обзор системы
  3. Ссылки
  4. Определения
  5. Примеры использования
  6. Функциональные требования
  7. Нефункциональные требования

После создания плана можно писать спецификацию. Вот несколько советов:

Выберите для написания лучшего

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

Сделайте информацию визуальной

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

Не документируйте слишком много

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

Создайте онлайн-версию ТЗ и постоянно обновляйте её

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

1. Введение 1.1. Наименование программы 1.2. Назначение и область применения программы 2. Требования к программе 2.1. Требования к функциональным характеристикам программы 2.2. Требования к надежности программы 2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2. Время восстановления программы после отказа 2.2.3. Отказы программы из-за некоректных действий оператора 3. Условия эксплуатации программы 3.1. Климатические условия эксплуатации программы 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4. Требования к информационной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования 4. Требования к программной документации 4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработки программы 6. Стадии и этапы разработки программы 6.1. Стадии разработки программы 6.2. Этапы разработки программы 6.3. Содержание работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний 7.2. Общие требования к приемке работы

ТЗ для сайта — важные моменты

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

Детальное описание сущностей

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

  1. Вы создаёте сайт-визитку, состоящий исключительно из нескольких страниц. В этом случае, сущностью будет «Страница», у каждой из которых есть свой заголовок, содержимое и другие опции.
  2. Если вы захотите добавить на свой сайт раздел с новостями, то «Новость» будет новой сущностью. Помимо заголовка и содержимого эти материалы могут иметь, например, дату публикации или автора.
  3. Кстати, «Автор» также является сущностью — у каждого из них может быть уникальная фотография и имя. В этом случае, сущности могут быть связаны друг с другом, как новость и её автор.

Узнать больше о проекте

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

Функциональные особенности

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

3.2. Требования к квалификации и численности персонала

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

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

а) задача поддержания работоспособности технических средств;

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

в) задача установки (инсталляции) программы.

г) задача создания резервных копий базы данных.

Не игнорируйте исполнителя — отвечайте

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

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

Квитанция

Назначение: Предназначен для отражения начислений абонентам

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление оплаты» 

Реквизит

Тип

Назначение

Организация

Справочник Организации

Ссылка на собственное юридическое лицо

Ручная Корректировка

Булево

Признак ручной корректировки проводок документа

Табличная часть: Показания счетчиков

Реквизит

Тип

Назначение

Контрагент

Справочник Контрагенты

Ссылка на абонента

ДоговорКонтрагента

Справочник Договоры контрагентов

Ссылка на договор  с абонентом

Номенклатура

Справочник Номенклатура

Ссылка на номенклатуру с типом «Услуга» для учета взаиморасчетов с контрагентом

Тариф

Справочник Тарифы

Тариф абонента согласно договора

Счетчик

Справочник Счетчики

Ссылка на счетчик абонента

ВидНачисления

Перечисление ВидыНачислений

Ссылка на вид начисления (по показания счетчика или по установленной мощности)

ПотребленнаяЭнергия

Число

Потребленнаяэненргия

Значение тарифа

Число

Значение тарифа на дату документа

Начисленно

Число

Сумма начисленная абоненту

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

Документ проводится:

—  по плану счетов хозрасчетный :

 — по плану счетов налоговый :

Печатные формы

Реестр начислений

Квитанция на оплату со штрих кодом

Штрих-код формируется при помощи шрифта «Infograftbarcode»

Алгоритм формирования  Строка «0000»+Код договора абонента+Начислено

Макет квитанции прилагается в файле КВ_1.mxl

Алгоритм заполнения

Документ заполняется на основании справочника «Договора контрагентов» .  

  1. Из справочника выбираются договоры, у которых, согласно регистра сведений «Сроки действия договоров»  ДатаНачала меньше даты документа и ДатаОкончания больше даты документа;
  2. Выбираются счетчики соответствующие этим договорам;
  3. Для счетчиков определяется потребление энергии как оборот по регистру накопления «Потребление энергии» за период между датой документа и датой предыдущего документа, если дата предыдущего документа неизвестна, то берется весь оборот по регистру. Полученное значение записывается в поле «ПотребленнаяЭнергия»
  4. Устанавливается тариф согласно договора и значение тарифа на дату документа ;
  5. Устанавливается вид начисления «По показаниям счетчика»;
  6. Рассчитывается Поле Начислено как произведение  ПотребленнаяЭнергия на ЗначениеТарифа.

Алгоритм проведения

Для каждой строки табличной части  «Показания счетчиков» должны быть сделаны следующие проводки:

1.

Дт. 62.01 с аналитикой СубконтоДт1 – Контрагент, СубконтоДт2 —  Договор контрагента

Кт. 90.01 с аналитикой СубконтоКт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоКт2 – Номенклатура.СтавкаНДС.

Сумма проводки – значение реквизита «Начислено»;

2.

Если есть Кредитовое сальдо По счету 62.02, то проводится зачет аванса с проводкой 

Дт. 62.02 с аналитикой СубконтоДт1 – Контрагент, СубконтоДт2 —  Договор контрагента

Кт. 62.01 с аналитикой СубконтоКт1 – Контрагент, СубконтоКт2 —  Договор контрагента

Сумма проводки – минимальное значение из кредитового сальдо по счету 62.02 и значения реквизита  «начислено»)

3.

Дт. 90.03 с аналитикой СубконтоДт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоДт2 – Номенклатура.СтавкаНДС

Кт. 62.01 с аналитикой СубконтоКт1 – Контрагент, СубконтоКт2 —  Договор контрагента

Сумма проводки =  «Начисленно»* СтавкаНДС/(100+ставкаНДС), где СтавкаНДС  — «Номенклатура.СтавкаНДС»

Где искать авторов для сайта и сколько им платить?

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

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

Минимальные расценки, позволяющие найти приемлемых по качеству авторов:

  • Простой рерайтинг (один источник) – от 50-75 руб. за 1000 знаков.
  • Простой копирайтинг или рерайтинг нескольких источников – от 100-150 руб. за 1000 знаков.
  • Копирайтинг – от 150-200 руб. за 1000 знаков.
  • Тексты для специалистов, требующие от автора наличия профильного образования (пример: медицина, инженерия, строительство, ИТ, реклама и маркетинг) – от 200-300 руб. за 1000 знаков.

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

Найти хороших исполнителей можно в каталоге копирайтеров или на бирже сайта Kadrof.ru. На бирже можно бесплатно разместить вакансию для копирайтеров.

Пишем техническое задание

17.11.2014

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

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

Что такое техническое задание на разработку программного обеспечения?

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

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

Почему это важно?

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

  • Экономит время на коммуникации;
  • Минимизирует трудоёмкость разработки;
  • Позволяет давать клиентам обратную связь;
  • Помогает избежать дублирования задач;
  • Способствует переходу к новым пользователям или новым машинам;
  • Разбивает проблему на части;
  • Служит в качестве основного документа для проверки процессов тестирования и валидации;
  • Отсылка к последним техническим заданиям помогает выявить неточности и технологические недостатки.

Как написать ТЗ на разработку программного обеспечения?

Нет стандартного метода написания ТЗ, но мы можем дать несколько советов:

Создайте схему

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

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

Вот пример простого плана ТЗ на ПО:

  1. Цель
  2. Сфера применения
  3. Обзор системы
  4. Ссылки
  5. Определения
  6. Примеры использования
  7. Функциональные требования
  8. Нефункциональные требования

После создания плана можно писать спецификацию. Вот несколько советов:

Выберите для написания лучшего

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

Сделайте информацию визуальной

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

Не документируйте слишком много

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

Создайте онлайн-версию ТЗ и постоянно обновляйте её

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

Тэги: советы, технические задания

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

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

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

  • полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
  • исключать противоречивые сведения,
  • быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.
  • общие данные о проекте (название продукта, кем и для чего будет использоваться);
  • общие требования к ПО (к структуре, функциям, в частности приложить схему архитектуры и описать связь подсистем, виды интерфейсов всех составляющих для каждой из ролей пользователей — готовый дизайн или его концепцию);
  • подробный план работ (перечень этапов, сроки по ним);
  • порядок тестирования и приемки (виды и состав испытаний продукта в целом и отдельных частей);
  • перечень действий для запуска продукта;
  • требования к документированию процесса и результата разработки.
  1. детaлей:
    • пользователи программного продукта: роли, права и функции,
    • описание алгоритмов обработки данных,
    • перечень открытых и закрытых протоколов,
    • требования к безопасности данных на всем жизненном цикле,
    • список компонентов (платных, свободных), которые будут использоваться в разработке,
  2. примеров:
    • при наличии аналогов, интегрируемых систем указываются ссылки на них,
    • в описании работы системы приводится описание типичных сценариев взаимодействия с ней пользователей,
    • примеры входящих данных и формат данных взаимодействия подсистем (таблицы, базы, страницы и др.),
    • примеры исходящих данных (виды отчетов и экспортируемых файлов),
  3. производительности и надежности:
    • указание уровней нагрузки системы (день, месяц, максимальный),
    • требования к производительности, сохранности,
    • обоснование выбора оборудования запуска программного обеспечения,
    • указание хостинга серверной части.

Этапы и результаты проектирования

  1. Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
  2. Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
  3. Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
  4. Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
  5. Контроль: архитектор устраняет замечания менеджера проектов.
  6. Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.
  1. Что делаем (описание продукта, функционала, пользователей)?
  2. Как делаем (архитектура)?
  3. Как проверить, что цель достигнута (тестирование, критерии оценки)?

бесплатной оценке проекта

ТЗ по ГОСТу: поможет ли оно сделать классное приложение

У ТЗ на разработку мобильного приложения есть стандарты качества: отечественные ГОСТы и зарубежные SRS (software requirements specification). У SRS более разветвлённая структура: его содержание похоже на реферат с введением, главами, подглавами и заключением. Но и в том и в том стандарте есть общие смысловые
части:

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

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

Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете
стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:

  1. Гостовский документ кажется нам слишком громоздким. В нём сложно ориентироваться. Если вы приходите за конкретной информацией и не знаете, где её искать, вам придётся изучить весь документ. На листание
    страниц уходит время, которое можно было потратить на завершение других задач.
  2. ТЗ по ГОСТу не подходит для сотрудничества по Agile. Стандарт, написанный в конце
    80-х, не знает, что проектная разработка может идти спринтами. Приложение разрабатывается поэтапно.
    У каждого спринта — своя документация, поэтому монументальное ТЗ будет не к месту.

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