Requirement Specification
This chapter covers what system design means and how to turn stakeholder needs into requirements, using a content management system, HopPress, as the running example: identifying stakeholders, writing and prioritizing functional requirements, and introducing non-functional requirements, user stories, and use cases.
After reading this chapter, you should be able to:
- Explain what system design means and why design decisions continue throughout software development, not only at the start
- Describe a content management system and explain how HopPress narrows WordPress’s feature set to a small case study
- Identify a system’s stakeholders, recognize users as the stakeholders who operate the system, and identify outside systems it interacts with, along with the needs they bring and the requirements those needs produce
- Turn a stakeholder need into an explicit, testable functional requirement
- Prioritize and scope functional requirements.
- Distinguish functional requirements from non-functional requirements (system quality attributes and system constraints)
- Write a user story with acceptance criteria, and a use case with a main path and its alternatives
- Trace the history of requirements engineering and explain why AI assistance does not remove human responsibility for requirements and design decisions
Sections
- What System Design Does
- A Content Management System
- Stakeholders, Users, and Outside Systems
- From Needs to Functional Requirements
- Resolving Conflicting Requirements
- Priority and Scope
- Non-Functional Requirements
- HopPress’s Initial-Release Requirements
- User Stories
- Use Cases
- Requirements Engineering