Skip to content
Engineering Stage

ES-102 — Navigation

Move through requirements work without losing source, evidence, or downstream traceability.

Requirements Path Repository Map Next: Context

ES-102 Navigation

Purpose

This page explains how to move through ES-102 and where requirements artifacts belong.

ES-102 connects ES-101 vision evidence to ES-103 planning and ES-104 architecture. Navigation matters because requirements lose value when their sources, locations, review evidence, and downstream consumers are unclear.

ES-102 path

Follow the stage in this order:

README.md
  ↓
navigation.md
  ↓
engineering_context.md
  ↓
activities.md
  ↓
evidence.md
  ↓
outputs.md
  ↓
readiness_gate.md
  ↓
stage_manifest.md
  ↓
../ES-103/README.md

The page sequence is intentional. First understand the stage, then understand why requirements matter, then perform the work, then evaluate evidence, outputs, and readiness.

Repository areas used in this stage

Repository Area Purpose
docs/engineering/ES-102/ User-facing ES-102 guidance.
template-library/requirements/ Reusable blank requirements artifacts.
examples/lmu-coicp/requirements/ Completed reference examples when available.
docs/requirements/ Project-specific completed requirements evidence.
docs/vision/ ES-101 source evidence used by ES-102.

What to copy

Copy blank templates from:

template-library/requirements/

into:

docs/requirements/

Then complete them for the project. Do not edit the original templates.

Expected project artifacts

Required ES-102 project artifacts:

docs/requirements/requirements_overview.md
docs/requirements/functional_requirements.md
docs/requirements/nonfunctional_requirements.md
docs/requirements/constraints.md
docs/requirements/use_cases_or_user_stories.md
docs/requirements/traceability_notes.md
docs/requirements/requirements_review.md
docs/requirements/requirements_readiness_summary.md

Optional supporting artifacts may be created when they clarify real project evidence:

docs/requirements/stakeholder_questions.md
docs/requirements/open_requirements_issues.md
docs/requirements/ai_requirements_notes.md
docs/requirements/requirements_change_log.md

Source evidence used by ES-102

ES-102 should draw from the ES-101 vision package:

docs/vision/problem_statement.md
docs/vision/vision_statement.md
docs/vision/stakeholders.md
docs/vision/scope.md
docs/vision/assumptions.md
docs/vision/success_metrics.md
docs/vision/vision_readiness_summary.md

Every major requirement should connect to at least one ES-101 artifact. Requirements without traceability should be challenged before they become planning input.

Use the ES-102 pages as stage guidance. Use docs/requirements/ as the evidence location. Use template-library/requirements/ only as reusable blank structure. Use examples as reference evidence, not as answers to copy.

Keep links in stage pages as source-file links where practical so MkDocs can validate them during strict builds.

Evidence note

The most important navigation boundary in ES-102 is the boundary between guidance and evidence. Stage pages explain the work. Project artifacts under docs/requirements/ record the work.

Common pitfall

Do not treat traceability as paperwork created after requirements are finished. Traceability is a thinking tool used while requirements are being formed.

Continue to Engineering Context

Understand why requirements and constraints are engineering control points.

Continue to Engineering Context →