Skip to content

good practice and innovation
about us infoKits Tools & Techniques Publications Events
You are here: Home » infoKits » Creating an MLE » gathering-requirements » Trawling for information

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.

Click on image to view separately along with a description

Click on image to view separately along with a description

Click on image to view separately along with a description

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.

Click on image to view separately along with a description

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)


Bookmark and Share
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)