Разработка программного обеспечения
Как подготовить техническое задание на разработку ПО
Чтобы подготовить техническое задание, опишите цель проекта, пользователей, их действия, данные и условия, по которым будете принимать результат. Начните с того, что должно измениться в работе компании. Затем превратите это описание в проверяемые требования и отдельно запишите вопросы, на которые пока нет ответа.
Как связать бизнес-цель с требованиями
Сначала назовите затруднение в текущей работе и результат, который нужен после изменения. Формулировка «сделать личный кабинет» описывает возможную форму программы, но ещё не объясняет, какие действия он должен обеспечивать. Цель помогает выбирать требования и отсекать функции, не связанные с первой версией.
В условном примере компания принимает сервисные заявки по переписке. Цель проекта — дать сотруднику возможность зарегистрировать обращение и увидеть его состояние, а диспетчеру — назначить исполнителя и контролировать незавершённые заявки. Из этой цели следуют требования к регистрации, назначению и статусам.
Связка для проверки каждого требования
Кому нужно действие → какую задачу оно решает → какой результат должен появиться → как этот результат проверить. Если связь с целью неясна, уточните необходимость функции или отложите её за границы первой версии.
Зафиксируйте также, что не входит в проект. Например, в первой версии сервис регистрирует обращения, но не рассчитывает стоимость ремонта и не ведёт складской учёт. Это позволяет обсуждать один и тот же объём работ.
Пользователи и сценарии
Перечислите роли и права каждой из них. Название подразделения недостаточно: два сотрудника одного отдела могут иметь разные полномочия. Укажите, какие записи человек видит, что может создать или изменить и кто назначает ему доступ.
Для основного сценария опишите начальное состояние, действие пользователя и ожидаемый результат. Затем добавьте исключения: обязательное поле не заполнено, право отсутствует, запись уже изменилась, пользователь повторил отправку. Именно в исключениях часто обнаруживаются недостающие правила.
Условный сценарий: регистрация заявки
- Сотрудник с действующим доступом открывает форму и указывает объект обслуживания и описание затруднения.
- Система проверяет обязательные поля и сохраняет заявку с номером и исходным статусом.
- Автор видит подтверждение и заявку в своей истории; диспетчер видит её в очереди неназначенных обращений.
- При неполных данных система указывает пропущенные поля и сохраняет введённый текст в форме для исправления.
Отдельный вопрос для обследования: может ли сотрудник видеть обращения коллег или только свои? Ответ меняет права доступа, интерфейс и набор проверок.
Данные, интеграции и ограничения
Для каждой сущности укажите источник, обязательные поля, идентификатор и правила изменения. Для заявки это могут быть номер, автор, объект, описание, статус и назначенный исполнитель. Для справочника объектов нужно понять, кто его поддерживает и можно ли выбирать неактивную запись.
Если программа получает данные из другой системы, опишите направление обмена, нужные поля, допустимую задержку и действие при ошибке. Например, в условном сервисе объектов нет в локальном справочнике: до оценки нужно выяснить, есть ли доступный способ получить их из учётной программы.
- Среда: где будет работать программа, какие устройства и браузеры нужны, какие компоненты уже заданы.
- Нагрузка: сколько пользователей и операций ожидается в обычном и пиковом режиме.
- Доступ и сохранность: какие данные ограничены по ролям, какая история изменений нужна и как обсуждается восстановление.
- Перенос: какие существующие записи нужно загрузить, в каком виде они доступны и кто проверит качество.
Заменяйте слова «быстро» и «надёжно» условиями проверки. Если допустимое время отклика или восстановления пока неизвестно, отметьте вопрос, ответственного и момент согласования. Не подставляйте произвольные показатели.
Функциональные требования и критерии приемки
Функциональное требование описывает наблюдаемое поведение системы. Его удобно записывать отдельно от предположения о реализации: «диспетчер назначает исполнителя» не обязывает заранее выбирать конкретную библиотеку или структуру базы данных. Техническое ограничение включают, когда оно действительно задано проектом.
Критерий приёмки связывает требование с проверкой: исходные условия, действие и ожидаемый результат. По нему заказчик и разработчик должны одинаково понять, выполнено ли требование.
| Требование | Условия и проверка |
|---|---|
| Диспетчер назначает исполнителя | Для неназначенной заявки диспетчер выбирает действующего исполнителя. После сохранения назначение видно в карточке и очереди исполнителя; изменение отражается в истории. |
| Автор видит свои заявки | Под учётной записью автора открывается его история. Обращение к чужой заявке по прямой ссылке не раскрывает её содержимое. |
| Повторная отправка не создаёт дубль | Повтор одной и той же операции регистрации возвращает результат первоначальной заявки. Отдельная новая заявка с похожим текстом допускается по согласованным правилам. |
Договоритесь, какие данные и роли будут подготовлены для проверки и кто подтвердит результат. Одного показа экрана недостаточно для требования, затрагивающего права, сохранение данных или обмен.
Пример структуры ТЗ для программного проекта
Ниже — структура, которую можно перенести в рабочий документ и заполнить сведениями своего проекта. В колонке примера показан условный сервис заявок. Эти записи помогают начать обсуждение, но не заменяют согласование правил вашей компании.
| Раздел | Что заполнить | Условный пример |
|---|---|---|
| Цель и границы | Какую работу меняем, какой результат нужен, что исключено из первой версии. | Регистрация и назначение заявок; расчёт стоимости ремонта пока исключён. |
| Участники | Роли, права и ответственные за согласование требований. | Автор, диспетчер, исполнитель; правила очереди подтверждает руководитель службы. |
| Сценарии | Начальное состояние, действия, результат и исключения. | Создание, назначение и закрытие заявки; возврат на уточнение описания. |
| Данные и обмен | Сущности, поля, источники, идентификаторы и правила обновления. | Справочник объектов приходит из учётной системы; возможность подключения требует проверки. |
| Ограничения | Среда, нагрузка, доступность и сохранность данных. | Проверить работу на устройствах сотрудников; согласовать ожидаемую нагрузку. |
| Приёмка | Проверки, тестовые данные, участники и состав передаваемого результата. | Проверить путь заявки под каждой ролью, ограничения доступа и повтор операции. |
| Открытые вопросы | Что неизвестно, кто выясняет, какие решения зависят от ответа. | Уточнить доступ к справочнику до включения обмена в план. |
| Версия и изменения | Дата, согласованная версия, история решений и порядок изменения требований. | Новое правило назначения проверяется на влияние на сценарии и приёмку. |
Не пропускайте отрицательные сценарии, перенос данных и подготовку к запуску. Если раздел неприменим, запишите почему. Если данных нет, сохраните открытый вопрос: пустая строка скрывает неопределённость от участников.
Как уточнять требования и управлять изменениями
Требования уточняются по мере знакомства с процессом. Важно сохранять согласованную версию и отделять новые предложения от уже принятых правил. Для каждого вопроса укажите владельца решения и часть проекта, которая от него зависит.
Изменение удобно описывать через причину, новое поведение, затронутые сценарии и проверки. Например, в условном сервисе появляется заместитель диспетчера. Нужно уточнить его доступ, правила назначения и историю действий, а затем проверить влияние на уже согласованные требования.
- Зафиксируйте запрос и ожидаемый результат изменения.
- Разберите влияние на данные, права, интеграции и критерии приёмки.
- Согласуйте, входит ли изменение в текущую версию или следующий этап.
- Обновите требования и план проверок; сохраните принятое решение в истории.
Перед передачей ТЗ проверьте связность: у каждого обязательного сценария есть требование и проверка, у внешней зависимости — источник сведений, у нерешённого вопроса — ответственный. Такой документ можно использовать для предметного обсуждения проекта.
Частые вопросы
Обсудим требования вашего проекта
Подготовьте описание задачи, один основной сценарий и вопросы, которые пока мешают определить результат. На этой основе можно обсудить границы первой версии и сведения, необходимые для дальнейшей проработки.
Обсудить проект