A Template for Software Requirements

Requirements Management quotes

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

A Template for Software Requirements

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.

software requirements group
Articles Knowledge

Reviewing Requirements for Testability

Modern software development approaches like Agile and Scrum support a strong collaboration between all member of the software development team, software testers and business analysts included. Even if you don’t use a method like Behavior-Driven Development (BDD) or Specification by Example, checking the fact that you will be able to actually test your requirements is […]

Read More
Requirements Management Articles
Articles Knowledge

User Stories for Both Requirements and Testing

User stories are a technique taken from the agile development playbook that can easily be applied in traditional systems development and maintenance. User stories help you document needs in a structured way, from the users’ perspective. They’re a good basis for test cases, so as to support integrated requirements management and testing. In this article, […]

Read More
Requirements Management Articles
Articles Knowledge

Understanding System Analysis Models

This article is an extract of the “Complete Systems Analysis” written by James and Suzanne Robertson. It explains the basics of analysis models and emphasize that the important thing to remember is that modeling tools are complementary. Each shows one aspect of the system. Together, they make a complete working model of the system.

Read More

Copyright © 2009-2021 Martinig & Associates