Дополнительные виды проектной документации
ERD — Entity Relationship; SQL — SQL для аналитики, SQL; миграции — Пакетная работа. Полная таблица — о разделе.
Для контрактов и госсектора — ТЗ, ПМИ, ГОСТ. В чистом Agile — выборочно (изменения ТЗ, приёмка). Основной agile-поток — Документация в процессах. ТЗ ≠ описание реализации — см. Технический дизайн на основе требований.
Технические задания
Что такое техническое задание?
Техническое задание (ТЗ, техзадание) — это основной управленческо-технический документ, фиксирующий совокупность требований заказчика к создаваемому продукту или системе. Его ключевая функция — обеспечить однозначное понимание предмета разработки, а также служить юридическим основанием для оценки соответствия итогового результата ожиданиям заказчика. Поскольку ТЗ связывает бизнес-цели, технические возможности и юридические обязательства, оно должно быть составлено с высокой степенью точности, полноты и структурированности.
Важнейшие свойства технического задания:
- Обязательность для исполнителя — ТЗ определяет рамки работ, выход за которые требует согласования изменений;
- Юридическая сила — ТЗ, подписанное обеими сторонами (заказчиком и исполнителем), становится неотъемлемой частью договора;
- Стабильность и управляемость изменений — любая модификация ТЗ оформляется в виде акта о внесении изменений, который также подписывается сторонами и прилагается к основному документу;
- Полнота охвата — ТЗ описывает функциональные требования, ограничения, этапы, сроки, критерии приёмки и сопутствующую документацию.
Нормативная основа — ГОСТ 19.201–78
В отечественной инженерной практике разработка ТЗ на программные средства регулируется ГОСТ 19.201–78 "Техническое задание на разработку программного изделия. Требования к содержанию и оформлению". Данный стандарт устанавливает обязательную структуру ТЗ и перечень разделов, которые должны быть в нём отражены.
Согласно ГОСТ 19.201–78, техническое задание на программу должно содержать следующие разделы:
- Введение — краткое обоснование необходимости разработки, ссылки на нормативные документы и стандарты.
- Основания для разработки — указание на договор, приказ, распоряжение или иной документ, инициирующий создание ПО.
- Назначение разработки — описание целей, области применения, класса решаемых задач, ограничений по использованию.
- Требования к программе или программному изделию — наиболее объёмный и технически насыщенный раздел. Включает:
- функциональные требования;
- требования к надёжности, производительности, безопасности;
- требования к внешним интерфейсам (пользовательский, аппаратный, программный);
- требования к условиям эксплуатации.
- Требования к программной документации — перечень и состав документов, которые должны быть переданы вместе с программой (руководства, спецификации, ведомости и т.п.).
- Технико-экономические показатели — оценка стоимости, трудоёмкости, сроков окупаемости, экономического эффекта (если применимо).
- Стадии и этапы разработки — поэтапный план выполнения работ с привязкой к срокам и промежуточным результатам.
- Порядок контроля и приёмки — методы и процедуры проверки соответствия (тестирование, демонстрация, аудит), состав приёмочной комиссии, критерии приёмки.
- Приложения — могут включать схемы, прототипы интерфейсов, глоссарии, перечни терминов, дополнительные требования.
ГОСТ подчёркивает, что ТЗ должно быть достаточно детализированным для однозначной интерпретации, но не должно содержать решений по реализации — это прерогатива проектной документации.
Техническое задание на автоматизированную систему (АСУ)
Для сложных комплексов, таких как автоматизированные системы управления (АСУ), АСУ ТП (технологическими процессами) или корпоративные информационные системы, применяется иная нормативная база — ГОСТ 34.602–89 "Техническое задание на создание автоматизированной системы". Этот стандарт учитывает системный характер таких решений: их многокомпонентность, интеграцию с физическими объектами и распределённость функций.
Основные особенности ТЗ на АСУ:
- Оно может разрабатываться как на всю систему, так и на её составные части (подсистемы, программные модули, технические средства);
- Состав разделов значительно шире, чем в ГОСТ 19.201, поскольку охватывает ПО, организационные, технологические и инфраструктурные аспекты.
Согласно ГОСТ 34.602, ТЗ на АСУ включает следующие разделы:
- Общие сведения — наименование, заказчик, исполнитель, дата, ссылки на договор.
- Цели и назначение создания АС — обоснование проекта, ожидаемые результаты, ключевые показатели эффективности.
- Характеристика объектов автоматизации — описание бизнес-процессов, технологических линий, организационной структуры, подлежащих автоматизации.
- Требования к автоматизированной системе — функциональные, надёжностные, эксплуатационные, безопасностные и эргономические требования ко всей системе и её компонентам.
- Состав и содержание работ по созданию АС — перечень проектных, программных, пуско-наладочных, обучающих и других работ.
- Порядок разработки АС — этапы, сроки, взаимодействие сторон.
- Порядок контроля и приёмки АС — процедуры испытаний, критерии, состав комиссии.
- Требования к подготовке объекта автоматизации — действия заказчика по созданию условий для внедрения (обучение персонала, модернизация инфраструктуры и т.д.).
- Требования к документированию — полный перечень сопроводительной документации в соответствии с ЕСПД и ЕСКД.
- Источники разработки — нормативные документы, стандарты, технические условия, материалы обследования.
ТЗ на АСУ часто становится основой для разработки технико-рабочей документации и проектных решений, а также служит базой для формирования спецификаций на оборудование и программное обеспечение.
Техническое задание на сайт
В отличие от программных изделий или АСУ, для веб-проектов (сайтов, порталов, интернет-магазинов) не существует обязательных государственных стандартов, регламентирующих структуру ТЗ. Однако в профессиональной практике разработчики и заказчики адаптируют требования ГОСТ 19.201 и ГОСТ 34.602 в зависимости от сложности проекта:
- Сайт-визитка — чаще всего оформляется по аналогии с ТЗ на программу (ГОСТ 19.201) — описание структуры, контента, функционала (формы обратной связи, карта, админка), требований к дизайну, хостингу, SEO-параметрам.
- Корпоративный портал или интернет-магазин — требует подхода, схожего с АСУ — описание бизнес-процессов (регистрация, каталог, корзина, оплата, доставка), интеграции (CRM, 1С, платёжные шлюзы), требований к безопасности (PCI DSS, GDPR), масштабируемости, аналитике.
Хотя ГОСТы не являются юридически обязательными для веб-проектов, их использование повышает качество ТЗ, минимизирует риски недопонимания и служит доказательной базой в случае споров. Хорошее ТЗ на сайт включает:
- структуру навигации (дерево разделов);
- макеты ключевых страниц (wireframes или дизайн-макеты);
- описание пользовательских ролей и сценариев;
- требования к адаптивности, скорости загрузки, кросс-браузерности;
- состав передаваемых материалов (исходники, документация, инструкции);
- критерии приёмки (например, соответствие макету, отсутствие ошибок в консоли, прохождение тестов на мобильных устройствах).
Управление изменениями в техническом задании
Изменения в ТЗ неизбежны в условиях эволюции бизнес-требований или выявления новых ограничений. Однако произвольная модификация недопустима. Согласно договорной практике и требованиям стандартов:
- Любое изменение оформляется в виде дополнения или акта о внесении изменений в ТЗ;
- Акт подписывается уполномоченными представителями обеих сторон;
- Изменения вступают в силу только после оформления акта;
- Акт становится неотъемлемой частью договора и основного ТЗ.
Этот механизм обеспечивает прозрачность, предсказуемость и юридическую защищённость сторон.
ГОСТы
Во многих странах, в том числе Российской Федерации, имеются государственные стандарты, которые упорядочивают хаос в документах. Особенно важны для аналитика ГОСТы серий 19 и 34.
ГОСТ — это Государственный стандарт. Он устанавливает правила, требования и рекомендации по оформлению, содержанию и структуре документов, процессов и продуктов. В IT ГОСТы помогают установить единообразие, закрепить юридическую силу, и поддерживают контроль качества.
Официальные тексты стандартов публикуются в открытых фондах нормативных документов; в проекте опирайтесь на утверждённую редакцию из договора и на материалы энциклопедии по каждому виду документа. Сводная карта "программа vs АС, стадии, комплект ТП" — в навигаторе по нормативной документации.
Давайте разберём самые важные:
- ГОСТы серии 19 — Единая система программной документации (ЕСПД). Это основа. Здесь — как писать ТЗ, спецификации, инструкции.
- ГОСТы серии 34 — Стандарты информационной технологии, включая создание автоматизированных систем (АСУ). Это про жизненный цикл, стадии, документы на АС.
- ГОСТы серии 2 — Единая система конструкторской документации (ЕСКД). Хотя это "для инженеров", в IT они иногда применяются, особенно в смежных системах (например, ПО для станков).
- ГОСТы серии 15 — Система разработки и постановки продукции на производство. Важно для понимания процессов в государственных и промышленных проектах.
Почему нужно соблюдать требования ГОСТ? Есть несколько ньюансов. Вам можно составлять свои документы, если вы считаете, что ГОСТ недостаточно раскрывает суть. Но не юридически значимые. К примеру, можно разрабатывать статейки на Confluence или Wiki, готовить свои инструкции вольных форматов, но они будут считаться неофициальной документацией с целью помочь пользователю или сотруднику иной роли разобраться в системе или задаче. Но когда речь идёт об официальных документах, здесь уже играет роль юридическая сила документа.
Юридическая сила - это свойство документа или правового акта устанавливать правовые последствия, быть обязательным к исполнению или порождать правовые отношения. То есть, с инструкцией пользователя, написаной без соответствия ГОСТ и не утверждённой, не пойдешь в суд.
Точнее, в суде то примут, но юридической силы она иметь не будет. Поэтому государство и занимает стандартизацией документации.
ГОСТ 19: Единая система программной документации (ЕСПД) регулирует всё, что связано с программным обеспечением: от ТЗ до инструкций пользователю.
ГОСТ 19.001-77 — Общие положения, что такое программная документация, кто её создаёт, какие виды документов существуют. Это своего рода введение в курс дела.
ГОСТ 19.101-77 — Виды программ и программных документов, содержит классификацию - программы, документы, исполнительные модули и прочее.
ГОСТ 19.102-77 — Стадии разработки ПО, жизненный цикл ПО - разработка, испытания, внедрение и т.д.
ГОСТ 19.201-78 — Техническое задание (ТЗ), как оформлять ТЗ - структура, обязательные разделы (цель, требования, условия, сроки и т.д.).
ГОСТ 19.202-78 — Спецификация - детализация требований, о том, как именно ПО будет реализовано - модули, интерфейсы, данные.
ГОСТ 19.301-79 — Программа и методика испытаний. Как тестировать ПО, какие тесты, в каком порядке, какие критерии приёмки.
ГОСТ 19.404-79 — Пояснительная записка. Это обоснование решений, описание системы, архитектура, логика. Часто используется как обзор проекта для заказчика.
ГОСТ 19.501–508 — Руководства (для пользователей, операторов, программистов), о том, как пользоваться системой, как её обслуживать.
ГОСТ 19.601-78 — Учёт и хранение документов, как нумеровать, хранить, вносить изменения. Важно для управления версиями. Особенно в больших проектах, где документы меняются часто.
ГОСТ 34: Стандарты информационной технологии и АСУ. Это уже более масштабные системы — автоматизированные системы управления (АСУ), государственные проекты, корпоративные ERP и т.д. Здесь акцент на жизненный цикл, стадии, технико-экономическое обоснование.
ГОСТ 34.201-89 — Виды и комплектность документов при создании АС. Какие документы нужны на каждой стадии создания АС: от обоснования до ввода в эксплуатацию.
ГОСТ 34.601-90 — Стадии создания автоматизированной системы. Чётко делит на стадии:
- Обоснование создания АС
- Техническое задание
- Эскизный проект
- Технический проект
- Рабочая документация
- Ввод в эксплуатацию
Это основа управления проектом. На каждой стадии — свои документы, свои решения, свои подписи. Аналитик часто участвует в 1–4 стадиях.
ГОСТ 34.602-89 — Техническое задание на создание АС. Как писать ТЗ для целой системы, а не просто ПО. Учитывает организационные, технические, экономические аспекты.
ГОСТ 34.603-92 — Виды испытаний автоматизированных систем. Приёмо-сдаточные, комплексные, квалификационные испытания.
Также нужно выделить ещё два документа.
ГОСТ Р ИСО/МЭК 15271-02 — Процессы жизненного цикла ПО, взгляд на жизненный цикл — разработка, эксплуатация, сопровождение.
РД 50-34.698-90 — Требования к содержанию документов, руководящий документ, очень важный. Детализирует, что именно должно быть в каждом документе по ГОСТ 34.
Если не знать эти документы, то не получится работать в государственном секторе, оборонной, энергетической, жилищно-коммунальной сфере - там ГОСТы обязательны. Плюс, крупные проекты на серьёзные суммы требуют формальную отчётность, с этим очень строго, поэтому к документации нужно подходить с особым уважением.
ПМИ, ППМИ
Программа и методика испытаний (ПМИ) — это технический документ, определяющий перечень требований, подлежащих проверке, а также порядок, условия, методы и критерии оценки при проведении испытаний программного средства. ПМИ служит планом тестирования, формализованным регламентом контроля, имеющим юридическую и техническую значимость, особенно в контексте государственных контрактов, промышленных систем и регулируемых сфер (медицина, оборона, энергетика, транспорт).
В отличие от внутренних тест-планов или сценариев тестирования, используемых в гибких методологиях, ПМИ является внешним, утверждённым документом, который часто разрабатывается на основании технического задания и становится неотъемлемой частью комплекта поставки программного изделия. Он адресован разработчику, заказчику, приёмочной комиссии, аудиторам и сертификационным органам.
Нормативная основа
Разработка ПМИ регулируется рядом отечественных стандартов, в первую очередь:
- ГОСТ 19.301–79 "Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению" — устанавливает обязательную структуру и содержание ПМИ для программных средств;
- ГОСТ 34.603–89 — применяется при создании автоматизированных систем и дополняет ПМИ требованиями к испытаниям на системном уровне.
Эти стандарты предписывают, что ПМИ должна быть разработана на основе технического задания и предшествовать проведению испытаний, а её выполнение — фиксироваться в протоколах (актах) испытаний.
Назначение ПМИ
Основные функции документа:
- Формализация требований к проверке — конкретизация того, что именно подлежит верификации;
- Стандартизация процедур испытаний — обеспечение воспроизводимости и объективности результатов;
- Определение ответственности сторон — чёткое разграничение ролей заказчика, исполнителя и независимой комиссии;
- Юридическое обоснование приёмки — ПМИ служит основой для составления актов приёмки и разрешения споров;
- Обеспечение прослеживаемости — каждое требование из ТЗ должно быть отражено в ПМИ, а каждый пункт ПМИ — подтверждён протоколом.
Структура программы и методики испытаний
Согласно ГОСТ 19.301–79, ПМИ состоит из двух частей:
1. Программа испытаний
Программа определяет организационные и общие технические аспекты проведения испытаний:
- Наименование и назначение программного изделия — краткое описание объекта испытаний;
- Основания для проведения испытаний — ссылка на договор, ТЗ, приказ или иной инициирующий документ;
- Цель испытаний — проверка соответствия изделия требованиям ТЗ;
- Состав испытаний — перечень видов испытаний (например, функциональные, нагрузочные, стресс-тесты, проверка безопасности);
- Порядок проведения — этапы, последовательность, условия (аппаратные, программные, сетевые);
- Состав участников — перечень организаций и лиц, участвующих в испытаниях (разработчик, заказчик, независимый эксперт);
- Сроки и место проведения;
- Требования к аппаратуре, программным средствам и данным — описание тестового стенда;
- Перечень представляемых документов — перечисляются техническое задание, программная документация, руководства, которые используются при испытаниях.
2. Методика испытаний
Методика содержит конкретные процедуры проверки каждого требования. Это наиболее детализированная часть документа:
- Перечень проверяемых характеристик — с привязкой к пунктам ТЗ или спецификации (например: "п. 4.2 ТЗ — функция формирования отчёта");
- Методы проверки — описание того, как именно осуществляется контроль (визуальный осмотр, автоматизированное тестирование, анализ логов и т.п.);
- Входные данные — тестовые наборы, сценарии, исходные условия;
- Ожидаемые результаты — чёткое описание того, что должно быть получено при корректной работе;
- Форма фиксации результатов — протокол, акт, отчёт;
- Критерии приёмки/неприёмки — например: "все функции работают в соответствии с ожидаемыми результатами", "допускается не более 1 критической ошибки".
Методика должна быть настолько конкретной, чтобы любой квалифицированный специалист мог повторить испытания и получить сопоставимые результаты.
Виды испытаний, отражаемые в ПМИ
В зависимости от стадии жизненного цикла и целей, ПМИ может охватывать:
- Предварительные испытания — проводятся разработчиком для внутренней верификации;
- Приёмочные испытания — проводятся заказчиком или приёмочной комиссией для подтверждения готовности к вводу в эксплуатацию;
- Периодические испытания — в случае серийного выпуска или длительной эксплуатации;
- Испытания после модификации — при внесении изменений в программу.
Каждый тип испытаний может иметь отдельную ПМИ или быть включён в обобщённый документ с соответствующей маркировкой.
Связь ПМИ с другими документами
ПМИ не существует изолированно. Она органично вписана в систему документации:
- С ТЗ — каждое требование из ТЗ должно быть покрыто пунктом в методике;
- С программной документацией — описание применения и функциональные характеристики используются для формулировки ожидаемых результатов;
- С протоколами испытаний — результаты выполнения ПМИ фиксируются в актах, которые ссылаются на конкретные пункты методики;
- С пояснительной запиской — при анализе несоответствий используется информация об архитектурных решениях.
Таким образом, ПМИ обеспечивает сквозную прослеживаемость: от требования → к проверке → к подтверждению.
Современный контекст — ПМИ и agile-практики
В условиях гибких методологий (Scrum, Kanban) формальный документ ПМИ часто воспринимается как избыточный. Однако в регулируемых отраслях и при работе по государственным контрактам отказ от ПМИ невозможен. В таких случаях применяется гибридный подход:
- Требования из бэклога или пользовательских историй формализуются в виде спецификации;
- На основе спецификации составляется ПМИ в соответствии с ГОСТ;
- Автоматизированные тесты (unit, integration, E2E) служат инструментальной реализацией методики;
- Результаты автоматизированного тестирования агрегируются в отчёты, которые используются при составлении протоколов.
Такой подход сочетает гибкость разработки с формальной отчётностью, требуемой нормативами.
Пример типовой структуры ПМИ по ГОСТ 19.301–79
Ниже представлена развернутая структура Программы и методики испытаний, соответствующая требованиям ГОСТ 19.301–79 и адаптированная к реальной инженерной практике. Документ оформляется на фирменном бланке организации и утверждается руководителем исполнителя и согласовывается с представителем заказчика.
Обложка
(оформляется по ЕСПД — наименование документа, обозначение, наименование изделия, стадия разработки, дата, подписи)
1. Введение
Краткое обоснование разработки ПМИ. Пример:
Настоящая программа и методика испытаний разработана в соответствии с п. 7 технического задания № ХХХ от дд.мм.гггг и предназначена для проведения приёмочных испытаний программного средства "Система электронного документооборота (СЭД)" версии 2.1.
2. Основания для проведения испытаний
- Договор № ___ от ___;
- Техническое задание № ___;
- Программа работ по проекту;
- Приказ о назначении приёмочной комиссии.
3. Назначение и область применения программного изделия
Краткое описание функций СЭД, целевой аудитории (секретари, руководители, сотрудники), условий эксплуатации (локальная сеть, веб-доступ, поддерживаемые ОС и браузеры).
4. Цель испытаний
Проверка соответствия программного средства требованиям, установленным в техническом задании № ХХХ, а также подтверждение готовности к вводу в эксплуатацию.
5. Состав испытаний
Перечень видов испытаний:
- Функциональные испытания;
- Испытания на совместимость;
- Испытания на производительность (до 1000 одновременных пользователей);
- Испытания на отказоустойчивость (перезапуск сервера, потеря соединения);
- Проверка требований к безопасности (аутентификация, авторизация, аудит).
6. Порядок проведения испытаний
Этапы:
- Подготовка тестового стенда;
- Загрузка тестовых данных;
- Последовательное выполнение процедур по методике;
- Фиксация результатов в протоколах;
- Анализ отклонений;
- Подписание акта приёмки.
7. Условия проведения испытаний
7.1. Аппаратные требования
- Сервер — 4 ядра CPU, 16 ГБ ОЗУ, 500 ГБ SSD;
- Клиентские рабочие станции: не менее 2 шт., ОС Windows 10 / macOS 12+.
7.2. Программные требования
- ОС сервера: Ubuntu 22.04 LTS;
- СУБД: PostgreSQL 14;
- Браузеры — Chrome 115+, Firefox 115+, Edge 115+.
7.3. Данные для испытаний
- Набор пользователей (100 учётных записей);
- Реестр входящих и исходящих документов (1000 записей);
- Шаблоны документов (10 типов).
8. Состав участников испытаний
- От исполнителя: ведущий разработчик, тест-инженер;
- От заказчика: представитель отдела ИТ, конечный пользователь;
- Председатель приёмочной комиссии: зам. директора по ИТ.
9. Сроки и место проведения
- Место: тестовая зона ЦОД заказчика;
- Сроки: с 10 по 14 ноября 2025 г.
10. Перечень представляемых документов
- Техническое задание;
- Руководство администратора;
- Руководство пользователя;
- Текст программы (в архиве);
- Пояснительная записка.
11. Методика испытаний
Примечание: далее следует таблица, где каждый пункт ТЗ соотносится с процедурой проверки.
| № п/п | Пункт ТЗ | Проверяемая функция | Входные данные | Ожидаемый результат | Метод проверки | Критерий приёмки |
|---|---|---|---|---|---|---|
| 11.1 | п. 4.2 ТЗ | Регистрация входящего документа | Форма с полями: номер, дата, отправитель, тема | Документ сохранён в БД, присвоен уникальный ID, доступен в реестре | Ручной ввод + проверка в БД | Все поля сохранены корректно, ID уникален |
| 11.2 | п. 4.5 ТЗ | Маршрут согласования | Выбор маршрута "Секретарь → Начальник отдела → Финансист" | Документ последовательно появляется в рабочих местах участников | Имитация действий пользователей | Статус документа меняется корректно, уведомления отправлены |
| ... | ... | ... | ... | ... | ... | ... |
Каждая строка — это отдельная проверка. По завершении составляется протокол испытаний с указанием:
- дата и время проведения;
- фактический результат;
- выявленные отклонения (если есть);
- вывод: "соответствует / не соответствует".
Сравнение с IEEE 829 — международный взгляд на документирование испытаний
IEEE Std 829-2008 — международный стандарт, описывающий структуру тестовой документации. В отличие от ГОСТ 19.301, где всё содержимое объединено в один документ (ПМИ), IEEE 829 разделяет функции на несколько специализированных артефактов:
| ГОСТ 19.301 (ПМИ) | IEEE 829 |
|---|---|
| Программа испытаний | Test Plan (TP) |
| Методика испытаний | Test Проектирование Specification + Test Case Specification |
| Протокол испытаний | Test Log + Test Incident Report + Test Summary Report |
Ключевые различия:
- Гибкость vs формализм: IEEE 829 допускает адаптацию объёма и глубины каждого документа под проект; ГОСТ требует строгого соблюдения структуры.
- Фокус на процессе — IEEE 829 делает акцент на управлении тестированием (роли, риски, стратегия); ГОСТ — на проверке требований.
- Юридический контекст: ПМИ по ГОСТ неотделима от договора и используется в приёмке; IEEE 829 — внутренний инженерный документ (хотя может быть адаптирован для внешней отчётности).
Тем не менее, содержательная основа схожа — и там, и там требуется описание целей, методов, входных данных, ожидаемых результатов и критериев.
В международных проектах с российскими контрагентами часто применяется гибрид: структура ПМИ сохраняется для юридической отчётности, а внутри команды используется модель IEEE 829 с автоматизированными тестами и трассировкой требований в Jira/Confluence/TestRail.
Матрица прослеживаемости — от требования к подтверждению
Матрица прослеживаемости (Traceability Matrix) — это инструмент, обеспечивающий сквозную связь между:
- Требованиями (ТЗ);
- Проверками (ПМИ);
- Результатами (протоколы, тесты).
Пример фрагмента матрицы:
| ID требования | Требование | ID проверки (ПМИ) | Автотест | Статус |
|---|---|---|---|---|
| REQ-DOC-001 | Возможность регистрации входящего документа | TEST-DOC-001 | test_register_incoming.py | Пройден |
| REQ-SEC-005 | Аудит действий администратора | TEST-SEC-005 | test_admin_audit.log | Пройден |
Такая матрица позволяет:
- Убедиться, что все требования покрыты проверками;
- Быстро выявить непроверенные или проваленные требования;
- Обосновать готовность к приёмке (все REQ → TEST → Passed).
В ПМИ по ГОСТ матрица не обязательна, но на практике она формируется неявно через таблицу в разделе "Методика".
Когда формальный документ обязателен, а когда избыточен
На практике полезно сразу разделять контексты:
- контрактный/государственный контур - формальные ТЗ, ПМИ, акты изменений обязательны;
- внутренний продуктовый контур - допускается облегченный формат, но с сохранением прослеживаемости требований;
- гибридный контур - внутри команды agile-артефакты, наружу формальный комплект.
Так проще избежать споров в конце проекта, когда команда "работала по Jira", а заказчик ожидает проверку по пунктам ТЗ.
Мини-чеклист качества ТЗ перед согласованием
Перед передачей ТЗ на подпись удобно пройти короткий контроль:
- Все ключевые требования измеримы и проверяемы.
- Нет решений по реализации там, где нужны только требования.
- Есть явные критерии приемки и сценарии испытаний.
- Понятно, как управляются изменения и кто их утверждает.
- Указаны связанные документы — спецификации, протоколы, руководства.
Этот чеклист хорошо дополняет блок про артефакты из Артефакты аналитической деятельности и помогает готовить основу для технического дизайна в Технический дизайн на основе требований.
Частая ошибка в проектах
Команда пишет "подробное ТЗ", но на деле это смесь требований, проектных решений и задач из бэклога. Документ разрастается, теряет фокус и перестает быть управляемым.
Практичнее разделять:
- ТЗ - что должно быть получено;
- технический дизайн - как это будет реализовано;
- задачи - кто и когда это делает.
Такое разделение экономит время на согласовании и снижает риск конфликтов на приемке.