On (software) requirements
As a regular reader of reddit’s programming section I tend to be amazed about the number of people who seem to have something against requirements.
Wikipedia defines a requirement as follows:
In engineering, a requirement is a singular documented need of what a particular product or service should be or do. [...] . It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.
In the years that I have now spent in software engineering I have seen many different approaches; from classic waterfalls, to the currently hip Scrum model.
No matter which approach you take you do need to know a set of requirements before you actually can start doing anything, including gathering the requirements.
- What is the purpose of this project.
- What is the scope of this project.
- Who are the stakeholders of this project.
- What are the constraints of this project.
- What are the risks of this project.
Purpose
This is a short, quantified statement of what the resulting product should do and what it means for your business. This simple statement should make clear why the company is justifying the investment in the product and will help keep focus while gathering requirements.
Scope
The scope of the work is defined by the business area affected by the installation of the product (the roll-out). You need to understand these areas in order to properly specify the appropriate product.
Stakeholders
The stakeholders are the people with an interest in your product; the customer who requested the product, the users who will be using the product and all the other people with knowledge needed to gather all the requirements for the product.
Constraints
No product can be made with infinite budgets, time or technology; these aspects create the constraints in which the project should create the product.
Risks
Every product brings along risks, these should be clear and understood before continuing.
Go / No-Go
All of the above result in a document which can be used at a project blastoff / kickoff to determine if the project has any chance in succeeding at all.
Gathering requirements
In order to understand what is actually needed from a project you, after getting a go, need to gather all relevant functional and non-functional requirements.
For many projects this can be done iteratively, often you will find a requirement only by already doing some design or development work, but nontheless they should all be documented else you will always end up with discussions and questions about some aspect of the product after a lot of work, time and money has been spent.
When you are dealing with outsourcing (which I do as part of my current job) you should always strive to have as many requirements defined as possible in order (for both parties) to have a clear understanding what work should be done and what the ultimate goal of a project is.
Volere
In order to get more organized in this area I started to study up on requirements processes and have selected the Volere requirements process as a basis for my own work. The process is described in full in the book Mastering the Requirements process.
Now that the requirements process is a much larger part of my daily work I think it would be a good idea to devote a series of articles on this process and to show how I put a personal spin on the Volere process itself.
It should be clear that I am a great proponent of software requirements, if done appropriately within the context of a company and project; defining all requirements up front in a Scrum process is not a good choice as is not defining enough in an outsourcing process.