Технический проект по ГОСТ 34: что входит и как проверить состав

Технический проект по ГОСТ 34 нужен, чтобы зафиксировать выбранное решение до поставки: архитектуру, функции, данные, интеграции, технические требования и ограничения. Это не просто пояснительная записка, а рабочая рамка, по которой можно проверять состав будущей системы.

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

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

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

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

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

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

• писать технический проект после разработки как отчет, а не до реализации как рамку решения;
• смешивать желаемые функции и подтвержденный объем этапа;
• не описывать внешние системы и владельцев интеграций;
• не указывать нефункциональные требования;
• оставлять схемы без текстового объяснения и критерия проверки.

Готовый технический проект должен давать основу для оценки, разработки, приемки и сопровождения. Он не обязан закрывать все будущие этапы, но должен ясно описывать текущий контур решения и последствия выбранных архитектурных решений.