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.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

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. 
Can i have the steps to write SRS document for my project
@venky1992, thank you for your question. Let me answer in a couple of ways. First, I don’t recall ever seeing SRS writing in terms of steps. One of the advantages of an SRS is its pigeonhole format, which can serve as prompts for writing each of the many topic sections an SRS typically includes.

Second, consider a different and I believe much more productive way to approach writing an SRS. Apply what I call the Problem Pyramid™, which involves six steps that need to be accomplished in sequence, accompanying each step with systematic disciplined ways to give confidence the step is defined accurately and adequately:

1. Identify the REAL problem, opportunity, or challenge that will provide REAL value when addressed appropriately. This is much harder than most people realize, which is why their projects turn out not to solve the right problem and thus fail to provide needed value.

2. Integral to getting the REAL problem right is identifying two measures of the problem, starting with the current measures that tell us it’s a problem.

3. The second measure is the goal measure(s) that tell us the problem has been solved, the opportunity taken, or the challenge met. Achieving the goal measure(s) is what provides REAL value.

4. Identify the causes of the REAL problem. These represent the as is (or current-state) process producing the current measures which tell us we have a problem.

5. Identify the REAL business requirements should be (or future-state) process deliverable _whats_ that when satisfied will reasonably achieve the goal measure(s) and thereby provide REAL value.

6. Design a product, system, or software way _how_ to satisfy the REAL business requirements deliverable _whats_ and document it in an SRS.

Excellent writeup on SRS, it is useful for me.