4.2. Deciding Procedures

Introduction

A Managed Learning Environment is a human activity system and hence the use of formal systems design procedures makes sense for any institution wishing to create an MLE. Systems analysis and design involves well established and proven techniques and tools.

'The special contribution of Systems Design is that it offers a complete set of techniques, guiding design from gathering data about what matters to make, to defining the system function and structure that works for the customer.' (Beyer, H. and Holtzblatt, K., (1998) Contextual Design. Morgan Kaufmann. P425.)

'When the concern is the contribution of several institutional parts to one enterprise, as in the case of large scale projects, the VSM [a particular systems analytical method] offers the possibility to study and design flexible structures and, as a consequence, reduce the chances of costly errors.' (Espejo, R. (1989) A Cybernetic Method to Study Organisations. In The Viable System Model. Ed: Espejo and Harnden. Wiley. P361)

This section will outline a range of systems design techniques that you can use to create a comprehensive and accurate definition of MLE stakeholder requirements.

Requirements Specification Procedures

A typical representation of the requirements gathering process is shown below.

This diagram is an adaption from Robertson but is representative of typical approaches.

Usually, an MLE design project group is formed of key users of the intended system, reporting to senior management. The project group has the responsibility of ensuring that a thorough systems analysis is completed as part of the design process to ensure that the requirements of all users and stakeholders are accommodated by the MLE.

You begin the process by creating a conceptual model of the intended system which defines the main features and functionality. This will be initiated through brainstorming activities with key stakeholders together with experienced practitioners. If such expertise is not available within the institution, then other organisation support such as consultants may be engaged to support the process. The JISC and the Centre for Educational Technology Interoperability Standards (CETIS) have a role to play here and this infoKit is intended to provide a valuable reference resource.

The purpose of the conceptual model is to provide a vehicle for you and the design team to make the overall purpose and principles of the intended system apparent to all the stakeholders. Having done this, you can engage in dialogue with the stakeholders to begin the process of identifying needs. This is normally done in the context of the technical, physical, social and organisational environment of the stakeholders. The Conceptual Model describes, in general terms, the anticipated functionality and usage of the MLE. This model or Prototype would then be tested with each stakeholder group for its usability and a positive cost/benefit outcome.

The design team works with the stakeholders in an iterative process that continuously refines and develops the Conceptual Model to accommodate design constraints, task scenarios and new processes as they emerge from the consultation. Example 1. below, illustrates this process.

Example 1

Stakeholder: Institutional Quality Manager
Task Scenario: On-line access to student performance data
Design Constraints: Data security, VLE/MIS data interoperability, data access opportunities
Usability Goal: For internal and external examiners to have on-line access to student performance data
Requirements: Quality user interface, effective and efficient access to specific student data, coordinated and verified student data management system, complete data security
New Processes: Provision of secure on-line access to student data for internal and external examiners. Agreed quality procedures for the updating, verification and accessibility of student data

Throughout the process you will be compiling a User Requirements Document. This document would typically have the following structure:

• General system characteristics

• Organisational structure

• Task scenarios and interactions

• Technical environment

• System functions and features

• User interface design

• Standards and styleguides

• Test and implementation plan

A range of methods can be used to gather stakeholder needs and these are outlined in detail in the section 'Trawling for Information'. In summary, the design team will use:

• Brainstorming

  • A way of generating many ideas or problem solutions. Ideas should be broad and radical, and produced very fast. It is a lateral thinking process which encourages participants to break out of their normal thinking patterns into new ways of looking at things.

• Focus groups

  • An informal technique that brings together a group of stakeholders to discuss needs and requirements. It is useful to gather simultaneous reactions and group dynamics. It is important to have a moderator to maintain group focus.

• Group discussions

• Interviews

  • Usually conducted on one-to-one basis. They tend to be time consuming and as such need to be carefully planned.

• Observation

  • Again this can be a time consuming process and it it worth remembering the 'Hawthorne Effect' where people often change their behavious whilst being observed.

• Scenario building

  • Another group technique which is useful when building different views or requirements of a process. The trigger for the collaborative working may be that each person describes the process from their point of view, or a moderator presents a model inviting comments and suggestions.

• Storyboarding

  • A written or pictorial representation of a process. It is usually used to show a sequence of operations within a process and the interactions with other processes. An excellent technique to use when working with stakeholders who are not familiar with MLE concepts.

• Task analysis

  • Shows what a user is required to do in order to complete a task. It is used to define the current system and to show the information flows within. When determining the requirements for an MLE, the task analysis could, in addition, highlight duplication and omissions.

These methods are explained in detail by Maguire who also provides a series of templates for documenting the outcomes.

Although the development of e-learning delivery systems is relatively new in education, a number of institutions have been through a systematic process of MLE design and their experience is valuable for others beginning that process.

Jos Boys, for example, describes approaches to MLE development in the context of organisational change and notes that stakeholders have a variety of motivations and degrees of enthusiasm for change. This needs to be accounted for in the methods used to satisfy their requirements.

Sarah Holyfield examined the role of requirements gathering in developing a shared understanding of the managed learning environment, described in terms of functionality required by the stakeholders.

A number of other examples like these are included in the resources for this section.

Follow this link for key resources for this section (these open in a new window)