Software Requirements Specification Is King - Part 1
One of the problems that Software Project Managers encounter is the struggle with the team over product development documentation. Documents, documents, documents. Theory says that the development of the SW product must be accompanied by a series of documents: Market Requirements Specification, Software Requirements Specification (SRS, SW Architecture, SW Design, SW Detailed Design, test documentation, Release... On and on.
People usually hate to write documents. They like to do their job, be it market research, SW design, SE architecture, etc. But they hate to sit down and put all their knowledge on paper. And on top of that, there are the theorists who claim that documenting is a bad idea anyway (especially if they have to do it :). And to make matters even worse, even if they finally agree (or are forced) to write one of these documents, it's usually bad quality because they are not skilled in writing such documents. This surely does not add to the popularity of generating and maintaining documentation.
In this post, I don't intend to go into this debate about: does a SW product need documentation? This will require a rather elaborate discussion. To be clear, I do have an opinion - I think documentation is very important as long as it's done wisely, but this is for another discussion. What I want to cover here is the following rule that I strongly believe in:
If nothing else, at least maintain and use a decent Requirements Specification.
The Software Requirements Specification (SRS) is the most important and useful of the various SW development documents. It tells everybody, and I mean everybody, what this piece of SW should be doing. If you think for a moment, I think you will be surprised when you realize the long list of project stakeholders that will find the SRS useful and beneficial (and that's why I say everybody). Here is a list (let me know if I forgot anybody):
- Product Manager - needs to be able to tell potential customers what the product does
- Sales Manager - needs to be able to tell potential customers what the product does
- SW Architect - uses it to develop the architecture.
- SW Designer - uses it to design the product.
- Programmer - uses it to make sure his implementation provides the correct features/behavior
- QA will test against the SRS
- Customer will know what to expect and what to test (acceptance testing)
- Technical Writer will use it as the reference for the user's documentation (User's Guide, User's Manual, etc.).
- Executives will use it for various purposes (such as in case of dispute, especially with the customer).
Without a SRS, every stakeholder has their own picture in their mind of what this product should do and how it should behave. How many times have you seen the bewildered Product Manager asking why is this feature different form what we agreed? Or the angry customer asking what is this new thing that was never mentioned to us? What does it do? How do we use it? Why do we need it? Did you ask us if we needed it? And where is this important feature that we did want to have and you agreed to provide? Or the angry engineer who says to the QA tester "Why does this test fail? The implementation is correct. You don't know how to write tests". And the tester answering "according to my information, this should behave differently. My test is correct". And who is right? If it's not written down, who knows?
No other document has this power of putting all the stakeholders on the same page like the SRS. So, please, if you don't write any other document, please, at least, write a Requirements Specification.
I will continue in the next post and provide some useful suggestions to make the chore of writing and maintaining the SRS easier. I will also suggest some rules for maintaining the SRS and how to effectively use it. I will just give you a little heads-up here as a teaser:
If you don't intend to use it seriously, don't bother to write it.
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
No comments:
Post a Comment