ES-102 Activities¶
Purpose¶
This page guides the requirements engineering work for ES-102.
Complete the activities in order. Iterate when later activities reveal earlier weakness. The goal is not to fill templates quickly. The goal is to produce requirements evidence strong enough to guide ES-103 planning and later lifecycle work.
Activity 1 — Review ES-101 evidence¶
Review all ES-101 vision artifacts before writing requirements.
Use:
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
Create:
docs/requirements/requirements_overview.md
Use template:
template-library/requirements/requirements_overview.md
The overview should explain how ES-101 evidence becomes ES-102 obligations. It should identify source artifacts, major requirement themes, major constraints, known uncertainty, and any areas that require stakeholder clarification.
Vision-to-requirements bridge evidence under docs/requirements/requirements_overview.md.
Activity 2 — Define functional requirements¶
Create:
docs/requirements/functional_requirements.md
Use template:
template-library/requirements/functional_requirements.md
Each functional requirement should include an identifier, statement, source, rationale, priority, verification approach, status, and open questions when needed.
A functional requirement should describe a system obligation, not a preferred design. It should be specific enough that later planning, architecture, implementation, testing, and review can use it.
Behavioral requirements evidence under docs/requirements/functional_requirements.md.
Activity 3 — Define nonfunctional requirements¶
Create:
docs/requirements/nonfunctional_requirements.md
Use template:
template-library/requirements/nonfunctional_requirements.md
Consider security, privacy, reliability, availability, performance, usability, accessibility, auditability, maintainability, observability, recoverability, human oversight, AI verification, operations, governance, and evidence preservation.
Nonfunctional requirements should be realistic enough to plan and meaningful enough to verify. Do not write vague quality claims that cannot influence architecture or testing.
Quality and trustworthiness requirements evidence under docs/requirements/nonfunctional_requirements.md.
Activity 4 — Define constraints¶
Create:
docs/requirements/constraints.md
Use template:
template-library/requirements/constraints.md
Constraints may include policy restrictions, data limitations, timeline limits, approved technologies, prohibited technologies, compliance requirements, integration boundaries, prohibited uses, operational limitations, educational constraints, and governance requirements.
For each constraint, identify its source, what boundary it imposes, what solutions it excludes, and what downstream stages must respect it.
Solution-boundary evidence under docs/requirements/constraints.md.
Activity 5 — Write use cases or user stories¶
Create:
docs/requirements/use_cases_or_user_stories.md
Use template:
template-library/requirements/use_cases_or_user_stories.md
Use cases or user stories should cover important stakeholder goals. Include alternate and exception paths where trust, evidence, failure, oversight, denied access, escalation, or auditability matters.
Do not only document happy paths. Intelligent systems are often risky at the boundary conditions.
Interaction and stakeholder-goal evidence under docs/requirements/use_cases_or_user_stories.md.
Activity 6 — Build traceability notes¶
Create:
docs/requirements/traceability_notes.md
Use template:
template-library/requirements/traceability_notes.md
Connect requirements to ES-101 source evidence, stakeholder needs, scope decisions, assumptions, success metrics, use cases or user stories, constraints, and verification expectations.
Traceability should be built as requirements are created. Do not defer it until the end.
Traceability evidence under docs/requirements/traceability_notes.md.
Activity 7 — Review the requirements package¶
Create:
docs/requirements/requirements_review.md
Use template:
template-library/requirements/requirements_review.md
Review the package for clarity, ambiguity, testability, traceability, scope alignment, stakeholder coverage, missing constraints, AI verification, operational implications, and governance implications.
Record findings, corrections, accepted risks, deferred issues, and questions that must be resolved before or during ES-103.
Review evidence under docs/requirements/requirements_review.md.
Activity 8 — Complete requirements readiness summary¶
Create:
docs/requirements/requirements_readiness_summary.md
Use template:
template-library/requirements/requirements_readiness_summary.md
Summarize completed artifacts, unresolved issues, major constraints, major planning risks, AI-related obligations, and readiness for ES-103.
This is the primary transition artifact from requirements into planning.
Transition evidence under docs/requirements/requirements_readiness_summary.md.
Recommended working order¶
requirements_overview.md
↓
functional_requirements.md
↓
nonfunctional_requirements.md
↓
constraints.md
↓
use_cases_or_user_stories.md
↓
traceability_notes.md
↓
requirements_review.md
↓
requirements_readiness_summary.md
AI assistance¶
Useful AI-assisted review prompts:
Identify ambiguous requirements in this file.
Which requirements appear to be design decisions rather than system obligations?
Which nonfunctional requirements are missing for a trustworthy intelligent system?
Check whether each requirement is traceable to ES-101 vision evidence.
Identify requirements that cannot yet be verified.
AI output is not requirements evidence until the engineering team reviews it, corrects it, and accepts responsibility for the final requirement set.
Do not write all requirements first and trace them later. That usually produces a traceability artifact that explains decisions after the fact instead of improving decisions while they are being made.
The best requirements activity is iterative. Each new artifact should expose weaknesses in earlier artifacts and push the team back toward clarification.