A software requirement specifies what an application must do, allow users to do, or satisfy as a quality or constraint. Good design begins by acquiring and analyzing requirements so the result is the right application, not merely a well-built one. section 1.5 section 3.0
Treat requirements as an evolving engineering input:
- Gather them through repeated client interviews, clarifying questions, observation of current work, and collaboration with domain stakeholders. section 3.4
- Separate functional requirements from nonfunctional requirements, and distinguish explicitly stated needs from implications needed to automate the domain correctly. section 3.0 section 3.4.2
- Analyze the results to derive an initial set of classes, then expect iteration, backtracking, and change rather than a single final design pass. section 1.5 section 2.3
- Encapsulate areas likely to change, because requirements may change during development or after release and otherwise spread modifications through the application. section 2.2 section 3.4.2
Book catalogue requirements
A catalogue must let users add fiction books with titles and author names, then search using any number of attributes. Title and author matches are case-insensitive; wildcard attributes match every book by default; remaining attributes match exactly. These precise rules provide behavior that can be analyzed into an initial design. section 2.3
Explore the requirements timeline, including the distinction between stated and implied requirements and the point at which requirements are expected to stabilize. section 3.4.2
