Рекомендованная форма ТЗ¶
Статус: informative. Это рекомендация, а не норма. Соответствие RENAR не зависит от формы входного ТЗ ни в одном пункте: стандарт принимает ТЗ как данность — в том числе плохо структурированное — и нормирует не написание ТЗ, а работу с ним (
standard/01 §1.3: RENAR не нормирует процесс создания ТЗ на стороне клиента). Единственный нормативный механизм работы с ТЗ любого качества — контур ADAPT (standard/07).Приложение не создаёт обязательств и не расширяет ни один закрытый список (§1.7.5).
13.1 Статус и границы применения¶
ТЗ — документ, внешний по отношению к стандарту: его пишет или приносит клиент, оно живёт в контрактном контуре и подчиняется деловой практике вендора. Вся машинерия стандарта — прямая адаптация, обратные находки, ACTZ — построена именно на допущении, что входное ТЗ может быть любым. Если бы стандарт начал требовать форму ТЗ, он перестал бы принимать чужие ТЗ и потерял бы своё входное условие.
Поэтому у приложения три жёсткие границы, и они соблюдаются по всему корпусу:
- Соответствие не зависит от формы ТЗ. Глава о соответствии (
standard/13) не упоминает форму входного ТЗ ни в одном пункте. Организация с ТЗ произвольной структуры может заявить полное соответствие. - Проверки носителя не касаются структуры ТЗ. Ни одна автоматическая проверка не разбирает ТЗ на разделы и не требует их наличия. Требовать структуру ТЗ автоматической проверкой — значит нарушить границу §1.3.
- Реестром требований ТЗ не становится. Дублировать BR / SR в ТЗ — прямая анти-рекомендация (§13.5).
Единственный допустимый довод в пользу формы — наблюдение, а не обязанность: ТЗ, написанное по этой форме, порождает меньше обратных находок, сокращает число раундов уточнений и делает вывод приёмочных тестов надёжным (§13.6). Выбор остаётся за вендором и клиентом.
13.2 Основание формы: инверсия типологии находок¶
Форма рекомендуется не по привычке конкретного вендора, а по внутреннему основанию стандарта. Семь категорий обратных находок (§7.4.4) — это, по сути, каталог типовых дефектов ТЗ. Значит, рекомендованная форма есть инверсия типологии находок: каждый раздел существует не сам по себе, а как профилактика конкретной категории дефектов.
| Раздел формы | Закрываемая категория находок |
|---|---|
| Вне объёма проекта | scope — неясная граница работ |
| Роли пользователей (явная авторизация) | hidden-assumption — предположение, которое может быть неверно |
| Интеграции (ограничения, риски) | feasibility, regulatory |
| Определения | terminology — прямая профилактика |
| Ключевые сущности данных | terminology (сущности), hidden-assumption |
| Критерии «дано — когда — тогда» у каждого функционального требования | gap — ТЗ молчит о том, без чего невозможна реализация |
| Сценарии использования с пред- и постусловиями | contradiction — сценарии сталкивают требования между собой |
| Сопроводительные артефакты (таблица) | адресуемость приложений: каждое приложение становится единицей, на которую можно сослаться |
Таблица работает и в обратную сторону — как инструмент поиска дыр в самой форме. Именно она вскрыла, что категория terminology до появления раздела «Определения» оставалась единственной без профилактического раздела.
13.3 Разделы формы¶
Одиннадцать разделов. Нумерация — внутри ТЗ; стабильные идентификаторы пунктов (УС-NNN, ФТ-NNN, НФТ-NNN) задаются клиентом и далее не меняются: на них ссылаются приёмочные тесты (§9.19.3).
| № | Раздел | Содержание |
|---|---|---|
| 1 | Общее описание | Один абзац: что это, для кого, как работает |
| 2 | Определения | Термины клиента с фиксированными значениями (§13.4) |
| 3 | Роли пользователей | Таблица ролей; авторизация обозначается явно — в том числе явным «не предусмотрена» |
| 4 | Сценарии использования | УС-NNN: участник, предусловие, шаги, постусловие |
| 5 | Функциональные требования | ФТ-NNN: приоритет и критерии приёмки «дано — когда — тогда», включая минимум один негативный вариант с некорректными данными |
| 6 | Нефункциональные требования | НФТ-NNN: только явно ограниченное или значимое |
| 7 | Интеграции | Таблица на внешнюю систему: адрес, тип, ограничения, данные на входе и выходе, риски |
| 8 | Ключевые сущности данных | Словарь предметной области — не схема базы данных |
| 9 | Сопроводительные артефакты | Таблица приложений: тип, охват, расположение, статус |
| 10 | Вне объёма проекта | Явный перечень того, что не входит |
| 11 | Критерии приёмки проекта | Условия принятия, эталонный сценарий |
Разделы 4 и 5 — то, из чего выводится программа приёмочных испытаний (reference/14). Раздел 11 — её зародыш: клиент с самого начала видит, как будет проходить сдача.
13.4 Раздел «Определения» — второй, и почему именно так¶
Раздел ставится вторым, сразу после общего описания и до первого употребления терминов в сценариях и требованиях. Это следует практике ГОСТ и ISO, где термины и определения идут в начале документа.
Содержание — термины клиента, у которых возможно второе прочтение: роли и их синонимы, глаголы-действия («провести», «согласовать», «выгрузить»), статусы, единицы измерения, аббревиатуры организации. Форма — таблица «термин — значение — синонимы или чем термин не является».
| Термин | Значение | Синонимы / чем не является |
|---|---|---|
| Провести документ | Зафиксировать документ в учёте так, что он влияет на остатки | Не «сохранить»: черновик остатки не меняет |
Две рекомендации к наполнению:
- включать только термины с возможным вторым прочтением — словарь общеупотребительных слов раздел не заменяет;
- определять термин самостоятельной формулировкой. Определение через употребление («как в разделе 4») недопустимо: оно не снимает неоднозначность, а прячет её.
Раздел — прямой вход для сопоставления терминов в ADAPT: термин, зафиксированный клиентом, не порождает находку категории terminology, и весь терминологический слой не приходится достраивать раундами уточнений, хотя клиент мог зафиксировать свои термины сразу.
13.5 Чем ТЗ не является¶
ТЗ остаётся документом на языке клиента и его предметной области. Форма структурирует клиентский язык — она не превращает ТЗ в реестр требований.
Дублировать BR / SR в ТЗ не рекомендуется. Требования стандарта живут во внутреннем контуре и выводятся из ТЗ через интерпретацию (§7.12); скопированные в ТЗ, они расходятся с оригиналом при первой же правке и порождают два источника истины вместо одного. Развязка контуров — не формальность, а условие работы прослеживаемости.
Расстояние между языком ТЗ и языком стандарта — переменное и нормальное (§7.12.1). Форма это расстояние сокращает, но не отменяет.
13.6 Наблюдаемый эффект¶
Эффект фиксируется как наблюдение, а не как обещание и не как обязанность:
- меньше обратных находок — каждый раздел формы закрывает свою категорию заранее (§13.2);
- короче путь до требований — меньше раундов уточнений ACTZ (§7.13);
- надёжнее вывод приёмочных тестов: стабильные идентификаторы
УС-NNNиФТ-NNNдают адресацию поляverifiesбез интерпретации, а обязательный негативный вариант в критериях приёмки даёт парность положительных и отрицательных приёмочных тестов почти даром (§9.19).
Вендор со своим ТЗ теряет только скорость, но не соответствие.
13.7 Связь с другими документами¶
| Документ | Связь |
|---|---|
standard/07 §7.4.4 |
Семь категорий обратных находок — основание формы |
standard/07 §7.13 |
ACTZ — протокол уточнения ТЗ |
standard/07 §7.14 |
Итоговое ТЗ — эталон приёмки |
standard/09 §9.19 |
AT — приёмочный тест контрактного контура |
reference/14 |
Рекомендованная форма программы приёмочных испытаний |
reference/12 |
Шаблоны внутренних артефактов (BR / SR / TR / TC / AR / ACTZ / AT) |