A free "real world" software requirements specification

By Alvin Alexander. Last updated: June 4, 2016

Last night I ran across a software requirements specification that I meant to share out here a long time ago, but unfortunately I never did. I created this software requirements specification for one of my customers, and they kindly gave me permission to publish this document out here (after I took out a few things specific to their business).

So -- to kick off the sharing for today -- here's a 92-page example software requirements specification that I wrote about five years ago (PDF). (If you prefer HTML, there is a link to the HTML version of this software requirements specification below.) As you'll see, we primarily tried to capture the behavior of the system in a UML Use Case format, so you'll find many example use cases, written to the best of my abilities five years ago.

Example software requirements specification - background

Here are a few notes which may help you better understand this software requirements specification:

This phase of development was a small part of a much larger overall effort. We were creating a new software system that would be used both by (a) employees and (b) customers, and in this phase we were trying to determine how to let customers access this new software, including handling user logins and permissions (access control). Like many businesses I've worked with, this customer had over the years created several different ways to let customers access their software system, and we were trying to merge this different systems into one system that would work for all parties.

As you'll see right away, this document is labeled "Version 6.1", and yes, we really did re-draft this document 6.1 times (the ".1" part was just some minor cleanup, and was intended to be a joke at the time, because we all knew how much time we put into re-hashing these items).

There was a lot of disagreement at this time as to whether we should even worry about this functionality at this time.

As this customer (the business people, a team of six domain experts) and my company (the developers) became more comfortable with each other, our specifications became smaller and smaller. This was one of the last "large" specifications. All of the documents after this one switched to a much lighter format, and were typically 10 to 30 pages long. (The newer documents still primarily used use cases, but our use case format became much lighter.)

I changed all instances of the customer name in the document to "ACME", and changed all references to my company name to "Consultant".

This document is color-coded to show changes between different versions. The colors are a little bright to look at in the PDF, but they printed much better.

HTML version of this software requirements specification

This requirements specification document was written in LaTeX, and was generated into a PDF with pdflatex. A cool thing about LaTeX is that you can generate output in different formats, so even though the styling is poor (thanks mostly to me), here's a link to the HTML version of this software requirements specification.

Comments

I hope this example software requirements specification can serve as a good example of what to do -- and what not to do -- in a requirements specification document. By that, I mean that this document is probably full of good and useful Use Case examples, but these Use Cases are also "heavy" -- very detail-oriented, and following a Use Case template. After talking with the domain experts after this particular phase of the project, this was the last time I used this template approach. I think you can learn from seeing both good and bad use case examples, so here's all of my dirty laundry from this particular project.

As usual, I welcome any constructive comments or questions. Just leave a note in the comments section below, and I'll be glad to reply.