The Programmer's Input

In most organizations, programmers are told how finished programs should behave. One can argue that if a programmer can be told how finished programs should behave, whoever specifies the behavior can write the programs in the first place.

This is true only if the behavior of the finished product is specified in low-level detail. Generally speaking, the specification of program behavior given to developers is no more detailed than the specification reviewed and approved by the client. Yet, this specifications must leave no room for ambiguity.

For example, let us consider ``let a user attempt to log in three times, then lock the user out of the system after three failed attempts.'' This specification is ambiguous. The client may understand it as ``three consecutive failed attempts'', while a programmer may understand it as ``a total of three failed attempts, not necessarily consecutive.'' It is the responsibility of a systems analyst to ensure that a specification only has one interpretation (no ambiguity).

Another type of documents distributed to developers is bug report. However, a systems analyst should ensure every bug report distributed to developers relates to the original specifications of the programs. In other words, instead of simply stating ``the log in screen times out too quickly'', the bug report should indicate ``the log in screen times out in less than 10 seconds, as specified in section 12.3.5 of the specification, version 2.6.1.'' What if there is no specification of the time out delay?