A functional requirement specifies an operation an application must perform or enable an end user to perform. It describes what the application must do, not how its internals implement that behavior. Functional requirements help ensure that development produces the right application before design focuses on building it well. section 3.2 section 3.0
Write requirements as firm, observable statements using must or shall. Avoid weaker wording such as should or could, which makes the obligation unclear. Keep functional requirements separate from nonfunctional requirements, which impose constraints such as performance or platform requirements. section 3.2 section 3.9
A useful functional requirement identifies one or more of the following:
- An operation the application performs, such as storing book attributes or matching search strings without regard to case. section 3.2
- An operation a user can perform, such as adding books or searching for books by selected target attributes. section 3.2
- The data, categories, values, or rules that make the operation precise, such as required book attributes, permitted genres, or don’t-care search fields. section 3.2 section 3.8
From vague idea to testable requirements
“Build a more advanced book catalogue” is too vague to guide implementation or validation. Refine it into statements such as: “A librarian must be able to add, update, and delete books.” “A customer must be able to search by any number of target attributes.” “String matches during searches shall be case-insensitive.” “A customer must be able to specify don’t-care attributes.” These statements expose required actors, operations, data rules, and observable outcomes without prescribing internal implementation. section 3.1 section 3.8 section 3.7
Discover requirements by interviewing clients, observing current manual or legacy tasks, discussing alternatives with the development team, and using prototypes to elicit feedback. Maintain a tight communication loop because requirements may change during design and coding. section 3.4 section 3.9
Use cases add context by describing how an actor performs a sequence of actions to reach a goal. A description can record the goal, actors, preconditions, trigger, primary and alternate action sequences, postconditions, and applicable nonfunctional requirements. section 3.6 section 3.6.2
Collect the requirements and use cases in a functional specification written in clear, nontechnical language. Keep it external to the application: describe the problem, objectives, behavior, and validation criteria rather than internal design. Analyze the resulting requirements afterward; nouns can suggest classes, while verbs can suggest methods. section 3.7 section 3.9
Figure 3.2 A more advanced version of the book catalogue application. A librarian interacts with the book catalogue server to enter new books into the catalogue, update existing books, and remove outdated ones. A customer interacts with the server to search for books. The books are stored in a backend database.
Use the catalogue interaction diagram to distinguish user operations from application responsibilities and stored data. section 3.1
