Another kind of highly visible system component

Specifying System Inputs
© Conrad Weisert, Information Disciplines, Inc., Chicago
1 August 2003

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.

A logical next step

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?

Transactions and use-cases


An input transaction is a collection of data items that:

  • Are entered together into the system
  • Cause the system to take some action

Common transaction types

Certain kinds of transaction arise routinely in business systems:

  • An inquiry transaction causes the system to display information.
  • A file maintenance transaction causes the system to update its database or permanent (master) files.

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:

Input editing


Input editing consists of two functions:

  1. Validating that the component data items are legal and reasonable.
  2. Converting component data items from external representation to a standard internal representation. (In an object-oriented program that representation is usually the hidden private data members of objects.)

Validation levels

There are several levels of validation:

  • Syntax validation makes sure that a data item conforms to its specification. For example, that a numeric value contains no alphabetic characters.
  • Context validation makes sure that data values are consistent with one another. For example that dateHired > (dateOfBirth + a constant).
  • Database validation makes sure that data values are consistent with the contents of the database or master files. For example, that productNumber matches a product in the catalog.

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.

Specifying validation rules

A common form of requirements clutter is validation rules. It is never necessary or desirable to document a "requirement" that:

Data entry modes

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.

Warning: Some modern software development tools encourage a kind of GUI-driven specification, where the systems analyst begins by considering the first screen that a user will see, and then designs a series of screens and forms through which a user would navigate. While the results may be useful as illustrative input-output prototypes this approach can easily lead to the long-discredited input-driven approach described in the historical background note at the beginning of this article.

If you develop an input output prototype to help the user visualize the new system, be sure that you also prepare rigorous transaction specifications.

Defining the content

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
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.

Non-transactional inputs

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