0

An SRS is a staple of any serious contract work, and it can be incredibly dull for those who've never had the misfortune of needing to read one through in one go.

I'm writing a series of document classes with LaTeX (markup language for profession-quality documents; see these questions and this answer on TeX.SE) and, in so doing, I need to define the core tenets and common logical structures evident through any reasonable SRS.

I have unfortunately never had the opportunity to participate in the creation of an SRS from scratch save a simplified, somewhat contrived example during college, so I don't think I know the breadth of what goes into a Software Requirements Specification (SRS). I do know it consists of at least the changelog and the requirements themselves, but beyond that... ?

What are the indispensable parts of the document that every SRS should have?

I'm still pretty new here, but I'm open to making this CW if Programmers.SE is all about this kind of stuff.

Community
  • 1
Sean Allred
  • 837
  • 6
  • 14
  • 4
    Too many [TLA](http://en.wikipedia.org/wiki/Three-letter_acronym)s - I assume this is about [Software requirements specification](http://en.wikipedia.org/wiki/Software_Requirements_Specification)s? – Dan Pichelman Jun 19 '13 at 01:10
  • Ha! Yes -- I'll edit that into my question for clarity. It's a bad thing when you don't even realize you are *using* an acronym anymore... :( – Sean Allred Jun 19 '13 at 11:06
  • @Dan - FWIW you are correct IMHO. First time I ever heard that acronym was in an interview. The earnest young interviewer asked what I would do if someone laid an SRS on my desk. My only previous SRS reference was as an automotive airbag ("Supplemental Restraint System"), which contains a small explosive device. WTF? Why would anyone lay an airbag on my desk as part of a software development job? I guess "leave the room and call security" wasn't the answer he was fishing for, but they hired me anyway. – Joe Ballard Jun 19 '13 at 20:35

1 Answers1

3

If you can find it, the old DOD-STD-2167A Software Requirements (SRS) Specification Data Item Description (DID) tells you what the DoD wanted in an SRS, and how they wanted it. This will give you a very good start.

From memory, the SRS DID calls for a (boilerplate) Scope section, a Referenced Documents section, the Requirements section(s), and the Requirements Traceability Matrix. That last usually traces software requirements back to system requirements, and includes at least perfunctory information FOR EACH INDIVIDUAL REQUIREMENT about how you plan to test the system to determine whether it does or does not meet that requirement. (These are usually just one word: Inspection, Demonstration, Test, Analysis.)

If you have beaucoup money to waste, you could buy the IEEE software standards. They basically boil down to "The contractor will deliver whatever the *bleep* he feels like, and call it an SRS."

The changelog is not absolutely critical, as you are going to be maintaining your SRS in some kind of configuration management system, preferably a Requirements Management System like DOORS. (You are a fool if you don't.)

It should go without saying that requirements and ONLY requirements go in the SRS. If it ain't a requirement, it don't belong in the SRS. Period.

John R. Strohm
  • 18,043
  • 5
  • 46
  • 56
  • [wiki](http://en.wikipedia.org/wiki/DOD-STD-2167A) and [PDF](http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf) (although the latter doesn't give me a sense of longevity.) – Sean Allred Jun 19 '13 at 19:55