Loading…
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
Common mistakes
Powstik Guide
Records of two elicitation sessions with different stakeholders.
Steps
Template
| Session | Date | Stakeholder role | Method | Needs raised | |---------|------|------------------|--------|--------------| Draft requirements:
What gets sent back
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
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
Common mistakes
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
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
Common mistakes
Powstik Guide
An SRS review with two reviewers and resolved conflicts.
Steps
Template
| Reviewer | Role | |----------|------| | Issue | Found by | Resolution | |-------|----------|------------|
What gets sent back
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
You'll sign in first, then come straight back here.