A software requirement states what an application must do or allow users to do. Requirements guide the choice of application classes and distinguish building the right application from building it well. section 1.5 section 3.0
Good requirements should be:
- Clear and written in nontechnical, jargon-free language. section 3.4
- Consistent and free from contradictions. section 3.4
- Correct, complete, realistic, and verifiable through testing. section 3.4
- Traceable to application functionality or constraints, with every functionality or constraint justified by a requirement. section 3.4
Gather requirements through repeated interviews, clarifying questions, observation of current work, team discussion, and prototypes. Capture both stated requirements and implied requirements, then expect refinement until requirements stabilize. Because requirements can change during and after development, encapsulate likely change points rather than spreading assumptions through the application. section 3.5 section 3.5.1 section 3.5.2
Automating a library catalogue
A card catalogue requires librarians to maintain cards by title, author, and subject, while customers search manually. Interview librarians and customers, observe their work, and prototype improved searches before deciding the application’s functional and nonfunctional requirements. The example shows why users may suggest only incremental improvements and why observation and prototypes can reveal better requirements. section 3.5.1
Figure 3.3 To automate a library’s old-fashioned card catalogue with a software application, you must first get the requirements to develop the right application.
Use the library catalogue figure to connect requirements discovery with the goal of automating a manual process. section 3.5.1
