In Chapter One, the ‘too-little-too-late’ problem of human factors contribution was identified. The problem highlights the importance of earlier and wider human factors involvement in system development. Although additional areas of human factors contribution have been identified, the problem could not be simply or directly rectified, since the contributions map poorly onto the design support requirements of each stage of system development. In particular, existing human factors design processes were observed to be largely implicit, and its design techniques provide only a narrow coverage of the system design cycle.

To solve this problem, a more explicit and complete conception of human factors design with respect to system development, is required. Such a conception would facilitate the identification of more specific requirements for human factors support. On the basis of the requirements, existing means of human factors contribution may then be recruited and extended as appropriate.

Current human factors input to system development is effected through methods, tools and guidelines. Although the input prompts the consideration of human factors concerns during system development, reports have highlighted inadequacies with respect to the scope, granularity, format and timing of the contributions (see Smith, 1986; Chapanis and Burdurka, 1990; Sutcliffe, 1989; etc.).

To improve the effectiveness of human factors input to system development, problems with existing approaches need to be examined. Such an examination would:

1. highlight requirements pertaining to the role of human factors in system development; such as the concerns of the ‘who’, ‘what’, ‘when’ and ‘how’ of human factors input;

2. support the enhancement of existing approaches for human factors input;

3. facilitate the specification of new and more promising solutions to existing problems of human factors input.

This book argues that current problems of input to system development cannot be solved by early human factors involvement alone. Instead, it is emphasised that the problems would be solved only by ensuring early human factors involvement that is then continued throughout system development. To achieve this objective, human factors designers must also contribute actively to system specification as opposed to system evaluation only. In addition, the requirements and activities of human factors specification should be made explicit. Thus, both software engineering and human factors needs may be represented and accommodated appropriately by an overall system development agenda. Intersecting design concerns between the disciplines may also be identified and addressed more effectively in this way.

Annexes A and B are provided here for the sake of completeness.

Annex A completes the set of human factors descriptions that may be derived for the case-study described in Chapter Four. The extant system descriptions shown are applicable only if the system to be developed is very similar to an existing system. In addition, note that the procedures described here are simplified versions of the sets presented in Chapters Four to Six.

Annex B provides the reader with an advance view of possible enhancements of the design descriptions and notations of MUSE. The case-study descriptions presented are for illustration only.

Annex A: Case-study Illustration of Secondary Activities and Products of the Extant Systems Analysis (ESA) Stage (Network Security Management System)

This account completes an illustration of the Extant Systems Analysis (ESA) Stage, for the case-study used in Chapters Three to Six; namely the Network Security Management System. Specifically, secondary human factors activities and products applicable in a variant design scenario are described. Note that the extent to which such activities and products are addressed depends largely on how similar the domain characteristics and implementation technology are between the extant and target systems. Consequently, illustrations of design products are provided only when their derivation was considered appropriate during the case-study.

Following the derivation of a conceptual design of the target system, user interface specification is undertaken in the Design Specification Phase of the method. Presently, the design stages comprising the phase, namely the Interaction Task Model, Interface Model and Display Design Stages, are described in the sequence performed during design (i.e. in the given order). As before, human factors design activities and products of each of the stages are summarised using a block diagram, and case-study examples are provided where appropriate.

The Interaction Task Model (ITM) Stage

Having defined the on-line task conceptually in a Target System Task Model, the high-level cycles of human-computer interaction may be decomposed further. The human factors description derived at this stage is termed a Target Interaction Task Model (or ITM(y)). Note that the model is concerned primarily with the description of error-free user-computer interaction. Potential user errors are addressed at later stages of the method (see later). Figure 6-1 shows the location of the Interaction Task Model Stage relative to other stages of the method.

The objective of deriving a Target Interaction Task Model is to specify the device level interactions required to achieve on-line task goals on the computer. The model is described in terms of expected user interactions with the designated hardware, and with bespoke, variant and standard objects and actions of the chosen user interface environment.

This chapter describes in detail the Information Elicitation and Analysis Phase of the method. The phase comprises two design stages, namely the Extant Systems Analysis Stage and the Generalised Task Model Stage. The stages, described in the order of their application (see Figure 4-1), are concerned with the generation and analysis of background information to support subsequent derivation of a system design.

As indicated in Chapter Three, intermediate design processes, products and documentation schemes for each stage of the method are described as follows:

1. (a) an overview of the stage is provided prior to a detailed description;

2. (b) a block diagram summary of the stage is provided to highlight the sub-processes involved in transforming stage input(s) into one or more intermediate product(s);

3. (c) case-study illustrations of the products, processes and documentation schemes of the stage are provided where appropriate.

The Extant Systems Analysis (ESA) Stage

The main objective of the ESA Stage is to generate background information to assist the design of the target system at later stages of the method (see Figure 4–1 – the ESA Stage is highlighted by a box outlined in bold). To this end, extant systems are analysed to characterise current user needs and problems; existing function allocation between the user and device; the design features and rationale of existing user interfaces; etc.

The primary objective of this chapter is to characterise the problem addressed by MUSE, a structured human factors Method for Usability Engineering. To this end, existing problems of human factors contributions to system development are reviewed; namely, existing contributions are poorly timed and contextualised to the support required at different stages of the system design cycle. As a result, the relevance, format and granularity of human factors contributions are not optimal for effective uptake during design. By establishing the nature of the problems, promising solutions may then be assessed. Arguments supporting a structured analysis and design method, such as MUSE, are thus exposed.

General Problems of Human Factors Contribution to System Development

Recent developments in computer technology (e.g. the availability and affordability of personal computers and the rapid diversification in computer applications) have resulted in a shift from mainframes to personal computers. Today, such interactive computers have made significant inroads into both the workplace and the home. Consequently, the user base of computers has widened considerably.

The extended user base, together with market forces, highlighted the importance of designing computer applications that are appropriate in both functionality and usability. The success of Macintosh computers is an example (see also Shackel, 1985 and 1986b; CCTA (Draft) Report, 1988, Annex 1; Shuttleworth, 1987).

The objective of the present overview is to establish a conceptual foundation for a detailed stage-wise account of the method in Chapters Four to Six.

General Characteristics of the Human Factors Method

The primary focus of the method is on design specification because a literature survey indicated that current human factors contributions are well established at later stages of system development, e.g. human factors evaluation after design implementation. In contrast, human factors contributions to design specification are generally inadequate and implicit. Since the recruitment of human factors contributions is traditionally late, the discovery of design errors is also delayed. As a result, the required modifications are costly and difficult to implement (see Chapter One). Thus, greater emphasis is placed on ensuring human factors contributions to design specification. In this context, a participative followed by consultative design role for human factors contribution is envisaged at system specification and implementation respectively. During the latter stage, existing techniques for human factors evaluation may be recruited to support the method. An overview of the method follows.

The method is structured into three phases, each of which comprises a number of design stages (Figure 2-8 is reproduced overleaf for reference).

This chapter describes a number of features that might be useful in practical work with qualified types. We adopt a less rigourous approach than in previous chapters and we do not attempt to deal with all of the technical issues that are involved.

Section 6.1 suggests a number of techniques that can be used to reduce the size of the predicate set in the types calculated by the type inference algorithm, resulting in smaller types that are often easier to understand. As a further benefit, the number of evidence parameters in the translation of an overloaded term may also be reduced, leading to a potentially more efficient implementation.

Section 6.2 shows how the use of information about satisfiability of predicate sets may be used to infer more accurate typings for some terms and reject others for which suitable evidence values cannot be produced.

Finally, Section 6.3 discusses the possibility of adding the rule of subsumption to the type system of OML to allow the use of implicit coercions from one type to another within a given term.

It would also be useful to consider the task of extending the language of OML terms with constructs that correspond more closely to concrete programming languages such as recursion, groups of local binding and the use of explicit type signatures. One example where these features have been dealt with is in the proposed static semantics for Haskell given in (Peyton Jones and Wadler, 1992) but, for reasons of space, we do not consider this here.

This chapter describes an ML-like language (i.e. implicitly typed λ-calculus with local definitions) and extends the framework of (Milner, 1978; Damas and Milner, 1982) with support for overloading using qualified types and an arbitrary system of predicates of the form described in the previous chapter. The resulting system retains the flexibility of the ML type system, while allowing more accurate descriptions of the types of objects. Furthermore, we show that this approach is suitable for use in a language based on type inference, in contrast for example with more powerful languages such as the polymorphic λ-calculus that require explicit type annotations.

Section 3.1 introduces the basic type system and Section 3.2 describes an ordering on types, used to determine when one type is more general than another. This is used to investigate the properties of polymorphic types in the system.

The development of a type inference algorithm is complicated by the fact that there are many ways in which the typing rules in our original system can be applied to a single term, and it is not clear which of these (if any!) will result in an optimal typing. As an intermediate step, Section 3.3 describes a syntax-directed system in which the choice of typing rules is completely determined by the syntactic structure of the term involved, and investigates its relationship to the original system. Exploiting this relationship, Section 3.4 presents a type inference algorithm for the syntax-directed system which can then be used to infer typings in the original system.