RENAR Principles
Nine ideas the standard is built on. This is not the normative text — it's an introduction. Next: the full standard or the Core.
1. Five Values
The same as SENAR's — the RENAR methodology is built on them.
2. BR → SR → TR Hierarchy
Three levels of requirements — each with its own question and audience.
Who, what, why. Business goals, constraints, KPIs. Audience — stakeholders and the client.
What the system does. Functional and non-functional requirements. Audience — architects and developers.
What the implementer does. Goal and acceptance criteria in the tracker (Jira, Linear, GitLab Issues), not as a file.
3. ADAPT — Two-Way Adaptation
When an immutable TZ meets the reality of implementation.
Forward interpretation: TZ + context → BR / SR / SPEC.
Backward findings (7 categories): contradictions, gaps, risks — returned to the client.
Dual signature by client + architect records the agreed interpretation. The TZ stays immutable.
4. 9 SPEC Types (closed list)
A parallel axis to requirements via constrained-by[].
5. Test Cases (TC)
Not a byproduct of code, but a normative artifact on par with BR/SR.
- →Paired scenarios: positive and negative for every TC.
- →VLM for UX: visual criteria via a vision-language model.
- →Types by SPEC: TC-API, TC-AI, TC-SEC, and others.
- →Tag
[test-spec-change]: an explicit marker for a TC change.
6. Substrate and V1–V6
One standard — any storage with six capabilities (see chapter 3).
7. Quality Gates QG-0..2
Lifecycle checkpoints before moving on.
8. Maturity RENAR-1..5
Five maturity levels for requirements management (see chapter 11).
9. Relationship to SENAR
SENAR is how to do AI-native development. RENAR is what to do: which requirements, in what form, with what relationships.
You can apply RENAR without SENAR or vice versa; together they give full coverage of AI-native development.