Knowing when software requirements are complete

If you're a business analyst that happens to know not only how to write accurate software requirements, but also knows about Function Point Analysis, you have an advantage in that you should know when the process of gathering software requirements is really complete.

In short, for a given, basic set of features, you can know that the software requirements process is complete when you can accurately count the Function Points for the application you're designing.

Function Point Analysis and software requirements

Before learning Function Point Analysis (FPA), I used to always have a nagging feeling when writing a software requirements specification that I may have missed some functionality -- maybe a data-entry screen, reports, or something else -- but once I learned FPA, those fears went away.

Because of some "tricks" that you learn after using FPA for a while, you'll know that your requirements specification is finished when:

1. You verify that all ILFs are being maintained in your Use Cases.
2. You verify that there are three or more EIs for each ILF.

I'm not going to get into all the details here today, other than to say that "ILF" means "Internal Logical File", and "EI" means "External Input". If I go too far beyond that, I'd have to write a lot about Function Point Analysis, and I think I've already covered that in my Function Point Analysis tutorial.

The important note for today is that if you're a business analyst, and you also happen to know FPA, you have a nice little advantage in knowing when your software requirements specification is feature complete.