How to know when a software requirements specification process is done

By Alvin Alexander. Last updated: May 9, 2018

Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

How I know when the software requirements specification is really complete

As a business analyst, I'm lucky to have trained myself in the techniques of Function Point Analysis (FPA). Right away, FPA helped clarify the definition of a UML Use Case for me, and then later on, when I became really comfortable with FPA, I realized that it also helps me understand when a given software requirements specification is "feature complete".

By this, I mean that when a customer comes to me and gives me a 10,000-foot overview of what they want, and we follow that initial meeting with some requirements gathering meetings, I know that I have all the requirements for the problem very simply:

I know the requirements process is complete when I can accurately count the Function Points.

Missing functionality in the requirements specification process

Before understanding FPA I never felt 100% certain that a software requirements specification was complete. I always had this nagging feeling that I might have missed something, sometimes something obvious, other times just a nagging feeling of something small, but still important.

But now, understanding FPA, I can feel very confident that my software requirements are complete, because if I can't count the function points for the current set of use cases, I know that something is missing, and beyond that, I know where they are missing. As you can imagine, that's a terrific feeling.

So, if you're a business analyst and you don't know what Function Point Analysis (FPA) is, I strongly recommend asking your company for training (it's pretty hard to learn on your own), but if your organization won't go for that, at least ask them to pay for a book for you. Here's the best FPA book I know:

Function Point Analysis (by "the two David's")

Update: Better yet, to help you get started, here's a link to my very popular, free Function Point Analysis tutorial (FPA tutorial).

FPA secrets to identifying missing functionality

Beyond that simple FPA "secret", there are several FPA "tricks" that can be used to find missing functionality.

(Sorry, if you don't know FPA, the following paragraphs may not make much sense. But at the moment I'm not going to make any effort to write these in plain english, because I think you need to have a basic understanding of FPA to understand what I'm about to write anyway.)

Verify that all ILFs are being maintained

The first FPA trick to know if you're missing functionality is to verify that all ILFs are being maintained. By that, I mean all the fields of all the ILFs. If you have fields that aren't being maintained in your ILFs, you're very likely missing functionality.

Are there three or more EI's for each ILF?

The second FPA trick is that for most applications in the world, you're probably going to have at least three EI's for each ILF. That's because you usually have the normal CRUD screens, which include processes like Add, Update, and Delete, which are EI's. Unless the data you've defined as being an ILF is not being maintained within the boundary of your application for some reason -- which is really a contradiction in terms -- you're going to want this functionality.

More importantly, if for some reason you don't have three EI's for each ILF, at least you've gone through this process, and you can explain why you don't have three EI's. And understanding this part is more important than anything else.