Do you ever get the uneasy feeling that no one is reading your software requirements specification? The reality is that the development team is probably busy on the last release and that the business stakeholders are busy doing their jobs in the business. What is a lonely Product Manager to do? How do you get people to read the specification? There are a couple of easy ways to know whether or not your spec is being looked at and to ensure that it really gets read.
1) Determine the number of changes requested in each section of the software requirements.
You might assume that you are brilliant if there are no changes (and maybe you are!). I prefer to assume that if I don’t see changes then no one has read that section. For a large number of requirements it can be difficult to get a good sense of which requirements may not have been reviewed. If you map out how many changes have actually been made to specific requirements you can get a very concrete measure of what sections are actively being read. A requirements management tool is very handy for this, but if you are using a Microsoft Word document, you can still use a diff utility (or the built in diff function) to see if there are requirements that have essentially never been changed. We work on very large projects with multiple development teams divided into functional areas, and using this method you can tell which development teams are really actively and regularly reviewing the document.
2) Get written signatures.
When you ask a group of stakeholders if anyone has any issues with the software requirements document, many times you will get silence. Silence is not approval. You could take the easy way out and move forward, but that won’t help you later when the software doesn’t meet the business needs. When you actually ask stakeholders to sign their name on paper all of a sudden some of them need a few more days to do a final review. For some reason there is a psychological component to physically signing your name to a document; use this to your advantage.
3) Tailor the requirements for the audience.
There is nothing more painful than having to read a list of hundreds or thousands of shall statements. That simply is not how anyone thinks, not even us analysts. Use requirements models that your stakeholders can identify with to make it more likely that they will read and understand what they are getting. Models that the business can readily understand are click-action-response diagrams, use cases and flow diagrams.
4) Get verbal and written commitment from people before a requirements review.
There is a principle of influence which says that people try to maintain consistency. If you call people and get their commitment to review the software requirements specification before a review meeting, you will get a much higher compliance rate. It is a pain, but it really works. Even better is if you can get commitment for people to send their issues to you before the meeting. You can then specifically call people who haven’t sent in their issues list. Remind them that eventually they will have to sign off in writing.
These are just a few of the techniques that we use to help ensure that the software requirements specification isn’t just a paperweight gathering dust on a shelf.
