I once heard an young and not too experienced engineer comment that requirements specs and design documents shouldn’t be boring. They should read like a novel…be engaging…be interesting to read. Then I got a copy of his “War and Peace” version of his latest requirement specification and had to translate it into a test plan.
There wasn’t any clear indication anywhere in the document what should be tested because I did not know was truly required or was something that might be good to implement but is not going to be. On top of that, one of the sentences contained so many apparent requirements before the period at the end came calling, I was wondering if the entire subsystem design was in that one sentence.
Now that I have a few years, well, a few decades under my belt and I have had the fortune of learning the value of clear requirements. I know the power of a software requirement document written with each requirement written clearly and measurably, but…yes…boringly… with the almighty “shall” as a verb in the sentence. Not only does this help the tester to create a test plan, it also helps Training, Sales and Marketing too.
Let me explain. Let’s say you have the statement: The software shall contain a login screen. Very simple. Very boring… But, you can use this statement in the following way:
- Quality Assurance can create the following test: Verify the software contained a login screen.
- Training can start their training plans with: Login to the application as an…
- Sales can mention to customers that, due to a Login Screen, the application has a high level of information security.
- Marketing can refer in their literature to the high level of security as well.
All of this information can be assembled even before a line of code is written. And once each feature has been either approved or definitely implemented Sales and Marketing can start trumpeting their horn!
