In contrast with the formal, analytical strategies developed by professional intermediaries, information seekers also use a variety of informal, heuristic strategies. These informal, interactive strategies are clustered together under the term browsing strategies. In general, browsing is an approach to information seeking that is informal and opportunistic and depends heavily on the information environment. Four browsing strategies are distinguished in this chapter: scanning, observing, navigating, and monitoring. The term browsing reflects the general behavior that people exhibit as they seek information by using one of these strategies.

Browsing is a natural and effective approach to many types of information-seeking problems. It is natural because it coordinates human physical, emotive, and cognitive resources in the same way that humans monitor the physical world and search for physical objects. It can be effective because the environment and particularly human-created environments are generally organized and highly redundant – especially information environments that are designed according to organizational principles. Browsing is particularly effective for information problems that are ill defined or interdisciplinary and when the goal of information seeking is to gather overview information about a topic or to keep abreast of developments in a field.

The following concerns are addressed in this concluding chapter:

1. An assessment of the development of MUSE and MUSE*/JSD. For instance, have appropriate case-studies and tests been used to support the development and demonstration of the methods?

2. An assessment of the methodological characteristics of MUSE and MUSE*/JSD. For instance, is their scope of human factors design appropriate? Are requirements identified in Chapters One and Two satisfied by MUSE and MUSE*/JSD, and have they any limitations?

3. A review of potential developments of MUSE and MUSE*/JSD. For instance, how could the methods be enhanced with respect to (a), (b) and (c) above? What computerbased tools could be developed to support the methods; and should declarative human factors knowledge be collated and integrated with them to facilitate method application at each stage of system development?

These concerns are discussed in turn in the sub-sections that follow.

An Overview and Assessment of Method Development Activities of MUSE and MUSE*/JSD

Generally, activities for developing the methods were implemented as planned, e.g. literature surveys; specification and test of method conceptions; case-study selection, planning and familiarisation; etc. An assessment of how key concerns of method development were addressed is discussed below:

1. Case-study selection. It was clear that the number of case-studies undertaken specifically to develop and test the methods would be limited by the resources available. Thus, considerable care was devoted to the planning and selection of appropriate casestudies for developing and testing the methods.

Having developed a structured method that supports human factors specification at each stage of system development (namely MUSE), its explicit integration with similarly structured software engineering methods may be considered. In this way, the problems associated with the ‘too-little-too-late’ contribution of human factors to system development may be addressed more completely (see Chapter One). To this end, the following concerns of methodological integration are discussed in this chapter:

1. (a) A conception of what constitutes an integration of structured human factors and software engineering methods. The requirements to be satisfied by the integrated method are thus defined.

2. (b) The pre-requisites and issues to be addressed during the integration of structured human factors and software engineering methods.

The above concerns are reviewed generally, followed by an illustration of how they have been addressed in the integration of MUSE (the structured human factors method) with the Jackson Systems Development (JSD) method (a structured software engineering method). For completeness and to provide a contrast with the latter work, other integrations of human factors with structured software engineering methods (work undertaken elsewhere) are also reviewed. Three structured software engineering methods are covered in the latter review, namely the Jackson System Development (JSD) method; the Structured Systems Analysis and Design Method (SSADM); and the Structured Analysis and Structured Design (SASD) Method.

In this chapter, the stages of the Design Synthesis Phase of the method, namely the Statement of User Needs Stage, the Composite Task Model Stage, and the System and User Task Model Stage, will be described in the order by which design is advanced. The account includes the design products derived to support target system specification using the method. Using the format outlined in Chapter Three, design activities of each of the stages are described in terms of sub-processes that transform its inputs into a number of products. As in Chapter Four, case-study examples are used to illustrate the products.

The Statement of User Needs (SUN) Stage

The Statement of User Needs Stage summarizes the conclusions of extant systems analysis and defines user requirements for the target system. Thus, the information collated would include a mixture of the following:

1. (a) existing user needs and problems;

2. (b) existing design requirements, rationale and constraints;

3. (c) rationale underlying extant design features to be ported to the target system;

4. (d) performance criteria and domain semantics for the target system.

The primary purpose of the products derived at this stage is to establish constraints to support later design decisions and extensions, e.g. during the synthesis of task models at the Composite Task Model Stage.

Figure 5-1 shows the location of the Statement of User Needs Stage relative to other stages of the method (the stage is indicated by a box outlined in bold).

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.