Creating a Software Requirements Specification

Every software project needs a really good software requirements specification if it’s going to succeed.

But it takes a lot of practice to write those specifications, and it's not easy.

We're going to take a look at a simple approach anybody can use to write solid specifications and get their project completed.

All you're really doing is communicating what you need to the development team - it doesn't really matter how you do it, the format, what it looks like or how you deliver it.

As long as you communicate it well, that's what we're aiming for.

It's not easy to do, but there is a simple mentality you can take that will help a lot.

First, you want to make sure you put in as much detail as possible. You can't have too much detail.

Repeating yourself a few times or putting in some unnecessary details wastes a tiny little bit of space on usually, a virtual document.

Forgetting something is a big expensive mess.

Don't hold back, try to get as much detail as you can.

Also, imagine that the reader, the developer is coming into this project with zero knowledge. Explain everything, no matter how rudimentary or obvious it seems, get it down on paper.

Use lots of words, don't try to explain everything short and sweet. The software requirements specification is the last place you want to be concise.

You have to think of this as a brainstorming exercise.

People think that when you write a software requirements specification you have to know exactly what's going on, you've got everything in your head and you're just writing it down.

But it doesn't really work like that. Writing requirements is a brainstorming process.

Let's Take a Look at an Example

A client approaches a developer and says, I've got a great idea for a weight loss app and here are the requirements.

The first requirement says, "users can see metrics about their workouts."

Sounds good right? The client is probably thinking there will be all kinds of metrics and graphs everywhere, the user can see how their workout is going and how much weight they're losing.

On the other hand to the developer, this doesn't really mean anything. What metrics?

Already we can just add words. If we add "logged in" - now the requirement is "logged in user can see metrics about their workouts."

Not very useful at this stage but it's getting somewhere. We can add more details about the metrics and what the user can see, "logged in user can see a progress chart showing their weight loss."

Now we know the user is logged in, we've got a specific metric in mind and we're also clear on how we're going to show this metric to the user in the form of a chart.

We can expand on this, "logged in user can see progress chart showing their weight loss, the chart can show the user's weight loss by day, week or month."

Now, this is getting interesting, we're drilling down on one feature.

It's okay to repeat yourself, you want the developer to be crystal clear.

Goals

The main goal of a software requirements specification is to help provide a realistic foundation for estimating costs, risks and schedules.

When used properly software requirements can help prevent software project failure.

Most companies survive the pain of cost and schedule overruns. However, 17% of IT projects go so bad that they can threaten the very existence of the company - McKinsey/Oxford study.

A good software requirements specification establishes the fundamentals for an agreement between the client and the developer on how the software should function.

The specific goals of a software requirements specification are, describing the scope of work, providing a solid reference to the developers and to provide a framework for testing primary and secondary use cases.

Ultimately the developer needs to have a clear and thorough understanding of what you're trying to achieve. The best way to achieve this is through detailed and ongoing communication throughout the development process.