Software Requirements Specification
6 weeks · 0 milestones
Produce a Software Requirements Specification (SRS) for a real or realistic software system using IEEE 830 or an equivalent structured format. The SRS must cover: functional requirements (at least 15 numbered, testable requirements with input, output, and boundary conditions), non-functional requirements (performance, security, availability, maintainability — each with a measurable acceptance criterion), assumptions and constraints documented explicitly, and use-case or user-story mapping to each requirement. The system described must be real or realistic enough that the requirements can be verified against it. Proof artifacts: the SRS document (design artifact) and a review record in which a software engineer challenges at least 3 requirements for completeness or consistency — with your written responses (documentation artifact). Accessible: no special software required — the SRS is a document artifact. Verification: a software engineer or systems architect who challenges 'this requirement is ambiguous — how would you test it?' for at least 3 requirements before endorsing. Generic fictional systems are not accepted; the reviewer must be able to ask grounding questions about real constraints.
Milestone map
Milestone map
3 milestones
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