I'm answering this questions in two parts because it is a question I am asked often, and it can be explained in variety of ways. That is, how to write a Software Requirements Specification (SRS) is the same regardless of what the SRS is for. I've discussed this previously, in fact in response to a question about how to write an SRS for a portal project, in this blog post.
Although many people think their difficulty is in writing the SRS, it's more likely their real difficulty is in getting the requirements right that must be met by the software product they design and document with an SRS. A far better question, and perhaps what these questioners actually meant to ask, would be, "How do I find out the requirements for a portal project or for a non-profit organization having three different databases which do not collaborate?"
Without purporting to know the specifics of their two individual situations, one starts by discovering the REAL, business requirements deliverable whats that provide value when met by the product/system/software how. You need to find out things such as:
- What is the portal for?
- What does it need to do that in fact provides value?
- What does the non-profit organization need to do that will provide value for it?
- What, taken together, from a business perspective if accomplished will reasonably provide that value?
- What information, from what sources, is needed to accomplish these things?
- Who needs to receive the information and in what formats and manners?
- What business rules, algorithms, formulas, and calculations must be applied?
- What quality factors almost must be met to provide the value?
Once you've identified what needs to be accomplished, then and only then s it worthwhile to worry about how to accomplish it -- a product/system/software whose design is described in an SRS.
This was first published in November 2009