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
  • 847

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,161