Milestone map
Milestone map
3 milestones
Elicit and Document Stakeholder Requirements
1–2 weeks (3–4 hrs/week)
Conduct structured requirements elicitation for a software or system project. Use ≥2 elicitation techniques — interviews, workshops, document analysis, observation, or prototyping — and produce raw requirements notes. Then classify each requirement as functional (what the system shall do) or non-functional (performance, security, reliability, usability constraints). Document ≥15 requirements from ≥3 stakeholder roles. A requirements specification is only as good as the elicitation process behind it — if you only ask one person one question, you will produce an incomplete spec.
Proof required
Submit your elicitation record (meeting notes, workshop outputs, or observation logs for ≥2 sessions with ≥2 different stakeholder roles) and a classified requirements list (≥15 requirements, each labelled functional or non-functional).
What gets checked
- ≥2 elicitation techniques are documented — not just one interview
- ≥3 stakeholder roles are represented — not all requirements from a single viewpoint
- Requirements are classified as functional or non-functional — not all treated identically
Common mistakes
- Elicitation with only one stakeholder role — functional requirements from the system's primary user will miss constraints that come from operators, administrators, and maintainers
- Non-functional requirements stated as vague aspirations ('the system should be fast') — every non-functional requirement must have a measurable threshold
Powstik Guide
Records of two elicitation sessions with different stakeholders.
Steps
- Pick two stakeholder groups.
- Run an interview, workshop or observation.
- Record needs in their words.
- Turn needs into draft requirements.
Template
| Session | Date | Stakeholder role | Method | Needs raised | |---------|------|------------------|--------|--------------| Draft requirements:
What gets sent back
- Only one stakeholder group.
- No session records.
- Requirements invented without input.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm ≥2 elicitation techniques are documented with evidence (notes, outputs, or observation log).
- Confirm ≥3 stakeholder roles are represented — not all requirements from one person.
- Confirm all non-functional requirements have measurable thresholds — flag any stated as aspirations.
You'll sign in first, then come straight back here.
Write the Software Requirements Specification
2–3 weeks (3–4 hrs/week)
From the elicited and classified requirements in M1, write a complete Software Requirements Specification (SRS) following IEEE 830 or equivalent structured format. Each functional requirement uses 'The system shall...' language and is uniquely numbered (e.g. FR-001). Each non-functional requirement names the threshold (e.g. 'The system shall respond to 95% of user requests within 2 seconds under peak load of 500 concurrent users'). The document includes: scope, constraints, assumptions, system context diagram, and requirement dependencies or conflicts. Write ≥20 requirements in total.
Proof required
Submit your SRS document (≥20 numbered requirements in 'shall' language, with functional/non-functional classification, measurable thresholds on all non-functional requirements, a scope section, and a system context diagram).
What gets checked
- Every functional requirement uses 'The system shall...' with a unique number — not passive or aspirational language
- Every non-functional requirement has a measurable threshold — not 'the system should be fast'
- A system context diagram is included showing the boundary of the system and its external actors/interfaces
Common mistakes
- Non-functional requirements without thresholds — 'shall be reliable' is not a requirement; 'shall achieve 99.5% uptime over any 30-day period' is
- No system context diagram — the boundary of the system (what's in scope vs. out of scope) is one of the most important things a requirements specification defines and it is communicated most clearly with a diagram, not prose
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm every functional requirement uses 'The system shall...' language with a unique identifier.
- Confirm every non-functional requirement has a quantified threshold — flag any without one.
- Confirm a system context diagram is present and shows the system boundary and ≥2 external actors.
You'll sign in first, then come straight back here.
Review the SRS with Stakeholders and Resolve Conflicts
1–2 weeks (2–3 hrs/week)
Conduct a structured requirements review with ≥2 stakeholders from different roles. Apply a review checklist: completeness (all use cases covered?), consistency (no conflicting requirements?), testability (can each requirement be verified?), feasibility (are constraints achievable?). Document conflicts found, resolution decisions, and the final agreed requirement count. A requirements specification that has not been reviewed is a hypothesis, not a specification — the review is what converts it.
Proof required
Submit your review record: ≥2 reviewers (names and roles), review checklist completed with findings, ≥3 issues or conflicts identified and resolved, and a brief statement of the agreed final specification scope.
What gets checked
- ≥2 reviewers from different stakeholder roles — not two reviewers with the same background
- ≥3 issues or conflicts are documented with resolution decisions — a review with zero findings is not credible for a ≥20-requirement spec
- Final specification scope is agreed and stated — not left open
Common mistakes
- A review that produces zero findings — all real requirements specifications have conflicts or ambiguities; a zero-finding review means either the reviewers did not engage critically or the review was not thorough
- Resolving conflicts by deleting the requirement — conflicts must be resolved by negotiation and a documented decision, not by eliminating one side of the conflict
Powstik Guide
An SRS review with two reviewers and resolved conflicts.
Steps
- Send the SRS with a checklist.
- Hold the review with two or more people.
- Log at least three issues.
- Record how each was resolved.
Template
| Reviewer | Role | |----------|------| | Issue | Found by | Resolution | |-------|----------|------------|
What gets sent back
- Fewer than two reviewers.
- Fewer than three issues.
- Issues unresolved.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Engineering Design Triad check: M1–M3 together produce a design artifact (SRS with numbered requirements and context diagram), an analysis artifact (elicitation record + review checklist findings), and a documentation artifact (review record with conflict resolutions) — confirm all three types are present.
- Confirm ≥2 reviewers from different stakeholder roles participated.
- Confirm ≥3 issues or conflicts are documented with resolution decisions — flag a zero-finding review as not credible.
- Confirm final specification scope is agreed and stated.
- The Proof Accessibility Rule applies — IREB CPRE free basics, draw.io (free), Volere free template, and Karl Wiegers free checklists are all accessible without commercial licence.
You'll sign in first, then come straight back here.