Precisely imprecise

We like to think that we software developers are a precise bunch. For example, we write down requirements (at least sometimes). And we expect the software to do whatever's written in the requirements.

All too often, it turns out that meeting a requirement is much more difficult than that. If developers fail to meet requirements when building agency systems, irate discussions and even litigation may result. We all lose in such a situation — developers, agency managers and technical staff, even taxpayers.

Part of the problem may be that requirements have an inherent lack of precision. For example, in a recent situation, a system had the requirement to "send e-mail." That's pretty imprecise, but we are comfortable with it because we all "know" what sending e-mail means. And we probably believe that any ambiguities will be addressed in the design.

The approved design showed that files containing text are uploaded to a server, where they are read by a program, which in turn calls a commercial control to send the mail. The parts of the mail message ("To," "From," etc.) are identified according to the Microsoft Corp. ".ini" file format, which provides a key that allows retrieval of strings from the file through a GetPrivateProfileString Windows application program interface call. Sounds simple, right? And well-defined. But it proved otherwise when the system tried to go live.

For one thing, the software did indeed send mail, but to one user at a time. Addresses that involved multiple recipients didn't work as expected. Does sending mail qualify as sending mail if linked addresses are not supported?

Also, messages arrived "from" an internal account that was able to connect to the Simple Mail Transfer Protocol service, not from the e-mail address of the user who created the mail in the first place. Was there a requirement to invisibly act as a proxy in forwarding e-mail?

Agency requests for proposals frequently contain specifications not much more detailed than "send e-mail." Vendors might respond with proposals claiming that their software does indeed "send e-mail," but the actual software might not do what the agency truly needs.

In this situation, many outcomes are possible. The contract might be canceled. Developers might modify the code to do what they were told it should do, and these directions might not even be written down. That process can go on for a long time and can cost a lot of money. If the vendor isn't prepared for the expense or isn't committed to the customer, wrangling over change orders is probably the least disastrous of the outcomes.

If it isn't cost-effective to specify requirements precisely enough so that we're happy with the results, maybe the time has come for lightweight methodologies that allow customers and developers to interact more closely as the software is built.

—Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at tbragg@acm.org.

Featured

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.