4.5. Creating a Specification
4.5.1. Introduction
The process of trawling for information was based on the interaction that each of the stakeholders would have with the MLE. We termed each of the specific interactions with a stakeholder a Use Case. The use cases and the information they provide about stakeholder requirements need to be systematically recorded, typically using the type of template referred to earlier.
Whatever form it takes, the record will need to contain some basic information:
A description of the potential requirement in the form of an action that the MLE must take to satisfy the requirement
A unique requirement identifier
The use case(s) this requirement is associated with
The source/stakeholder associated with the requirement
The requirement rationale and priority
It is likely, during the process of identifying stakeholder needs, that a number of complex use cases (or work scenarios) will be discussed which may involve a large number of requirements. It is important that these are broken down into single actions that the MLE must perform in order to do the work of the use case. If you want to investigate use case modelling in more detail there is a lot of published information available and a good example is the paper From Essential Use Cases to Objects included in the resources.
As the requirements emerge you are likely to want to classify them in a logical way. Typically this would be in terms of functional and non-functional requirements, the technical, physical, social and organisational environment and the various user interfaces. For each requirement whoever is carrying out the analysis will specify a fit criterion by which they would know that the MLE can successfully carry out the required action. The analyst will also be looking for dependencies and conflicts which will need to be resolved. During the whole process of defining the specifications, the analyst will be double checking stakeholder satisfaction, relevance, viability and completeness of the requirement.
4.5.2. Functional and Non-functional Requirements
Functional requirements derive from the fundamental purpose of the MLE and the particular mix of actions that it must be capable of to deliver the administrative processes and pedagogic approach favoured by the institution.
The infoKit on System Selection covers defining functional requirements in some detail and gives examples relating to student administration, human resource management and virtual learning environment (VLEs).
Defining the requirements of an MLE is necessarily more complex than considering a single system as you will be placing a lot of emphasis on how the different systems (particularly student records and VLE) interact. Depending on the scope of your MLE you may also be considering linking in your library system and perhaps systems such as timetabling and staff records. The complexity of all the possible user interactions is one reason why most institutions choose to phase MLE development. As part of the Managed Learning Environment Activity in Further and Higher Education in the UK (Landscape Survey) which was funded by the JISC and UCISA, a matrix was developed to enable institutions to consider how far along the line of MLE development they were. You may find it interesting to carry out this exercise.
You also need to think about the non-functional requirements which typically include:
Look and feel (colourful, attractive, professional)
Usability (easy to use, ergonomic, accessible)
Performance (speed, accuracy, reliability)
Maintainability (easy to maintain, doesn't require specialist skills)
Security (confidentiality, integrity, availability)
The requirement specifications must be drawn up in the context of the product constraints and issues that apply to the MLE (overall budget limits, scope, scalability, build or buy policy, upgrade path, interoperability). However for a successful MLE the design of supporting processes and information flows is critical in ensuring all the elements work together.
4.5.3. Reusing Requirements
When you begin the design process and construct a requirements specification it will not, of course, be the first requirements specification that has been created for an MLE. Moreover, MLE specifications for different institutions will tend to have a great deal of commonality in terms of their features, functions and the way they are used.
Typical use cases, therefore, for most users and key stakeholders will already have been identified and the requirements specifications created. At this early stage of development this information may not be well organised in the public domain, but as time goes on the body of information will increase and the need to create requirements specifications from scratch will reduce.
A good example of a user requirements specification is the 'User Services Assessment' document which can be obtained from the De Montford University MLE project web site. The Diagramming Report included in the resources also gives an example of drawing up a requirements specification.
The work commissioned by the JISC on MLEs and VLEs provides useful information in this regard and visiting the JISC MLE web site is a good way of keeping up with developments. It is intended that this infoKit will also disseminate good practice as it emerges.
4.5.4. Prototyping and Testing
Prototyping was mentioned earlier in this section as a means of raising awareness in stakeholders of the functionality of MLEs and the implications for their role in its operation. Prototyping is also used to play out the consequences of specifying requirements in circumstances where the experience of the user is limited or the feasibility of the requirement is unclear.
Low fidelity prototyping and testing is a simple paper-based technique for challenging and clarifying requirements through brainstorming activity between the requirements analyst and the stakeholder. A simulation of an interface (menus, windows, dialogues and icons) is built from paper and card and this model is used to demonstrate the interface to the stakeholders. This is done by a member of the analysis team playing the role of the computer. Changes to this model can be made very easily and quickly during the demonstration. Once articulated, the requirements are tested by evaluating the effectiveness of the actions they would require of the MLE in facilitating the use cases that generated them.
Follow this link for key resources for this section (these open in a new window)
