How do I write a Software Requirements Specification (SRS) for a non-profit organization that has three different databases, none of which collaborate?
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.
Dig deeper on Penetration Testing
Related Q&A from Robin F. Goldsmith
Requirements management and the requirements process are sometimes used to mean the same thing, but customers should be aware that there are ...continue reading
To prevent feature creep, product requirements should satisfy the actual business requirements. Creep can occur when product requirements are ...continue reading
Testers often complain that software requirements specifications are too vague, but verbose requirements can have the negative impact of being so ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.