By Aaron Novstrup,

College Sophomore,

University of California, Berkeley,

Mathematics/Computer Science Major/Minor

This report evaluates the provided functional specification based on its likelihood to contribute to a good final product. The purpose of a functional specification is to convey any information that software developers will need to successfully complete a software project. In short, anything necessary to make the client happy with the software should be clearly and concisely detailed in the specification.

A thorough evaluation of a functional specification requires a strong working definition of the term "functional requirement". For the purposes of this report, a "functional requirement", or simply "requirement", will be defined as any necessary component of a software application. Each requirement can then be categorized as a function of the application, an element of the user interface, or part of the interaction between the software and the underlying system (Lukoff 1).

The attached functional specification defines three main requirements for health insurance software. The software must obtain information from the end-user regarding a claim to be processed', reference and update four databases containing information about claims, patients, doctors and procedures , and reject or process the claim. Breaking this down further, the program flow is as follows. First, the software prompts the user for whatever information is necessary to locate any additional information in the database. The program then looks up the patient and the claim in their respective databases and rejects the claim if the patient is not enrolled and paid-up, the patient is excluded from coverage, or the claim has already been processed. If the claim is not rejected, the application looks up the doctor and the procedure in the databases and determines how much to pay. Finally, the software updates the claim file and pays the claim.

Despite the clarity of program flow described above, the functional specification is not clear at all. It is in fact so ambiguous as to make it practically useless to developers. According to the Random House Compact Unabridged Dictionary, specification is defined as "a detailed description of [... ] requirements"- the word is synonymous with "blueprint". As you may know, a blueprint for a building shows everything from beams and studs to water pipes and light switches - anything that is relevant to the people that actually have to build it. Of course, a functional specification need not be as rigorous as a blueprint, but this specification should be more like a detailed blueprint and less like a loose outline.

The most blatant ambiguities lie in the database requirement. Table 1, titled "File Structure", gives absolutely no information about the file structure. If the files will be created from scratch, as they would for a new insurance company, this needs to be stated. Likewise, if the files already exist, this deserves mention. Furthermore, the data could be stored in any number of ways - in a character-delimited file, a fixed-width file, a Microsoft Access database, etc. The developers also need to know the type and size of each data field. The Paid Amount (listed in the claim file), for example, would be a floating-point number, but how big does it have to be? Membership Status (in the patient file) is a complete toss-up; it could be any size and stored in anything from an integer to a string of characters. A good specification would provide detailed information for each field in the databases. Database maintenance is also ignored by the specification. Clearly these databases will need to be modified aside from processing insurance claims. Patients and doctors will come and go, new procedures will be discovered, and so on. The claim-processing software might be entirely separate from the database-maintenance software, but either way the specification needs to address the issue.

Further ambiguities lie in the user interface requirements. Actually, the functional specification fails to explicitly mention these requirements at all. A developer needs to know what information will be entered by the end-user and how it will be entered. Obviously the program should prompt the user for the least possible amount of information needed to process the claim correctly. Will a claim number, patient name, doctor number, procedure number, and submitted amount give the program enough information to pick out a record in the database and process the claim correctly?

Equally important is how the user will enter the information. Any necessary claim information could be entered as command line arguments or stored in the records of a database of unprocessed claims. A developer might assume that the information would be entered into a dialog box when the program starts. The specification should clarify the data-entry needs (or wants) of the client.

This leads into a discussion of system requirements, which were left unspecified in the functional specification. System requirements are those requirements that relate to the interaction between the software and the system. This includes technical requirements such as memory allocation and efficiency, but system requirements are also closely tied to user interface requirements since each operating system has a unique native interface. An insurance company running Windows 2000 on two hundred computers is highly unlikely to want a program with a text-based interface, just as a legacy company with 386 processors and DOS may be uncomfortable with a graphical user interface. The specification should reflect the concerns of the client by describing two sets of system requirements. One set of requirements lists the minimum system configuration on which the program will run, and the other set lists the configuration on which the program will most commonly be used. This results in software that is tailored to the specific needs of the client and prevents expensive system overhauls necessitated by overly demanding software.

Due to the sensitivity of the information in the databases, some measures would have to be taken to prevent it from being accessed by unauthorized persons. A good developer might make this assumption and write security into the program, but the security requirement is important enough that it shouldn't be left up to the developer. The specification should take a sentence or two to describe a minimum level of security.

With the functional specification as vague as it is, it wouldn't be feasible to write code to meet the interface, database, or system requirements. Code could probably be written and tested to meet the processing requirements, but the utility of this is questionable since changes might have to be made after the other requirements are clarified. Once the ambiguities are removed from the specification, however, deriving test cases would be quite simple. The processing requirements could be tested independently by seeding the functions with data that would simulate possible scenarios and then checking the actual results against the expected ones. The database requirements could be tested independently by having the software read fields from a sample database and storing the results in another file. The processing and database functions could then be tested together with sample data, and finally the interface could be added and tested.

Due to its vagueness, it could be a costly mistake to release this functional specification to the developers for writing code. The final product would almost assuredly fail to meet the client's expectations if the project survived to completion. It is more likely that the project would run into a dead-end at which point the specification would have to be revamped. This would result in lost man hours and either a late completion or an unsatisfactory product. To avoid this, the specification should be overhauled before it goes to the developers. The changes would be simple: clearly and precisely define the user interface, database, and system requirements. Make the specification resemble a blueprint rather than a fleshless skeleton. Specifically, the following questions need to be answered: 1) Do the databases already exist? 2) Is there anything that the developers need to know about the database fields? 3) What should the program prompt the end-user for? 4) How will the end-user enter the information? 5) What type of computers will need to run the program? 6) What level of security is required?

Lukoff, Brian. "Requirements Management: Is It Really Necessary?" Online

posting. I May 2001 <http://www.ssq.org/grant/Lukoffhtml>.