by Conrad Weisert, November 13, 2006 NOTE: This article may be circulated freely as long as
the copyright notice is included.
© Information Disciplines, Inc., Chicago
A few years ago we began seeing a strange phenomenon in the specification and development of computer application systems: a shift away from emphasis on what the application does toward emphasis on what it looks like to an on-line user. That phenomenon followed and was very likely influenced by the emergence of graphical interface tools and languages, such as Visual Basic1.
That seemed especially puzzling in the case of information systems, still among the most common computer applications. An information system produces outputs in the form of reports or displays that contain information that its users need and want. That information constitutes the main, often the sole, purpose of the system. Nevertheless, I continue to encounter application development project teams well along in software development who are unable to show me a list of the output data items their proposed new system is to produce.
While making a presentation to a professional society group several years ago, I reported that I had recently encountered several failed projects in which the process of specifying a new application had gone through these four steps:
Of course, I meant my anecdote to raise amused but serious concern about a growing requirements crisis. To my surprise, however, an earnest young man cornered me after the presentation. "But of course that's the way to specify and develop a system," he protested. "How else could you do it?"
It's obvious that the four-step process process described above, like all iterative and incremental approaches, won't work at all if our intent is to develop requirements that might be met by a packaged software product. But often, the process of evaluating, choosing, and installing packaged software is even more interface-driven than custom development.
Here many organizations substitute a vendor demonstration for most of the requirements elicitation and documentation. Typical vendor presentations place great emphasis on the attractiveness and slickness of the user interface and gloss over detailed issues of exactly what their product does in specific situations. It's not unusual for executives in the buyer organization, after being impressed by such a demonstration, to make a commitment to buy and install the product. A project to do so is then formed. Not until the user training stage of the project or even parallel pilot testing do the new system's shortcomings relative to the users' real requirements come to light.
The look and feel of the user interface will affect the usability and acceptance of an application system, in particular:
Important as those things are to the success of a project, they have nothing at all to do with the functionality of a system. If a system doesn't do what the users need, the most elegant interface imaginable won't salvage it. But if a system fully satisfies its users needs, we can graft a wide variety of user interfaces onto it.
In theory it ought to be much easier to graft an entirely new user interface onto an existing system than to extend or alter the system's functionality. In practice, however, weak interface-driven design undermines our ability to alter the user interface after the system has been developed.
Consider for example a subroutine for processing a particular type of transaction. As we've noted in discussing input transaction specification that subroutine should know as little as possible about the source, entry mode, and external representation of its input data items. The identical subroutine could be used whether the input came from a GUI form, from a prompting dialog, from a telephone keypad, from another application's XML output, or from some other kind of batch record. Unfortunately, however, many new systems invert the logical module hierarchy, so that the transaction processing subroutine is subordinate to various "controls" belonging to a GUI form. Worse, the processing logic may be fragmented into pieces subordinate to multiple controls, making it impossible or prohibitively expensive to alter the user interface beyond cosmetic changes. This is an unavoidable result of the interface-driven approach to development that we described earlier.
Such an inverted structure, with the actual processing subordinate to the end-user input-output, is sometimes called an "application framework" by its supporters. That sort of application-framework design approach is in conflict with two well-established principles of software design:
Regardless of the process we use for gathering system requirements or the techniques we use for documenting those requirements, we should always start by specifying exactly what the proposed new system is to do. Once rigorous functional requirements have been approved by the sponsoring end users, we can evaluate packaged software products to identify candidates that support the required functionality. If we then elect to pursue custom development (in-house or contracted) we can then:
If we do that right, we should have a lot of flexibility in the final step, including the ability to provide more than one interface to assemble and submit transactions, such as:
Return to IDI home page
technical articles
methodology material
Last modified November 25, 2006