Session 3.5 - Requirements Fundamentals
Chapter 6: Defining the Requirements | Duration: 1 hr
Learning Objectives
By the end of this session, you will be able to:
- Define requirements and their role in TSPi
- Explain why the requirements process matters more than the document
- List characteristics of good requirements
- Describe the structure of an SRS (example outline)
Introduction
Chapter 6 highlights that requirements development is about understanding needs and reaching agreement, not just producing an SRS. Even with provided need statements, teams must validate scope and clarify details.
What Are Requirements?
Requirements capture what the product must do (functional) and how well it must do it (non-functional/quality attributes), plus constraints and external interfaces.
Why They Matter
- They anchor design, planning, and testing.
- Agreement on scope reduces churn and conflict.
- Quality of requirements drives downstream quality.
Characteristics of Good Requirements
| Characteristic | Description |
|---|---|
| Clear & Unambiguous | Single interpretation; avoids vague terms. |
| Testable/Verifiable | Can be demonstrated through inspection, test, or analysis. |
| Feasible | Achievable within constraints. |
| Necessary | Traces to a user need; not “gold plating.” |
| Consistent | No conflicts with other requirements. |
| Prioritized | Enables staged delivery across cycles. |
SRS Outline (Example)
Chapter 6 provides an outline example; key sections often include:
- Introduction and scope
- Overall description and constraints
- Functional requirements
- Non-functional requirements (performance, usability, reliability, etc.)
- External interfaces
- Appendices (glossary, references)
Objective: reach agreement among team and instructor on what will be built.
Summary
- Requirements define what and how well; they guide design, planning, and test.
- The process of reaching agreement is more important than the document alone.
- Good requirements are clear, testable, feasible, necessary, consistent, prioritized.
- An SRS organizes the agreed scope; use it to baseline and manage change.