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