MiDays: База знаний

Как написать тех. задание на доработку

2024-01-26 07:58 Разное
ТЗ на доработку или добавление нового функционала
ТЗ на доработку или добавление нового отчёта
Неправильно составленное ТЗ
Обратите внимание! Иногда, несмотря на четко сформулированные требования и желание пользователя, технические специалисты могут отказаться от выполнения определенных доработок. Это может быть связано как с ограничениями текущей архитектуры проекта, так и с другими факторами, которые делают разработку нецелесообразной или слишком сложной. Разработку функционала разработчик оставляет на своё усмотрение. Так, например основанием для отказа в разработке могут быть:
  • Архитектурные ограничения — текущая архитектура проекта не позволяет внести изменения без значительной переработки системы.
  • Несовместимость с внешними системами — интеграция невозможна из-за различий в форматах данных или протоколах обмена.
  • Технические ограничения — проблемы с производительностью или нехваткой ресурсов для реализации доработок.
  • Конфликт с существующим функционалом — новая функция может нарушить работу других модулей системы.
  • Избыточность или нецелесообразность — доработка слишком затратна по времени или дублирует уже существующий функционал.
Техническое задание (ТЗ) — это основополагающий документ, который описывает требования к доработке или добавлению нового функционала программного обеспечения. Его цель — максимально четко и подробно объяснить разработчикам, что требуется изменить или добавить. Хорошо составленное ТЗ помогает избежать недопонимания, сокращает время на доработки и уменьшает риск появления ошибок в ходе реализации проекта.

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

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

ТЗ на доработку или добавление нового функционала

Основные элементы ТЗ для доработки приложения

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

2. Цели и задачи доработки
Пользователь должен четко сформулировать, что именно он хочет изменить или добавить:
  • Почему нужна новая функция? Например, чтобы упростить действия, улучшить производительность, добавить новые возможности и т.д.;
  • Что именно должно быть изменено или добавлено? Этот пункт нужно детализировать, чтобы разработчик понимал конечную цель.

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

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

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

4. Интеграция с существующими модулями
Пользователю стоит описать, как новый функционал будет взаимодействовать с уже существующими модулями программы:
  • Должна ли новая функция получать данные из других частей программы;
  • Изменяется ли существующий функционал для поддержки новой функции;
  • Есть ли зависимости между различными модулями программы, которые могут быть затронуты при реализации нового функционала.

5. Если требуется обмен с внешними ресурсами
Определитесь, с каким внешним ресурсом система будет взаимодействовать:
  • Тип ресурса: это API или файловый обмен?
  • Как будет происходить обмен данными?
Предоставьте документацию
Если обмен по API, необходима документация разработчика API с описанием методов взаимодействия.
Если это файловый обмен, необходимы примеры файлов, которые вы ожидаете получить от программы.

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

Полезные советы для пользователей при составлении ТЗ
  1. Формулируйте запросы конкретно и подробно. Чем больше деталей вы укажете, тем точнее разработчик сможет понять ваши ожидания и требования.
  2. Не ограничивайтесь общими фразами. Вместо «хочу добавить новую кнопку» лучше описать, где именно она должна быть, как она должна называться и что должна выполнять.
  3. Опишите сценарии использования. Это поможет разработчику представить, как новая функция будет использоваться на практике.
  4. Избегайте неопределенности. Если вы не уверены в каком-то аспекте, лучше обсудить его с разработчиком заранее, чтобы избежать неоднозначных решений.
  5. Обратная связь и уточнение деталей. После получения ТЗ разработчик может задать уточняющие вопросы, будьте готовы дать ответ.
Пример простого ТЗ для доработки

Цель: Упрощение процесса отправки отчетов.
Описание текущей ситуации: В данный момент отчеты можно просматривать на экране, но нет возможности их печатать.
Задачи доработки:
  1. Добавить кнопку «Печать» на экран отчетов.
  2. После нажатия кнопки открывать окно с предварительным просмотром и возможностью выбора параметров (формат страницы, поля).
  3. После выбора параметров — отправка документа на печать.

Сценарий тестирования:
  1. Проверить, что при нажатии на кнопку открывается окно предварительного просмотра.
  2. Проверить работу всех параметров настройки печати.
  3. Убедиться, что отчет корректно отправляется на принтер и распечатывается.
Такое структурированное ТЗ позволит пользователю четко сформулировать свои требования, а разработчику — быстро понять задачу и правильно её реализовать.

ТЗ на доработку или добавление нового отчёта

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

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

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

2. Описание структуры отчета
Отчет представляет собой таблицу с определенными данными. Пользователь должен четко описать:
  • Какие данные нужно отобразить. Перечислите поля или столбцы, которые должны присутствовать в отчете (например, название товара, количество проданных единиц, дата, сумма продажи и т.д.).
  • Формат данных. Укажите формат отображения данных (например, даты в формате ДД.ММ.ГГГГ, числа с двумя знаками после запятой и т.д.).

Пример:
  • Столбцы отчета:
  1. Дата продажи (формат ДД.ММ.ГГГГ)
  2. Название товара
  3. Категория товара
  4. Количество проданных единиц (целое число)
  5. Сумма продажи (с двумя знаками после запятой)

3. Фильтры и условия выборки
Четко укажите, какие фильтры или условия нужно применить для формирования отчета:
  • По каким критериям нужно отбирать данные? Например, продажи только за последний месяц или только по определённым категориям товаров.
  • Какие временные рамки нужно учитывать? Например, отбор данных за конкретный период (месяц, квартал, год).

Пример:
  • «Отчет должен отображать продажи только за последний месяц».
  • «Необходимо добавить возможность фильтрации по группе товаров и объекту продажи».

4. Группировка и сортировка данных
Опишите, как нужно сгруппировать и отсортировать данные в отчете:
  • Нужно ли группировать данные по определенным полям (например, по дате, категории товаров или региону).
  • По какому полю или полям данные должны быть отсортированы (например, по дате или по убыванию суммы продаж).

Пример:
  • «Данные должны быть сгруппированы по группам товаров и отсортированы по дате продажи (по возрастанию)».

5. Агрегация данных

Если требуется вычислить какие-либо агрегированные значения (например, сумму, среднее значение, количество), это нужно четко указать:
  • Какие агрегированные данные нужны? (сумма продаж, средняя цена, общее количество проданных товаров и т.д.)
  • По каким параметрам выполнять агрегацию?

Пример:
  • «Необходимо рассчитать общее количество проданных единиц товаров за каждый день и общую сумму продаж за период».

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

Пример:
  • «Суммы продаж более 100 000 рублей должны выделяться зеленым цветом».
  • «Негативные значения (убытки) должны выделяться красным цветом».

7. Тестирование и приемка

Важный этап — это проверка правильности работы отчета после разработки:
  • Какие тестовые данные использовать для проверки?
Каковы критерии приемки отчета (например, корректность отображения данных, правильное применение фильтров и т.д.)?
Пример:
  • «Отчет должен корректно отображать данные за последний месяц, применяя все фильтры и группировки, а также без ошибок выгружаться в Excel».
Пример ТЗ на разработку нового отчета

Цель: Создать отчет для отображения продаж по категориям товаров за месяц с возможностью фильтрации по регионам и категориям.
Структура отчета:
  • Столбцы: Дата продажи, Название товара, Категория товара, Количество проданных единиц, Сумма продажи.
  • Формат: даты в формате ДД.ММ.ГГГГ, сумма продажи с двумя знаками после запятой.
Фильтры:
  • Данные только за последний месяц.
  • Фильтр по категории товаров и региону продажи.
Группировка и сортировка:
  • Группировка по категориям товаров.
  • Сортировка по дате продажи по возрастанию.
Агрегация данных:
  • Рассчитать общее количество проданных товаров и сумму продаж по каждому дню.
Форматирование:
  • Суммы продаж более 100 000 рублей должны выделяться зеленым цветом.
  • Убытки (если есть) выделяются красным цветом.
Важный момент при составлении ТЗ на разработку нового отчёта.
Создайте пустую базу MiDays UNO.
Заполните её несколькими тестовыми данными (которые понадобятся в желаемом отчёте)
Заполните таблицу в Excel так, как вы хотите видеть это в отчёте. Данные в Excel должны совпадать с данными в тестовой базе данных.

Неправильно составленное ТЗ

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

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

Другой распространённый пример – запрос «Добавьте в этот документ определённые данные». Такой запрос подразумевает, что от специалиста потребуется аргументация или предложение определённой формулы. Однако нередко после такого запроса следует молчание со стороны клиента, так как он сам не может точно объяснить, какие именно данные нужны или по какому принципу их следует интегрировать. Это приводит к тому, что специалистам приходится работать в условиях неопределённости.

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

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