Software Requirements Specification Is King - Part 2
In Part 1, I explained why the Software Requirements Specification (SRS) is the most critical and valuable product document. In this part - Part 2, I will provide some guidelines, suggestions, tips, etc. that Project Managers need to know in order to make the SRS experience good and beneficial.
We will start where I left off in Part 1:
If you don't intend to use it seriously, don't bother to write it.
This is actually applicable to all project and product related documents. So many project teams write so many documents (sometimes even reviewing and approving them) only to put them in the drawer and forget them forever. What's that good for? A frustrating and boring task, expanding resources with no benefit. So, don't bother.
Those of you who have seen a well written SRS know that it's not a trivial undertaking at all. Writing a high-quality SRS is very demanding, both in quality and quantity. This is one of the main reasons why it's often hard to get the team to write it. I have found in my experience that you - the PM - can make things easier if you and the team follow some simple rules.
- Substance is more important than form. In the beginning, don't worry too much about the appearance and format. Just make sure that the info is there. Worry about looks later. In fact it will probably be best to get a tech writer for that.
- Something is better than nothing. Trying to write a full, complete, comprehensive spec in the first shot is discouraging. It's a very large task. Encourage your team to start with something. Start small and add as you go.
These 2 principles will allow the team to start with a relatively small effort and get something started. The team will routinely add and improve and over time the document will be high quality.
Now we want to cover some important principles for the contents of the SRS. I will not cover this material here. There are tons of books out there and I don't need to repeat that. No added value. But I do want to recommend that you take a look at Scott Sehlhorst's article: Big Ten Rules - Writing Correct Requirements. This is a very good review of the characteristics of good requirements. It is probably more than you want to know or do for starters. But as you improve the quality of your SRS, this is certainly something that you should look at. The only thing that I want to add here is: if you start the SRS small, as I recommend, then, IMHO, the most important principle in Scott's blog above is actually the last one - correct. The important point here is: errors are unacceptable. They cause more damage than if there was no SRS in the first place. So scrutinize the SRS very carefully for correctness. Worry about the other rules later.
This is it for now. I covered some principles for generating the SRS. Sometime in the future (sooner than later, if there is interest), I will cover the principles for using the SRS.
Let me know what you think.
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No comments:
Post a Comment