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,
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 firstname.lastname@example.org.