4.4. Trawling for Information
4.4.1. Introduction
Having created a model of the intended MLE, identified the key stakeholders and documented the user characteristics, you will be in the position of being able to trawl for information about stakeholder needs. This will be carried out by one or more staff acting as Requirements Analysts. The requirements analyst works with each stakeholder to observe, interpret and record their anticipated interaction with the MLE system to ensure that their needs are met in the most efficient and effective way.
There are some basic issues which need to be recognised and catered for at the outset. The first is that the stakeholders' only experience of an MLE and what it means for them may be the conceptual model created by the design team. They may not be able to express a need because they only have a limited understanding of what it can do for them. Under these circumstances it will be necessary for the analyst to create detailed examples of their practical use (known as use cases), for that stakeholder to reflect on. Similarly, a typical user will be very conscious of some requirements, but others needs will be so engrained in their daily work that they've forgotten they exist. The trawling process must use methods which reveal all the requirements.
4.4.2. A Framework for Identifying Requirements
Given the number of stakeholders impacted by an MLE and the varied nature of their requirements a systematic approach to information gathering is essential. One such method is Apprenticing where the requirements analyst sits with the stakeholder to learn the job by observation and asking questions. When asked about their jobs away from work, people tend to respond in generalist terms. However, most people are good at explaining their job whilst they are actually doing it.
Maguire proposes a three stage framework for determining user requirements:
User Context Analysis
Feasibility and Prototyping
User Requirements Synthesis and Validation
These stages are shown in the diagram below where it can be seen that Stage 1 covers the stakeholder analysis, Stage 2 covers conceptual design, prototype design and trawling for information and Stage 3 covers requirements specification and systems design.
The above set of diagrams show User-requirements Specification Framework (from Maguire, 1998)
Maguire uses diagramming very effectively and the diagram below is a good summary of the basic activities involved in requirements gathering.
User-requirements Specification Activities (from Maguire)
There are different ways in which the requirements gathering process is described by different authors, but the consensus is largely the same. The stage 2 iteration above would include a range of different methods for information trawling. Again, the summary provided by Maguire is as good a representation as any and table 1 below shows part of the much more comprehensive list of methods included in the resources.
| Characteristics Applicable to Framework stage: | |||||||
| 1. User Context and Early Design | 2. Prototype and User Test | 3. User Requirements Documentation | Time and Effort Required. | Expertise or Skills Required. | Equipment Facilities Required. | Particular Strengths | |
| Methods | |||||||
| 1. Brainstorm | Yes | Low | Group Motivator | Generating Ideas | |||
| 2. Focus Groups | Yes | Yes | Low | Group Chairing | Discuss Topic In-depth | ||
| 3. Functionality Matrix | Yes | Yes | Low | System Knowledge | Spreadsheet Software | Refining List of Functions | |
| 4.Group Discussion | Yes | Yes | Yes | Low | Group Chairing | Airing Issues | |
| 5. Interview | Yes | Low | Neutral Non-leading | Individual Opinions In-depth | |||
Maguire describes each of the above information gathering methods in some detail and provides a wide range of templates for use during the process. There are many other tools available to help with the requirements process and Robertson provides advice on making an appropriate choice.
In summary, then, the process of trawling for information will involve your requirements analyst working with each stakeholder to construct use cases or work scenarios which describe how the stakeholder will interact with the MLE. The requirements analyst will do this using a descriptive prototype of the MLE which is a specific view of the MLE conceptual model relevant to the stakeholder's role and working environment.
Follow this link for key resources for this section (these open in a new window)


