ES-102 Evidence¶
Purpose¶
This page defines the evidence expected from ES-102.
Requirements evidence demonstrates that the system obligations and constraints are clear enough to support planning, architecture, design, implementation, testing, release, governance, operations, and stewardship.
A filled template is not automatically evidence. Evidence must be durable, reviewable, traceable, and useful to downstream engineering.
Required evidence¶
| Artifact | Evidence Purpose |
|---|---|
requirements_overview.md |
Connects ES-101 vision evidence to ES-102 requirements work. |
functional_requirements.md |
Defines required system behaviors. |
nonfunctional_requirements.md |
Defines required system qualities and trustworthiness expectations. |
constraints.md |
Defines solution boundaries and restrictions. |
use_cases_or_user_stories.md |
Shows stakeholder goals, interactions, alternate paths, and exception paths. |
traceability_notes.md |
Connects requirements to sources, constraints, use cases, and verification expectations. |
requirements_review.md |
Records review findings, corrections, accepted risks, and unresolved issues. |
requirements_readiness_summary.md |
Summarizes readiness for ES-103 planning. |
Evidence quality expectations¶
ES-102 evidence should be:
- clear enough for a reviewer to understand;
- bounded enough to prevent scope drift;
- traceable to ES-101 source evidence;
- reviewable by engineering and stakeholder reviewers;
- consistent with project scope and assumptions;
- useful to ES-103 planning and ES-104 architecture;
- explicit about AI-related obligations and human accountability;
- explicit about constraints and prohibited solution paths;
- realistic enough to be planned, tested, and governed.
Requirement quality test¶
A requirement is strong enough when a reviewer can answer:
- What must the system do or satisfy?
- Why does this requirement exist?
- What source evidence supports it?
- Is it in scope?
- Who or what does it serve?
- How will it be verified?
- What downstream stages must account for it?
If those questions cannot be answered, the requirement is not ready.
Constraint quality test¶
A constraint is strong enough when a reviewer can explain:
- what boundary it imposes;
- where it came from;
- what solutions it excludes;
- what risks it reduces;
- what downstream decisions must respect it.
Constraints that do not shape decisions are usually preferences, assumptions, or unresolved questions.
Traceability quality test¶
Traceability is strong enough when the team can move both directions:
ES-101 source evidence → requirement → verification expectation
and:
requirement → source evidence → downstream planning/design/testing use
Traceability should expose weak requirements. It should not hide them behind a table.
AI-use evidence¶
If AI materially assists requirements creation, record how it was used and how output was verified.
Minimum recommended statement:
AI assistance was used to draft, critique, or check requirements. The engineering team reviewed the final requirements for clarity, scope alignment, traceability, verification responsibility, and accountability.
AI-generated requirements are not evidence until reviewed, corrected, accepted, and stored as project-owned artifacts.
Review evidence¶
Requirements should be reviewed before ES-103.
Review findings should be recorded in:
docs/requirements/requirements_review.md
A useful review records ambiguity, conflicts, missing constraints, scope concerns, unverifiable requirements, AI accountability concerns, and open questions.
Evidence sufficiency¶
ES-102 evidence is sufficient when a reviewer can understand what the system must satisfy, what boundaries shape acceptable solutions, what evidence supports the requirements, what remains unresolved, and why ES-103 can begin.
A completed requirements template is not automatically requirements evidence. Evidence must be specific enough to challenge, revise, verify, and use.
Weak evidence forces later stages to rely on memory. Strong evidence lets later stages rely on the repository.