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

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

Скриншот страницы 1 Образца ТЗ на разработку ПО

Техническое задание (ТЗ) на разработку ПО регламентируется определенными нормативными документами – ГОСТами. В этих документах устанавливаются стандарты оформления и содержания ТЗ, обеспечивая качественное структурирование данных и их понятность для обеих сторон сделки. Обычно ГОСТ 34.601-90 применяется для разработки программных продуктов в государственных и крупных компаниях. Для ПО, разрабатываемого для среднего и мелкого бизнеса, компания-разработчик может предлагать свой вариант ТЗ.

Можно выделить обязательные разделы ТЗ, которые должны присутствовать в любой документации на разработку ПО:

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

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

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

Общая информация о проекте

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

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

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

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

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

Этот раздел посвящен основным функциям системы, например, таким, как:

• обработка данных;
• ведение реестра;
• заполнение категорий;
• контроль исполнения;
• и т. д.

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

«Основные функции» — пример заполнения

Роли системы

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

«Роли системы» — пример заполнения

Регистрация и авторизация

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

«Авторизация» — пример заполнения

«Регистрация» — пример заполнения

Навигация

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

«Навигация» — пример заполнения

Интеграция

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

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

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

1. Производительность;
2. Безопасность;
3. Масштабируемость;
4. Удобство использования.

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

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

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

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

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

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

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

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

Этапы и сроки выполнения работ

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

1. Анализ;
2. Проектирование;
3. Разработка;
4. Тестирование;
5. Внедрение;
6. Поддержка.

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

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

Требования к документации

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

1. Техническое задание (ТЗ);
2. Пояснительная записка;
3. Спецификации, описание архитектуры системы;
4. Схемы;
5. Руководства пользователя, администратора;
6. Программа и методика испытаний;
7. Программа и отчет о проведении инструктажа;
8. SLA (соглашение об уровне обслуживания).

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

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

«Требования к документированию» — пример заполнения

Порядок приемки и критерии качества

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

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

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

«Требования к приемке» — пример заполнения

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

«Гарантии качества» — пример заполнения

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

Напишите нам, чтобы получить образец ТЗ в формате docx