--- name: quality-matrix description: Аудит артефактов требований IT-систем на полноту и измеримость. Агент выявляет незаполненные ячейки матрицы программирования качества (лакуны) и метрологически несостоятельные формулировки, угрожающие объективному качеству продукта. disable-model-invocation: true allowed-tools: Read Glob Grep WebSearch metadata: author: Nikolay Marusov version: "2.2" --- # Многофакторный аудит качества и полноты требований IT-систем (матрица программирования качества) **Первичная цель агента:** Обнаружить все структурные пробелы (лакуны) в покрытии матрицы программирования качества требованиями. **Вторичная цель:** Выявить и пометить все метрологически несостоятельные требования (пустые, неизмеримые формулировки). **Базовая аксиома:** Качество — объективная мера соответствия характеристик IT-системы задачам пользователя на всех этапах жизненного цикла (ЖЦ). Любая ячейка матрицы, не закрытая хотя бы одним измеримым требованием, порождает «свободный параметр» и неконтролируемый риск. --- ## Определение матрицы программирования качества **Матрица программирования качества** — это инструмент полноты, построенный по методу системной инженерии. Она представляет собой таблицу размером 5×4 (5 строк × 4 колонки), образующую 20 ячеек. Каждая ячейка — это **обязательный класс требований**, который должен быть закрыт как минимум одним измеримым требованием. **Строки (факторы обусловленности)** — это объективные силы, которые влияют на IT-систему независимо от желания разработчика. Иерархия строк жёсткая: если не обеспечено требование вышестоящей строки, то любые требования нижестоящих строк теряют смысл, так как система выйдет из строя или не сможет применяться. | Строка | Фактор | Суть вопроса, на который нужно ответить | |---|---|---| | 1 | **Среда** | В каких внешних условиях IT-система должна сохранять работоспособность? Как среда влияет на систему, а система — на среду? Среда включает: **социальные** (политика, демография, языки, культурные нормы, менталитет пользователей, хакинг, человеческий фактор), **регуляторные** (законы, стандарты, отраслевые регламенты, требования сертификации: GDPR, HIPAA, PCI DSS, 152-ФЗ, CCPA), **корпоративные** (политики безопасности, SLA смежных систем, корпоративные стандарты, процедуры закупок и согласований, действия конкурентов), **технологические** (аппаратное окружение, сетевая инфраструктура, операционные среды, браузеры, протоколы, экосистема API, облачные провайдеры, кибербезопасность), **природные** (геораспределённость, климатические условия ЦОД, природные катастрофы и отказоустойчивость к ним), а также прочие объемлющие факторы и тенденции (рыночные тренды, технологическое импортозамещение, миграция платформ). | | 2 | **Эргономика** | Как человек взаимодействует с IT-системой? Учтены ли когнитивная нагрузка, ментальные модели, паттерны поведения, доступность для разных групп пользователей (включая людей с ограниченными возможностями — a11y), время реакции, порог внимания, утомляемость от интерфейса? | | 3 | **Функции** | Какие задачи IT-система выполняет? Какая польза создаётся для клиента? Это то, ради чего система создаётся: бизнес-логика, алгоритмы, операции, вычисления, хранение, передача данных, интеграции. | | 4 | **Аварии/Катастрофы** | Какие существуют источники угроз (внешние, внутренние)? Как предотвратить катастрофы? Что происходит при отказах, ошибках, некорректных действиях, атаках? Каков приемлемый ущерб? Как система деградирует, восстанавливается, защищает данные и сохраняет целостность? Надёжность, усточивость к сбоям. | | 5 | **Технологическая обеспеченность ЖЦ** | Какими управленческими инструментами, процедурами, инструментами, платформами, технологическим стеком, ресурсами, компетенциями обеспечиваются проектирование, разработка, развёртывание, сопровождение и вывод системы из эксплуатации? | **Колонки (этапы жизненного цикла)** — это временные срезы существования IT-системы. Требование должно быть определено для каждого этапа, иначе система окажется неготовой к этому этапу. | Колонка | Этап ЖЦ | Суть вопроса, на который нужно ответить | |---|---|---| | 1 | **Проектирование и Разработка** | Как выявляются требования? Как система будет спроектирована, разработана, протестирована, собрана в билд и развёрнута? Какие требования предъявляются к самому процессу создания? (требования, CI/CD, тестовые среды, ревью, линтеры, метрики кода, управление зависимостями) | | 2 | **Эксплуатация / Удовлетворение потребностей** | Как система выполняет свои функции в руках пользователя в штатном режиме? Это целевой этап. (доступность, время отклика, пропускная способность, точность результатов, пользовательский опыт, поведение под нагрузкой, обучение/само использованию приложения) | | 3 | **Эксплуатация / Сопровождение** | Как система сопровождается: мониторинг, логирование, диагностика, обновление (включая rolling updates, blue-green, canary), миграция данных, резервное копирование, восстановление, управление инцидентами? Как собирается обратная связь от пользователей? | | 4 | **Вывод из эксплуатации / Миграция** | Как система выводится из эксплуатации? Как мигрируются данные? Как отзываются доступы? Как утилизируются учётные записи, артефакты, конфигурации, домены, SSL-сертификаты? | **Методология нахождения лакун:** Лакуна (пробел) в требованиях — это ситуация, когда на вопрос, заложенный в ячейку, в артефакте нет измеримого ответа. Для обнаружения лакуны агент последовательно перебирает все 20 ячеек и для каждой задаёт проверочный вопрос. **Проверочные вопросы для каждой ячейки (контрольный список лакун):** | Ячейка | Проверочный вопрос | |---|---| | 1.1 | В каких социальных, регуляторных, корпоративных, технологических, природных условиях должна вестись разработка? Какие ограничения среды накладываются на процесс создания? (лицензии на ПО, экспортные ограничения, политики использования open-source, доступность облачных регионов для разработки, требования по хранению исходного кода) | | 1.2 | В каких социальных (языки, культурные нормы, менталитет, количество пользователей), регуляторных (GDPR, HIPAA, 152-ФЗ, отраслевые стандарты), корпоративных (SLA, политики безопасности клиента, SSO-провайдеры), технологических (браузеры, ОС, устройства, сетевые конфигурации, облачные провайдеры, API смежных систем, протоколы, нагрузка) и природных (геораспределённость пользователей, требования к Disaster Recovery по географическому признаку) условиях система должна функционировать? | | 1.3 | Какие социальные, регуляторные, корпоративные и технологические условия среды должны быть обеспечены для сопровождения? (доступ к production-окружению, аудит-следы, соответствие регуляторным требованиям при обработке инцидентов, SLA на реагирование) | | 1.4 | Какие регуляторные, корпоративные, экологические, этические и технологические ограничения действуют при выводе системы из эксплуатации? (требования к хранению данных после остановки сервиса, право на забвение, уведомление пользователей, передача доменов/сертификатов, compliance при архивировании) | | 2.1 | Какие эргономические требования к инструментам разработки? (читаемость кода, навигация по репозиторию, документация для разработчика, UX CI/CD-пайплайнов, онбординг новых членов команды, ИИ-агенты) | | 2.2 | Каковы когнитивные, визуальные, моторные требования к пользовательскому интерфейсу? Учтены ли доступность (a11y: WCAG 2.1 AA), локализация (включая RTL-языки), ментальные модели разных групп пользователей, время обучения, порог ошибок, утомляемость, скорость отклика, когнитивная нагрузка при выполнении частых операций? | | 2.3 | Каковы эргономические требования к инструментам сопровождения? (дашборды мониторинга, консоли администратора, читаемость и фильтрация логов, UX для DevOps/SRE/операторов, эргономика алертов и уведомлений) | | 2.4 | Каковы эргономические требования к процессу вывода из эксплуатации? (интерфейс миграции данных, UX администратора при удалении/архивировании, понятность процедуры для конечного пользователя, уведомления и инструкции) | | 3.1 | Как происходит сама разработка? Какие функциональные требования должны быть проверены на этапе разработки? (автоматические тесты — unit/integration/e2e, приёмочное тестирование, проверки безопасности на CI, статический анализ, тестирование производительности на этапе сборки) | | 3.2 | Какие функции система выполняет для пользователя? Какую боль пользователя закрывает? Какие показатели бизнеса улучшает? (бизнес-логика, операции, отчёты, интеграции, API, производительность, точность) | | 3.3 | Какие функции обеспечивают сопровождаемость? (мониторинг, алертинг, распределённая трассировка, аудит, управление конфигурациями, переключение feature-флагов, A/B-тестирование, канареечные релизы, сбор обратной связи, инструменты поддержки) | | 3.4 | Какие функции обеспечивают вывод из эксплуатации? (экспорт данных пользователя в машиночитаемом формате, удаление учётных записей, перенаправление трафика, уведомления, архивирование логов и артефактов) | | 4.1 | Какие аварийные сценарии должны быть учтены на этапе разработки? (падение CI/CD, утечка секретов в репозиторий, вредоносный код/backdoor, компрометация сборочного процесса, supply chain attack, сбой системы контроля версий, потеря инфраструктуры как код) | | 4.2 | Что происходит при отказах системы у пользователя? Какой простой допустим? Как защищены данные при сбоях, атаках, ошибках пользователя? (RPO, RTO, деградация функциональности, rate limiting, circuit breaker, защита от DDoS, обработка некорректного ввода, защита от OWASP Top 10, целостность данных при partitioned network) | | 4.3 | Какие аварийные сценарии возможны при сопровождении? (неудачное обновление и откат, отказ БД и стратегия восстановления, потеря логов/метрик, компрометация админ-доступа, случайное удаление production-данных оператором) | | 4.4 | Какие аварийные сценарии возможны при выводе из эксплуатации? (потеря данных при миграции, зависшие транзакции и их разрешение, несанкционированный доступ к архивным данным, неполное удаление данных у всех процессоров/подрядчиков) | | 5.1 | Какие процедуры, платформы, инструменты, компетенции команды необходимы для проектирования и разработки? (CI/CD-платформа, VCS, контейнеризация и оркестрация, линтеры, тестовые фреймворки, код-ревью, управление секретами, SBOM) | | 5.2 | Какая инфраструктура и компетенции необходимы пользователю для эксплуатации? (клиентские устройства, пропускная способность сети, браузер и его версия, плагины, права доступа, обучение, документация для пользователя, служба поддержки) | | 5.3 | Какие процедуры, инструменты, регламенты необходимы для сопровождения? Как система должна справляться к кратным увеличением нагрузки? (мониторинг и observability-стек, масштабируемость, централизованное логирование, алертинг и on-call rotation, управление инцидентами, резервное копирование и план восстановления, управление changeset и релизами, инструкции, автоматические ассистенты) | | 5.4 | Какие процедуры, инструменты, регламенты необходимы для вывода из эксплуатации? (план миграции, процедура удаления данных и верификация полноты удаления, отзыв доступов, архивирование артефактов, передача знаний и документации) | **Правило применения проверочных вопросов:** Агент должен получить на каждый проверочный вопрос хотя бы один измеримый ответ из артефакта. Если ответа нет — ячейка является лакуной (🔴). Если ответ есть, но он не проходит проверку метрологической состоятельности (Шаг 3) — ячейка получает статус 🟠. Если ответ измерим, но неполон относительно опыта других проектов (Шаг 5) — ячейка получает статус 🟡. Только измеримый и полный ответ даёт статус 🟢. **Принцип обратного вывода (дополнительный метод обнаружения лакун):** Если агент находит в артефакте требование, которое не удаётся отнести ни к одной ячейке, это означает одно из двух: - Требование сформулировано настолько размыто, что его невозможно классифицировать → переводится в разряд метрологически несостоятельных (🟠). - Требование относится к ячейке, которая уже закрыта, и расширяет её покрытие → добавляется в соответствующую ячейку. --- # Алгоритм анализа артефакта(ов) ## Шаг 1: Идентификация и подготовка требований Перед заполнением матрицы агент извлекает из предоставленных артефактов все формулировки, претендующие на роль требований. Каждое требование сразу получает одну из двух меток: - **Измеримое:** допускает метрологическую проверку (см. Шаг 3). - **Неизмеримое (метрологически несостоятельное):** нарушает критерии Шага 3 — фиксируется, но не считается закрывающим какую-либо ячейку матрицы. ## Шаг 2: Картирование требований на двухкоординатную матрицу Классифицируйте каждое **измеримое** требование в ячейку на пересечении Строки (фактора обусловленности) и Колонки (этапа ЖЦ). Используйте определения и проверочные вопросы из раздела «Определение матрицы программирования качества». Формат нумерации ячеек — `<Строка>.<Колонка>`. Например, ячейка 2.2 — «Эргономика на этапе эксплуатации». *Правило закрытия ячейки:* Ячейка считается закрытой, только если в ней зафиксировано **минимум одно измеримое требование**. ## Шаг 3: Верификация метрологической состоятельности (для каждого требования) Требование признается состоятельным только при выполнении трёх условий: 1. **Однозначность:** лексически однозначно трактуется в целевой профессиональной среде разработки и эксплуатации IT-систем. 2. **Измеримость:** выражено через численные значения, статистические распределения или дихотомические критерии (да/нет) с чётким условием проверки. 3. **Принадлежность к допустимому классу:** - Базовое значение ± допуск (например, время отклика API ≤ 200 мс ± 10%) - Мин/Макс граница (например, минимальная пропускная способность 1000 RPS) - Диапазон допустимых значений (например, поддержка браузеров Chrome 90+, Firefox 90+, Safari 15+) - Многомерное распределение (например, latency p50 ≤ 100 мс, p95 ≤ 200 мс, p99 ≤ 500 мс) - Детерминированный алгоритм проверки (для бинарных/качественных требований, например: «валидация JWT-токена по алгоритму RS256 с публичным ключом из эндпоинта .well-known/jwks.json») Всё, что не удовлетворяет этим критериям, переводится в статус «**метрологически несостоятельное**» и не участвует в закрытии ячеек. ## Шаг 4: Поиск критических дефектов (лакун и нарушений иерархии) Агент выполняет последовательные проверки: 1. **Первичная проверка — лакуны:** Сканируется каждая ячейка матрицы. Любая ячейка без измеримых требований объявляется **лакуной (свободным параметром)**. 2. **Проверка иерархии строк:** Если ячейка в Строке 3 (Функции) или ниже закрыта требованиями, а соответствующая ячейка в Строке 1 (Среда) или 2 (Эргономика) для того же этапа ЖЦ пуста, это фиксируется как **«нарушение иерархии»**. Функциональные требования в такой ситуации считаются висящими в воздухе (например, описаны функции системы без указания браузеров, ОС, устройств, регуляторных ограничений, на которых они должны работать). 3. **Ловушка «Ячейки 3.2»:** Проверяется, не сконцентрированы ли все измеримые требования исключительно в колонке «Эксплуатация / Удовлетворение потребностей» и строке «Функции». Если да — фиксируется критический перекос, ведущий к игнорированию сопровождения, вывода из эксплуатации, безопасности среды и человеческого фактора. 4. **Типология пользователей:** Для массовых IT-систем проверяется наличие требований, учитывающих различные классы пользователей (роли, права доступа, уровни подготовки, языковые группы, пользователи с ограниченными возможностями, культурные особенности). Отсутствие такой дифференциации считается лакуной в Строке 2 (Эргономика) и/или Строке 1 (Среда — социальные и культурные факторы). ## Шаг 5: Выявление неучтённых требований на основе опыта других проектов Для каждой ячейки матрицы, независимо от статуса (закрыта, лакуна, несостоятельное покрытие), агент проводит веб-поиск реального опыта других IT-проектов, инцидентов и извлечённых уроков. Цель — обнаружить конкретные требования или классы требований, которые были упущены в анализируемом артефакте, но доказали свою критическую значимость в аналогичных системах. **Процедура поиска для каждой ячейки:** 1. **Формирование поискового запроса на основе семантики ячейки:** - Скомбинируйте термины строки и колонки с операторами: - `"lessons learned"` / `"извлечённые уроки"` - `"post-mortem"` / `"анализ инцидентов"` - `"requirements gap"` / `"пропущенные требования"` - `"failure case"` / `"отказ из-за"` - `"outage postmortem"` / `"incident review"` / `"breach report"` - Привяжите к домену IT-системы (веб-приложение, микросервис, мобильное приложение, SaaS, API, data pipeline), если он определён в артефактах. 2. **Поиск и извлечение референсных инцидентов:** - Найдите публичные разборы отказов, аварий, провалов внедрения IT-систем, где корневой причиной стало отсутствие требований именно в контексте данной ячейки. - Приоритетные источники: отраслевые базы инцидентов (The Verge outage reports, Cloudflare Blog, GitHub Availability Report, AWS Post-Event Summaries), статьи "How we failed", отраслевые конференции (SREcon, DevOpsDays, OWASP), IT-шные сайты и формумы (habr.com, stackoverflow.com). 3. **Формулирование неучтённых требований:** - На основе каждого релевантного инцидента сформулируйте **одно конкретное требование**, которое могло бы предотвратить проблему. - Требование должно быть: привязано к источнику, содержать измеримый критерий (если возможно), указано в формате "система должна...". 4. **Фиксация вывода:** Для ячейки указываются: - Краткое описание инцидента-источника (1-2 предложения); - Сформулированное неучтённое требование; - Класс требования (среда / эргономика / функция / авария / технологическая обеспеченность — может не совпадать со строкой ячейки, если инцидент показал неочевидную связь). **Формат вывода для ячейки:** ``` ### Ячейка [Строка] × [Колонка] **Статус в артефакте:** [Закрыта / Лакуна / Несостоятельное покрытие] **Найденные неучтённые требования (из опыта других проектов):** 1. **Источник:** [Описание инцидента/проекта, источник] **Упущенное требование:** [Формулировка] **Класс:** [Среда/Эргономика/Функция/Авария/Тех.обеспеченность] 2. ... **Итого неучтённых требований для ячейки:** [N] ``` **Итоговый свод по шагу 5:** Общее количество неучтённых требований, выявленных через анализ опыта других проектов. Ранжирование по критичности: требования, отсутствие которых уже приводило к авариям, инцидентам безопасности или остановке эксплуатации в аналогичных системах, помечаются как **КРИТИЧЕСКИ УПУЩЕННЫЕ**. --- ## Шаг 6: Формирование вердикта — «Матрица программирования качества» Агент формирует итоговый отчет на основе результатов всех предыдущих шагов. Каждая ячейка матрицы получает итоговый статус, отражающий не только наличие требований, но и их содержательную полноту относительно опыта других проектов. **Итоговые статусы ячеек (приоритет от худшего к лучшему):** | Статус | Обозначение | Критерий | |---|---|---| | **Лакуна** | 🔴 | Ячейка пуста — ни одного требования не сформулировано. Свободный параметр. | | **Метрологически несостоятельное покрытие** | 🟠 | Требования в ячейке есть, но все они не прошли проверку Шага 3 (неизмеримы, бытовой язык, неоднозначны). Ячейка не считается закрытой. | | **Формально закрыта, содержательно неполна** | 🟡 | Требования в ячейке есть и они измеримы, но анализ опыта других проектов (Шаг 5) выявил неучтённые аспекты/классы требований, отсутствие которых в аналогичных системах приводило к инцидентам, отказам или провалам внедрения. | | **Закрыта и содержательно полна** | 🟢 | Ячейка содержит ≥1 измеримого требования, и анализ опыта других проектов не выявил критически упущенных аспектов. | **Формат итоговой матрицы:** ``` ### Матрица программирования качества **Артефакт:** [название/путь к файлу] **Дата анализа:** [дата] | Строки \ Колонки ЖЦ | Проектирование и Разработка | Эксплуатация / Потребности | Эксплуатация / Сопровождение | Вывод из эксплуатации / Миграция | |---|---|---|---|---| | **1. Среда** | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | | **2. Эргономика** | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | | **3. Функции** | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | | **4. Аварии/Катастрофы** | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | | **5. Тех. обеспеченность ЖЦ** | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | 🟢/🟡/🟠/🔴 | ``` **Дополнительные маркеры в ячейках матрицы:** - **Нарушение иерархии** — если ячейка низшей строки закрыта (🟢 или 🟡), а соответствующая ячейка высшей строки (Строки 1 или 2) для того же этапа ЖЦ имеет статус 🔴 или 🟠. В ячейке низшей строки добавляется символ **⬆️** (например: 🟡⬆️). **Сводка дефектов:** ``` ### Сводка дефектов полноты и состоятельности требований **Количественная оценка:** - Всего ячеек матрицы: 20 - 🔴 Лакун: [N] - 🟠 Метрологически несостоятельное покрытие: [N] - 🟡 Формально закрыта, содержательно неполна: [N] - 🟢 Закрыта и содержательно полна: [N] - ⬆️ Нарушений иерархии: [N] **Критические дефекты (требуют немедленного устранения):** 1. [Перечень ячеек 🔴 в Колонках 2 и 3 — наивысшая критичность] 2. [Перечень ячеек 🟠 в Колонках 2 и 3] 3. [Перечень нарушений иерархии ⬆️] 4. [Перечень проблемных артефактов] **Существенные замечания (требуют устранения в приоритетном порядке):** 1. [Перечень ячеек 🟡 с указанием неучтённых аспектов из Шага 5] 2. [Перечень ячеек 🔴 в Колонках 1 и 4] 3. [Перечень проблемных артефактов] ``` **Формат детализации для каждой проблемной ячейки:** ``` ### Ячейка [Строка] × [Колонка] — 🟡 Формально закрыта, содержательно неполна **Существующие требования в артефакте:** - [Требование 1] - [Требование 2] **Неучтённые аспекты (из опыта других проектов):** 1. **Источник:** [Инцидент/проект] **Упущенное требование:** [Формулировка] **Почему критично:** [1-2 предложения о последствиях отсутствия] 2. ... **Рекомендация:** [Конкретные типы требований для добавления] ``` **Формат для ячеек с несостоятельным покрытием:** ``` ### Ячейка [Строка] × [Колонка] — 🟠 Метрологически несостоятельное покрытие **Существующие формулировки в артефакте:** - "[Формулировка 1]" — причина несостоятельности: [однозначность/измеримость/класс] - "[Формулировка 2]" — причина несостоятельности: [однозначность/измеримость/класс] **Неучтённые аспекты (из опыта других проектов):** [Аналогично формату выше] **Рекомендация:** Переформулировать существующие требования в измеримом виде и дополнить неучтёнными аспектами. ``` **Итоговый вывод:** ``` ### Итоговый вердикт **Практика — критерий истины.** На основе анализа матрицы программирования качества: - Обнаружено [N] лакун (🔴), [N] ячеек с метрологически несостоятельным покрытием (🟠), [N] содержательно неполных ячеек (🟡). - Выявлено [N] нарушений иерархии требований (⬆️). - Из опыта других проектов обнаружено [N] неучтённых требований, способных предотвратить известные инциденты и отказы. **Качество продукта признаётся:** - 🟢 **Объективно подтверждённым** — если все ячейки в статусе 🟢, нет нарушений иерархии. - 🟡 **Субъективно допустимым, но объективно неподтверждённым** — если есть ячейки 🟡, но нет 🔴 и 🟠 в критических колонках (2 и 3). - 🔴 **Объективно неподтверждённым, проект под угрозой срыва** — если есть хотя бы одна 🔴 или 🟠 в Колонках 2 или 3, либо зафиксированы нарушения иерархии в критических строках. Проект несёт риски непредвиденных внешних воздействий (социальных, регуляторных, технологических), человеческого фактора или провала поддержки, которые не были учтены в требованиях и уже приводили к отказам в аналогичных системах. **Итоговый вывод:** ``` ### Итоговый вердикт **Практика — критерий истины.** На основе анализа матрицы программирования качества: - Обнаружено [N] лакун (🔴), [N] ячеек с метрологически несостоятельным покрытием (🟠), [N] содержательно неполных ячеек (🟡). - Выявлено [N] нарушений иерархии требований (⬆️). - Из опыта других проектов обнаружено [N] неучтённых требований, способных предотвратить известные инциденты и отказы. **Качество продукта признаётся:** - 🟢 **Объективно подтверждённым** — если все ячейки в статусе 🟢, нет нарушений иерархии. - 🟡 **Субъективно допустимым, но объективно неподтверждённым** — если есть ячейки 🟡, но нет 🔴 и 🟠 в критических колонках (2 и 3). - 🔴 **Объективно неподтверждённым, проект под угрозой срыва** — если есть хотя бы одна 🔴 или 🟠 в Колонках 2 или 3, либо зафиксированы нарушения иерархии в критических строках. Проект несёт риски непредвиденных внешних воздействий (социальных, регуляторных, технологических), человеческого фактора или провала поддержки, которые не были учтены в требованиях и уже приводили к отказам в аналогичных системах. ``` --- ## Шаг 7: Формирование открытых вопросов для устранения лакун **Конечная практическая цель агента** — не просто зафиксировать дефекты, а предоставить команде **готовый к использованию перечень открытых вопросов**, адресованных владельцу продукта, заказчику или стейкхолдерам. Каждый вопрос должен быть сформулирован так, чтобы ответ на него естественным образом закрывал лакуну измеримым требованием. **Правила формулирования открытых вопросов:** 1. **Один вопрос — одна лакуна/неучтённый аспект.** Вопросы не должны быть составными. Если лакуна широкая, она разбивается на несколько конкретных вопросов. 2. **Вопрос должен предполагать измеримый ответ.** Формулировка вопроса должна направлять респондента к численному значению, диапазону, перечню, бинарному выбору или алгоритму проверки. Избегайте вопросов, на которые можно ответить «да/нет» без конкретики, или вопросов, начинающихся с «Предусмотрено ли...» — вместо этого спрашивайте «Каково значение...», «Какие именно...», «В каких случаях...». 3. **Вопрос должен быть понятен стейкхолдеру без погружения в матрицу.** Используйте предметную лексику домена, избегайте терминов «Строка 1», «Ячейка 2.3». Вместо этого: «Какие регуляторные стандарты...», «Какой простой допустим...». 4. **Приоритет вопросов** соответствует критичности ячейки: сначала вопросы по ячейкам 🔴 в Колонках 2 и 3, затем 🟠 в тех же колонках, затем 🟡, затем 🔴 и 🟠 в Колонках 1 и 4. 5. **Для каждой лакуны должен быть сформулирован минимум один вопрос.** Если лакуна выявлена и через формальный статус ячейки, и через анализ опыта других проектов (Шаг 5), вопросы формулируются по каждому неучтённому аспекту отдельно. **Шаблон формулирования вопроса:** ``` **Контекст:** [1 предложение — почему этот вопрос важен, к какому этапу ЖЦ относится] **Источник лакуны:** [🔴 Лакуна / 🟠 Несостоятельное требование / 🟡 Неучтённый аспект из опыта: краткое указание инцидента] **Вопрос стейкхолдеру:** [Открытый вопрос, предполагающий измеримый ответ] **Ожидаемый формат ответа:** [Базовое значение ± допуск / Мин/Макс граница / Диапазон / Многомерное распределение / Детерминированный алгоритм проверки / Перечень] ``` **Формат итогового перечня открытых вопросов:** ``` ### Перечень открытых вопросов для устранения лакун **Артефакт:** [название/путь к файлу] **Дата анализа:** [дата] **Кому адресовано:** [Владелец продукта / Заказчик / Технический лид / DevOps-инженер / Архитектор] --- #### Блок 1: Критические вопросы (требуют ответа до начала разработки) **Вопрос 1.1** - **Контекст:** [контекст] - **Источник лакуны:** [источник] - **Вопрос стейкхолдеру:** [формулировка] - **Ожидаемый формат ответа:** [формат] **Вопрос 1.2** ... --- #### Блок 2: Существенные вопросы (требуют ответа до этапа приёмочного тестирования) **Вопрос 2.1** ... --- #### Блок 3: Рекомендательные вопросы (требуют ответа до вывода системы в эксплуатацию) **Вопрос 3.1** ... ``` **Принцип отнесения вопросов к блокам:** | Блок | Критерий включения | |---|---| | **Блок 1: Критические** | Вопросы по ячейкам 🔴 и 🟠 в Колонках 2 и 3, а также по нарушениям иерархии ⬆️. Без ответов на эти вопросы разработка не должна начинаться. | | **Блок 2: Существенные** | Вопросы по ячейкам 🟡 в Колонках 2 и 3, а также 🔴 и 🟠 в Колонках 1 и 4. Ответы должны быть получены до начала приёмочного тестирования. | | **Блок 3: Рекомендательные** | Вопросы по ячейкам 🟡 в Колонках 1 и 4, а также дополнительные вопросы, сформулированные на основе опыта других проектов, не вошедшие в критические и существенные. Ответы желательны до вывода системы в эксплуатацию. | **Итоговая цель шага 7:** На выходе агент предоставляет **готовый артефакт для встречи со стейкхолдерами** — структурированный перечень вопросов, на которые команда должна получить ответы для превращения лакун в измеримые требования и достижения статуса 🟢 по всем ячейкам матрицы программирования качества.