This is the third installment in the Requirements Specification series we began with May's issue of the month, which pointed out serious flaws in some recent trends in documenting user requirements.
Last month we examined the need for a project data dictionary and discussed criteria for specifying different kinds of data items. Once we've identified most of the data items that the proposed new system must store, we can start to determine how those data items will get into the system.
Historical background: In the 1960s many systems analysts used to begin the specification of a new computer application system by describing the system inputs (often punched cards). They were misled by the sequence in which events occur in the computer. If the first thing a program does, they reasoned, is to read some input cards, they'd better design the content and format of those cards. Today's enlightened systems analyst is amused by such a misguided approach. How on earth can we know what inputs are needed before we know something about what data items are to be stored and what the system is to do? Did any user ever demand a new system in order to be able to enter data?
|
Definition An input transaction is a collection of data items that:
|
Common transaction types Certain kinds of transaction arise routinely in business systems:
|
A transaction specification is similar in some ways to the use case favored by Ivar Jacobson and his followers. Both of them describe a system user's triggering of some activity.
Transaction specifications and use cases, however, should not be thought of as just two different ways of specifying the same thing. They are very different in a fundamental sense:
Definition Input editing consists of two functions:
| Validation levels There are several levels of validation:
|
Once data items have been edited, the application program's functions need not concern themselves with either trivial error checking or messy external data representations. Thorough input validation combined with simple internal data representations will make a huge contribution to the maintainability and reliability of an application system.
Syntax validation and external-to-internal conversion require minimal computer power, and are easily done on a desktop client or an offline microcomputer without access to the application's database.
A common form of requirements clutter is validation rules. It is never necessary or desirable to document a "requirement" that:
The way a system reads its input transactions has steadily changed over the past decades, perhaps more than any other aspect of a business system. We've progressed from batch records, prepared off-line on a keypunch to user-friendly forms, submitted over the web.
A central design principle is this:
Data-entry mode is not part of the formal specification of a transaction type.
A system may accept, for example, a renew subscription transaction through an interactive telephone-key-pad dialog with the subscriber. The same system may also accept a renew subscription transaction from a file of sorted batch transactions keyed by a data entry clerk in a poor country. Those two transactions contain exactly the same component data items, and they cause the system to take exactly the same action. They are, therefore, instances of exactly the same type of transaction.
It follows that data entry mode is rarely of primary importance in capturing and documenting user requirements for a new application system. Indeed, over the lifespan of many business systems, changing technology, changing economics, and changing user communities will very likely require entirely new front ends.
|
Some systems analysis textbooks and packaged life-cycle methodologies contain forms or templates for specifying system inputs. The good ones call for at least the following information:
| Section | Content |
| Purpose | A brief statement of what this transaction accomplishes and, if not obvious, why it's needed. |
| Volume | Average and maximum number of transactions per day or other unit of time. |
| Content | List of component data items (fields), each of which is precisely defined in the data dictionary. |
| Audit, security, & privacy considerations |
Any restrictions and constraints on the entry and authorization of this type of transaction. |
| Medium / entry mode | Any bona fide constraint on the data-entry mode. |
While most system inputs are transactions, a few are not. Non-transactional input is more typical of scientific/engineering applications than of business applications and more typical of single-user systems than of multi-user systems. Examples include:
Obviously, non-transactional input is subject to the same editing requirements that we apply to input transactions.
Return to Requirements Guidelines
Return to IDI Home Page