To be or not to be; the reasons for and content of a requirement specification.
Earlier this year DVel had a breakfast seminar about start-up of measurement system projects. I had the opportunity to hold a presentation about requirement specifications, which in my eyes are very important. I think most engineers are aware of that, but many projects that I have been involved in have ended up in discussions and irritations because of lack of information or misunderstandings. A collection of well written requirements would have avoided that.
Avoid discussion about what was supposed to be done
A good requirement specification must therefore be developed to avoid getting into the state of too many discussions and questioning during the project. Particularly not at the time for delivery. There will, of course, most often be some changes but the goal is to make sure they are not too many. This is especially cumbersome in a fixed price project, both for the client and the supplier, because there will be a discussion about what was supposed to be included. The client will end up spending more money or not getting all functionality desired.
How to get started
So, how to ‘produce’ this document? There are some ‘simple’ ways to start with. Involve all responsible stakeholders. Look at the requirement specification for an earlier project or a similar project and ask people involved. To search the internet is always a good source to find information, you never know what you will find. And, use your network for help. They will probably not spend too much time on your project, but guide you in a good direction.
Types of requirements
Below is a list of some good examples of what a requirement specification shall contain and define.
- An informative section of how the result of the project shall be used. Even with a good requirement specification one must understand the master plan.
- Well specified requirements to minimize misunderstandings.
- Specifications of components that are required to be used.
- User interface (graphical and mechanical).
- Flow charts of how it shall behave in different scenarios
- IT specifications, if it shall be connected to a database, Internet etc.
- Quality Assurance needs. If there is a QA department, as in many MedTech companies, they must be involved early in the project.
- Responsibility areas for the people involved in the project.
Another important thing is to use the word ‘Shall’ in the requirements. Requirements that are not mandatory will probably not show up in the delivery. Why spend time on something that is not needed?
And finally, there is also a simple word, SMART, on how requirements should be.
S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-bound
You will probably end up with a rather good requirement specification if you work like this, but as with all things experience comes into play when finding that right level of a specification. There is a lot more to be said and discussed about this subject. We look forward to discussing it further and to share our experience, either in this blog or as dedicated seminars. Or around a coffee table.
By Thomas Johansson