8.4 User Interface Infrastructure

8.4 User Interface Infrastructure

Purpose

A user interface infrastructure is a coherent set of components that together enable a user to interact with the system, excluding anything developed as part of a specific system, general underlying software (such as an operating system), and hardware. That is, a user interface infrastructure is what's left if you take away the system and everything it needs to run that isn't wholly related to the user interface. For instance, the user interface infrastructure for a simple Web system might comprise a browser and a Web server. Unfortunately the pieces we're left with are usually tied to a particular technology, which we want to avoid as far as we can. A Web server is usually an implementation detail that requirements needn't worry about-but a Web browser is visible to our users, so we can't ignore it. This leads us into a dilemma about how much to say about a user interface infrastructure. Four possible approaches are as follows:

1. Say very little. Leave it up to the development team to pick the most suitable technical solution.

2. Describe only any technology that must be used. Otherwise, don't make technology statements. For example, we might require a browser-based user interface, and leave open how it's achieved. It can be hard to consider user interface matters without a general appreciation of prevalent technologies. Consequently, it is probably counterproductive to try being abstract when stating our requirements: if we have to support a specific technology, say so.

3. Specify the user interface capabilities required. This is likely to become intricate and tied to particular kinds of user interface components, so go only as far into detail as you must. Avoid being drawn into defining the low-level characteristics of everything: drop-down lists, scroll bars, menus … and on and on.

4. A mixture of (2) and (3).

The user interface is an area for which we might need more than one instance of an infrastructure. We might have different classes of users who have very different user interface demands. This is particularly true if we have specialized end-user devices-for example, in the case of a payment processing system with EFTPOS terminals for users in stores and PCs for internal users.

The subject of user interface infrastructures is often ignored completely in requirements specifications-usually without noticeable impact, no doubt because adopting a user interface technology is such an obvious need that projects take it in their stride. However, any area of functionality for which we have no explicit requirements is liable to be tackled in an ad hoc, unsystematic, and uncontrolled manner, perhaps according to the whims and prejudices of a senior member of our development team. As a result, the chosen solution might not be the most suitable for our problem-even if the person who makes the choice is competent to decide-because some important factors might be unknown to them at the time. A better solution might be overlooked.

Invocation Requirements

User interface invocation requirements do two things: first, they constrain the technology that can be used; and second, they state capabilities that the user interface must support (that is, things users can perceive when using the system's functions).

Technology constraints don't need to mention specific technologies or products but can include factors that influence the choice of technology. These can include salient characteristics of devices from which the system must be accessible. Here are a few examples:

Open table as spreadsheet

Summary	Definition
Access via Web browser	It shall be possible to access every user interface function via common Web browsers. For the purpose of this requirement, a common Web browser is one that is used by at least 5% of Web users. For each such browser, all major versions that have been released in the past two years shall be actively supported.
Client software download unnecessary	Users shall not have to download and install client software.
Prevalent programming language	All software that runs on a client device shall be written in a prevalent programming language, which is one for which software can be run on a personal computer without having to download a supporting environment. This requirement does not preclude the use of more than one programming language, provided each one satisfies this requirement.

It's important to strike the right balance between a broad sweep and being too narrow-which is often not easy. For instance, the "Access via Web browser" requirement carefully avoids committing the system to working with every version of every browser every developed, while at the same time not mentioning specific products or version numbers. It introduces a "rolling window" that automatically keeps up with the latest releases. Write these requirements to be timeless: as far as possible, we want them to be valid in five years' time, and we can't predict what product versions will be in common use then (or even what products).

Here are a few examples of capabilities to be supported by a user interface:

Open table as spreadsheet

Summary	Definition
Automatic screen refresh	It shall be possible for a function with a user interface to automatically refresh itself (for example, whenever any displayed data changes), without the user having to act. It is expected that few functions will need to refresh themselves.
Fixed graphical animations	It shall be possible to display fixed graphical animations. For the purpose of this requirement, "fixed" means the content of the animation is unaffected by the user's action: once it begins, it plays-like a video clip.
Interactive animated graphics	It shall be possible to display graphics that are animated and respond to user input under software control. That is, it shall be possible to develop client software that can display animated graphics.

Implementation Requirements

Commercial systems typically make use of user interface infrastructures built by someone else, outside the scope of the system. (That is untrue only for truly exceptional systems that require the building of their own specialized hardware devices, which we won't worry about here.) Usually, our user interface implementation requirements are limited to extensions to existing third-party products-if any. These requirements are typically relatively limited in their scope-for example, some special-purpose graphical widgets or an application programming interface (API) wrapper to make a product easier for developers to use or to mask implementation details. As a result, a user interface infrastructure is unusual in that its invocation requirements are usually more extensive than its implementation requirements.

We only need to consider detailed user interface implementation requirements if we want to undertake a rigorous process for the selection of a solution product (for a Web server, say), in which we want to perform detailed comparisons of alternative options.