Перейти к содержанию

04. Носитель: document-oriented store (обзор)

Informative appendix. Нормативные capability V1–V6 — standard/03. Практический пример на distributed VCS (git) — guide/03.

Document-oriented store — носитель, где артефакты RENAR хранятся как версионированные документы: стабильный идентификатор, цепочка ревизий (revision token), атомарное обновление, API-шлюз для lifecycle-переходов и подписей.

RENAR формально не привязан к классу систем document store — нормативно задаются только возможности (V1–V6) (§3.2–11.3).

1. Когда выбирать document-oriented store

Подходит, если:

  • нужно централизованное enterprise-хранилище требований для нескольких проектов;
  • non-technical stakeholders работают через web UI, а не через VCS;
  • федерация межпроектных ссылок и поиск — ключевое требование к продукту;

Не подходит, если:

  • команда уже стандартизирована на git workflow и PR/MR review;
  • нет ресурсов поддерживать сервер document store + search index + API gateway;
  • нужны полноценные контрольные примеры (TC) как объекты в той же среде без отдельной настройки пользовательских типов документов (см. §9 — наличие TC нужно для декларируемого соответствия RENAR);

2. Сопоставление возможностей V1–V6 (обобщённо)

Возможность Типичный механизм document store
V1 — неизменяемая история Цепочка неизменяемых ревизий документа + стабильный _id
V2 — атомарная единица изменения Одно целое приращение версии документа за шаг
V3 — сравнение и ревью (diff) Поток утверждения через API и интерфейс; перехват прямых правок статуса
V4 — ветвление и слияние Черновые документы либо ветви конфликтов (по возможностям продукта)
V5 — фиксация версии Поле со ссылкой на ревизию в связанных артефактах
V6 — автор и отметка времени Поля документа author + updated_at на каждую ревизию

Сравнение с распределённой VCS — §3.4 (таблица-пример; не является нормативным контрактом).

3. Миграция VCS ↔ document store

Миграция возможна, если в обеих реализациях носителя сохраняются:

  • канонические идентификаторы артефактов (BR/SR/SPEC/ADAPT);
  • связи трассируемости;
  • состояния жизненного цикла по закрытому списку §10.

Процедура миграции — project-specific runbook; нормативный минимум — проверка V1–V6 до cutover (§3.5).

4. См. также