A functional requirement specifies an operation an application must perform or allow an end user to perform. It describes observable behavior rather than implementation, and uses strong wording such as “must” or “shall.” section 3.2 section 3.8
From a vague idea to requirements
For a book catalogue, “customers search for books” is too vague to guide development. More precise requirements state that a user must be able to add fiction books, cookbooks, and how-to books; a user must be able to search by target attributes; searches shall compare strings case-insensitively; and users must be able to mark attributes as don’t-care values. The requirements also specify the attributes and allowed values for each book type. section 3.1 section 3.2
Good functional requirements support several connected activities:
- Gather requirements by observing current tasks, interviewing clients, maintaining active communication, and using prototypes to expose needs and changes. section 3.5
- Connect requirements to use cases, which identify actors, goals, triggers, action sequences, alternate outcomes, and postconditions. section 3.7.2
- Record them in a functional specification alongside the problem statement, objectives, nonfunctional requirements, and use-case descriptions. section 3.8
- Analyze their nouns and verbs to form an initial set of application classes and member functions. section 3.10
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 and to update and remove existing books. 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 customer search behavior, librarian maintenance behavior, the server, and stored book data. section 3.1
