When you are gathering and documenting software requirements, it is not always easy to remember all the dimension that should be included in this activity. The book “Mastering the Requirements Process” proposes a template that should help you in this activity.
Project Drivers – reasons and motivators for the project
1 The Purpose of the Project – the reason for making the investment in building the product and the business advantage that you want to achieve by doing so
2 The Client, the Customer, and Other Stakeholders – the people with an interest in or an influence on the product
3 Users of the Product – the intended end users, and how they affect the product’s usability
Project Constraints – the restrictions on the project and the product
4 Requirements Constraints – the limitations on the project, and the restrictions on the design of the product
5 Naming Conventions and Definitions – the vocabulary of the project
6 Relevant Facts and Assumptions – outside influences that make some difference to this product, or assumptions that the developers are making
Functional Requirements – the functionality of the product
7 The Scope of the Work – the business area or domain under study
8 The Scope of the Product – a definition of the intended product boundaries and the product’s connections to adjacent systems
9 Functional and Data Requirements – the things the product must do and the data manipulated by the functions
Non-functional Requirements – the product’s qualities
10 Look and Feel Requirements – the intended appearance
11 Usability and Humanity Requirements – what the product has to be if it is to be successfully used by its intended audience
12 Performance Requirements – how fast, big, accurate, safe, reliable, robust, scalable, and long-lasting, and what capacity
13 Operational and Environmental Requirements – the product’s intended operating environment
14 Maintainability and Support Requirements – how changeable the product must be and what support is needed
15 Security Requirements – the security, confidentiality, and integrity of the product
16 Cultural Requirements – human and sociological factors
17 Legal Requirements – conformance to applicable laws
Project Issues – issues relevant to the project that builds the product
18 Open Issues – as yet unresolved issues with a possible bearing on the success of the product
19 Off-the-Shelf Solutions – ready-made components that might be used instead of building something from scratch
20 New Problems – problems caused by the introduction of the new product
21 Tasks – things to be done to bring the product into production
22 Migration to the New Product – tasks to convert from existing systems
23 Risks – the risks that the project is most likely to incur
24 Costs – early estimates of the cost or effort needed to build the product
25 User Documentation – the plan for building the user instructions and documentation
26 Waiting Room – requirements that might be included in future releases of the product
27 Ideas for Solutions – design ideas that we do not want to lose
Source: “Mastering the Requirements Process” (3rd edition), Suzanne Robertson and James Robertson, Addison-Wesley
Templates and documentation are not so much in favor now as the the Agile Manifesto prefers “working software over comprehensive documentation”, but they are important to formalize the knowledge. The trouble is that people often view templates as something that should be completely filled and not as a guideline about the aspect of a problem that could be considered according to the context. The fact is that Suzanne Robertson and James Robertson precise in their book that you don’t have to fill every items of this template, this is just a list of elements that could be useful to you when you have to formalize requirements for a software development project.
One thought on “A Template for Software Requirements”
Comments are closed.