Problem solve Get help with specific problems with your technologies, process and projects.

How to write a Software Requirements Specification (SRS) document

Knowing how to write requirements documentation is crucial when developing and tracking the completion of software. Expert Robin Goldsmith goes over how to write SRS documents and how to distinguish them in this expert response.

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.

This was last published in November 2009

Dig Deeper on Penetration Testing



Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

@ aniket1234, thank you for the kind words and additional blog cite. You can find many more of my articles by searching “Goldsmith” at the top of this article. The SearchSoftwareQuality editor determines which of my submissions are published and when, so hopefully she’s reading your comment and will act accordingly on some of my current submissions. 


Re: the cited SRS article. It seems to be from one of the several India-based test training organizations that provide valuable public service by publishing numerous articles on testing.  As happens so often in both testing and requirements communities, the article mainly emphasizes form rather than content issues. That is, clarity and consistency with objectives are both form issues. Requirements can pass both yet still be wrong—and too often are wrong. See my book, Discovering REAL Business Requirements for Software Project Success, or my seminar to learn more than “21 Ways to Evaluate Requirements Adequacy,” including many seldom-recognized ways to identify wrong or missing requirements content.