A free "real world" software requirements specification

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.

Related software requirements specification and Use Case articles

Here are links to a few articles related to software requirements specifications and UML Use Cases:

thanks

thanks

Any Chance of the LaTeX source?

Is there any chance of you posting the LaTeX document you used to generate this document?

More information?

I've received this request a few times, but I guess I don't understand how that would be helpful, at least in the context of learning about use cases and requirements? Any more info on this request (from you or anyone else) might help me understand that better.

From my perspective I've had some people plagiarize my work over the last year or two, so I've become a little leery about sharing this. I normally try to share everything I can, but I've pulled back a little on this lately.

LaTeX Source

The main thing was your formatting and layout in LaTeX, I honestly dont care too much about the actual content, I've written quite a few SRS before, but I'm moving away from using MS Word, towards using LaTeX, and since I'm still learning LaTeX I stumbled across your pages about LaTeX SRS. I was just hoping to get a template I guess to work from.

I noticed you have a few other LaTeX pages with source, I was just wondering if you could do the same thing for this one.

Thanks for the feedback

I'll be glad to share a subset of this, though I don't know if I'll be able to get to it soon though. I am currently packing all my things, and I start the long drive to Alaska next week. If I can get to it before I leave, I'll be glad to share what I can.

I think other people think what I do is crazy, but I actually write my specs using a Wiki-like markup language, then convert that to LaTeX, then generate the PDFs and HTML from that. Each Use Case I write is also contained in a separate file, and I include them into a master file.

Although others think this is crazy, I love it, because I can color-code my releases, control the page headers and footers, write in the margins, and  in general completely control the PDF layout, where Word tends to drive me nuts.

Again, I'll try to get to this before I leave, but I'm sorry, I can't make any promises here.

Post new comment

The content of this field is kept private and will not be shown publicly.