DF-ПРО-003 · Как проходит работа
Техническое задание на разработку ПО: состав и пример
- Какие границы проекта зафиксировать до описания функций
- Как превратить пожелания в наблюдаемое поведение программы
- Что написать о данных, доступах и рабочей среде
- Как подготовить сценарии проверки и приёмки
Разработчик показал готовую программу, но привычный рабочий сценарий в ней не помещается. Кто ошибся: исполнитель или заказчик? Если сценарий не описан в ТЗ, а результат нельзя проверить по согласованным условиям, однозначного ответа не будет.
Рабочее техническое задание связывает задачу бизнеса, поведение программы и приёмку. Из него понятно, кто пользуется системой, что может сделать, какие данные получает программа и какой результат должны увидеть стороны.
Это не обязательно большой документ. Для небольшой разработки важнее закрыть существенные решения, чем набрать десятки страниц. Если задача охватывает несколько систем и целый бизнес-процесс, пригодится отдельная инструкция про ТЗ на автоматизацию. Здесь разберём программный продукт на примере личного кабинета клиента.
С чего начать техническое задание?
Сначала обозначьте границу продукта. Допустим, нужен кабинет, где клиент видит свои заказы и скачивает документы. Отделите его от CRM, бухгалтерской системы, сайта и почты: кабинет может получать от них сведения, но не обязан заменять каждую соседнюю систему.
Затем перечислите пользователей и разрешённые действия. Клиент просматривает только свои заказы, менеджер видит закреплённых клиентов, администратор управляет учётными записями. Если права не записаны, разработчику придётся самому решать, кому доступны данные.
Зафиксируйте состав первой версии и исключения. Например, входят авторизация, список заказов, карточка заказа и скачивание документов. Не входят редактирование заказа, обмен сообщениями и отдельное мобильное приложение. Эти границы пригодятся и при оценке работ, и при разборе новых пожеланий.
Действующий ГОСТ 19.201-78 устанавливает порядок построения и оформления ТЗ на программу или программное изделие. Однако статус действующего стандарта сам по себе не делает его обязательным для любого частного проекта. Статья 26 Федерального закона № 162-ФЗ предусматривает добровольное применение документов национальной системы стандартизации, кроме установленных законом случаев.
Для изготовителя или исполнителя национальный стандарт становится обязательным при публичном заявлении о соответствии продукции этому стандарту. Поэтому основание применения ГОСТа стоит определить до согласования документа.
Как записывать требования к функциям?
Требование описывает наблюдаемое поведение, а не впечатление от программы. Слова удобный и быстрый бесполезны без условий. Запишите пользователя, исходное состояние, действие, ожидаемый результат и существенные ограничения.
ISO/IEC/IEEE 29148:2018 определяет спецификацию требований к ПО как структурированный набор существенных требований к функциям, производительности, проектным ограничениям, свойствам и внешним интерфейсам. Для функции личного кабинета запись может выглядеть так:
- Роль: зарегистрированный клиент.
- Исходное состояние: с учётной записью связан заказ.
- Действие: клиент открывает список и выбирает заказ.
- Результат: программа показывает номер, статус, дату обновления и доступные документы.
- Ограничение: чужой заказ нельзя увидеть в списке или открыть по прямому адресу.
Макет экрана можно приложить отдельно. Он покажет расположение элементов, но не заменит правила доступа, источник данных и реакцию программы на ошибку. Эти условия остаются текстовыми требованиями.
Что написать о данных и рабочей среде?
Для каждого набора данных укажите источник, обязательные поля, формат и владельца. В нашем примере сведения о заказе приходят из CRM, а документы — из файлового хранилища. Отдельно решите, копирует ли кабинет файл или получает ограниченную по времени ссылку.
Опишите сбои и неполные данные. Что увидит клиент, если внешняя система недоступна, заказ не найден или у записи нет документа? Без такого решения одна версия покажет пустой экран, другая — устаревшие сведения, третья завершит запрос общей ошибкой.
В разделе о среде перечислите место размещения, поддерживаемые браузеры, способ входа, внешние интерфейсы и ограничения инфраструктуры. Если стенд предоставляет заказчик, укажите, что и к какому моменту он должен подготовить.
Пароли и ключи в ТЗ не помещают. Достаточно записать назначение доступа: тестовая учётная запись CRM с правом чтения заказов, отдельная база для испытаний, административный доступ к тестовому стенду. Выдачу, хранение и отзыв доступов согласуют отдельно. Связать это с этапами проекта поможет описание порядка работы.
Как подготовить проверку и приёмку?
Соберите испытания из требований, которые влияют на результат. Интерфейс проверяют по пользовательскому сценарию, обмен данными — на подготовленных записях, права — через учётные записи разных ролей. Для ошибок заранее задают исходное состояние и ожидаемую реакцию.
В ISO/IEC/IEEE 29148:2018 разделены проверка и подтверждение правильности самих требований. Requirements verification отвечает на вопрос, хорошо ли они сформированы и организованы. Requirements validation — описывают ли они именно ту систему, которая нужна заинтересованным сторонам. Отдельные термины verification и validation относятся уже к подтверждению характеристик результата и его пригодности для предполагаемого использования.
Для кабинета подготовьте три заказа: доступный текущему клиенту, принадлежащий другому клиенту и запись без документа. Первый должен открываться, второй — оставаться недоступным, для третьего должно появляться предусмотренное состояние без ссылки на файл. Результат каждого шага фиксируют снимком экрана, журналом испытаний или иной согласованной записью.
Если нужен самостоятельный документ с программой испытаний, действующий ГОСТ 19.301-79 задаёт требования к его содержанию и оформлению. В небольшой работе сценарии можно поместить в приложение к ТЗ: идентификатор требования, исходные условия, действия, ожидаемый результат и подтверждающий материал.
Как проверить ТЗ перед согласованием?
Пройдите документ от лица каждой роли. Понятно ли, с чего начинается работа пользователя, какие действия ему доступны, откуда появляются данные и чем заканчивается сценарий? Затем проверьте ошибки: неверный ввод, отсутствие данных, недоступность внешней системы и недостаточные права.
Найдите оценочные слова. Удобный замените конкретным действием, быстро — измеримым пределом, если он действительно нужен, безопасно — правилами доступа и обработки данных. Не назначайте число ради видимой точности: сначала определите, зачем нужно ограничение и как его измерять.
Перед подписанием сверьте цель продукта с составом первой версии, роли — с правами, данные — с источниками и форматами, а сценарии испытаний — с ожидаемыми результатами. Исключения, материалы сторон и порядок согласования изменений тоже должны быть записаны явно.
ТЗ не обязано заранее выбирать за разработчика каждую технологию. Его задача — убрать разные трактовки результата: что входит в работу, как должна вести себя программа и по каким наблюдаемым признакам заказчик её примет.
Источники
Deskforge на связи
Где нас найти
Нажмите на карточку или наведите камеру на QR-код.