Пример и образец ТЗ для 1С

Данные > Статьи и инструкции > Инструкция

ИНСТРУКЦИЯ 1С 8, 1С 7.7 → перейти в меню [СТАТЬИ И ИНСТРУКЦИИ]

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

(название учреждения, организации)

Техническое задание на разработку/доработку в системе 1С

1. Общие сведения

1.1. Наименование проекта:
1.2. Заказчик:
1.3. Исполнитель:
1.4. Дата создания ТЗ:
1.5. Сроки выполнения работ:
1.6. Версия платформы 1С: (например, УТ 11, БП 3.0, ЗУП 3.1 и т.д.)
1.7. Конфигурация 1С (например, УТ 11, БП 3.0, ЗУП 3.1 и т.д.)
1.8. Этапы разработки

План работ
Описание этапов проекта:
Анализ требований – 1 неделя.
Проектирование – 2 недели.
Разработка – 4 недели.
Тестирование – 2 недели.
Внедрение – 1 неделя.
Критерии приемки
Условия, при которых проект считается завершенным:
Все функции работают корректно.
Выполнены тесты на производительность.
Подписан акт приемки.

2. Цель и задачи проекта

2.1. Цель проекта:
(Краткое описание цели, например, автоматизация процесса, доработка функционала, интеграция с другими системами и т.д.)

2.2. Задачи:
(Перечень задач, которые необходимо решить, например:)

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

3. Описание текущей ситуации

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

3.2. Описание бизнес-процессов:
(Краткое описание процессов, которые необходимо автоматизировать или изменить.)

4. Требования к функционалу

4.1. Описание нового функционала:
(Подробное описание того, что должно быть реализовано. Например:)

Добавить справочник "Контрагенты" с полями: Наименование, ИНН (УНП), КПП, Адрес.
Разработать отчет "Анализ продаж" с группировкой по периодам и контрагентам.
Настроить интеграцию с CRM-системой для выгрузки заказов.

4.2. Требования к интерфейсу:
(Описание требований к пользовательскому интерфейсу, например, расположение элементов, удобство использования и т.д.)

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

5. Требования к данным

5.1. Источники данных:
(Описание источников данных, например, существующие справочники, внешние системы и т.д.)

5.2. Форматы данных:
(Требования к форматам данных, если предполагается обмен с внешними системами.)

5.3. Миграция данных:
(Необходимость переноса данных из старых систем или конфигураций.)

6. Интеграция с другими системами

6.1. Описание систем для интеграции:
(Например, CRM, ERP, сайт, бухгалтерские системы и т.д.)

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

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

7.1. Перечень отчетов:
(Список отчетов, которые необходимо разработать или доработать.)

7.2. Параметры отчетов:
(Описание параметров, которые должны быть доступны пользователю для формирования отчетов.)

8. Требования к тестированию

8.1. Этапы тестирования:
(Описание этапов тестирования, например, модульное тестирование, интеграционное тестирование, приемочное тестирование.)

8.2. Критерии приемки:
(Условия, при которых работа считается выполненной и принятой заказчиком.)

9. Документация

9.1. Техническая документация:
(Требования к составу и формату технической документации.)

9.2. Пользовательская документация:
(Требования к инструкциям для пользователей.)

10. Дополнительные требования

10.1. Требования к безопасности:
(Ограничения доступа, настройка прав пользователей и т.д.)

10.2. Требования к сопровождению:
(Условия технической поддержки после внедрения.)

СОГЛАСОВАНО:

Руководитель структурного подразделения ЗАКАЗЧИКА: ______________________ (ФИО, подпись) "04" марта 2025 г.

Ответственные лица со стороны ИСПОЛНИТЕЛЯ: ______________________ (ФИО, подпись) "04" марта 2025 г.

С ТЗ ознакомлены:

______________________ (ФИО, подпись) "05" марта 2025 г.

______________________ (ФИО, подпись) "06" марта 2025 г.

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

Что включить в спецификацию к ТЗ?

1️⃣ Бизнес-описание

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

ЗАЧЕМ мы делаем это API?,
Какие задачи решает?
Кто будет ей пользоваться?

Это помогает всем участникам проекта "синхронизировать часы".

2️⃣ Эндпоинты

Каждый эндпоинт должен быть логичным и понятным.

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

Например,

📌 GET /users/{id} — Получение информации о пользователе.
📌 POST /orders — Создание нового заказа.

3️⃣ Входные параметры

Чётко опишите какие параметры принимает API.

Обязательно указывайте:

Типы данных,
Обязательность заполнения,
Описание,

Желательно указывать, где эти параметры находятся: в body, path, query или header. Так вашим разработчикам будет проще.

Например,

Параметр: userId

Тип данных: int

Обязательный: Да

Описание: Идентификатор пользователя

И еще, не забывайте добавлять примеры, чтобы это было наглядно 😉

4️⃣ Ответы API или выходные параметры

Тут все тоже самое, что и с входными параметрами.

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

Например:

{

"id": 123,

"name": "John",

"email": "info@mail.ru"

}

5️⃣ Обработка ошибок и альтернтивные сценарии

Что произойдёт, если запрос некорректен?
Какие ошибки будут возникать и как вы их будете возвращать?
Что делать при корнер кейсах, когда ответ вроде 200, но результат отличается от идеального пути?

Вот все это нужно описать и вернуть понятный ответ:

Например при ошибке вернуть так:

{

"error": "InvalidRequest",

"message": "Missing required parameter: userId"

}

6️⃣ Аутентификация

Тут пояснения думаю излишне

Опишите, как будет защищён ваш API: JWT, API-ключи или OAuth 2.0.

Например,

Authorization: Bearer <токен>

7️⃣ Маппинг и вызовы внешних систем

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

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

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

Реалии 1Сников...

К сожалению, обычно всё происходит следующим образом: программист сам пишет себе ТЗ, хотя формально в подписи указаны главный бухгалтер, кадровик или другой пользователь, якобы являющиеся постановщиками задачи. Затем программист разрабатывает программу, что, в общем-то, логично, ведь это его прямая обязанность. После этого он тестирует её, выступая в роли пользователя, находит и исправляет ошибки и недочёты. Далее он внедряет программу, обучает пользователей работе с ней, а иногда даже сам какое-то время работает в ней, потому что пользователь слишком занят своими основными задачами и не может отвлекаться на освоение нового инструмента. В итоге появляется документ о премировании за успешное внедрение ИТ-решения, и кого мы видим в списке награждённых? Фамилию программиста? Как бы не так! Там указаны главный бухгалтер, кадровик и другие пользователи, ведь именно они, согласно документам, создали столь грамотное ТЗ, по которому программист смог доработать "какую-то программу 1С"...

комментарии

____________________

Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник