Specifying Requirements
Specifying the requirements to be met by a new system is a fundamental activity in the early part of the systems lifecycle during the Process Review and System Selection phases and errors at this point significantly affect the ultimate implementation. The specification of requirements need not be a very large document and need not be particularly technical in nature, but it must contain sufficient information to enable suppliers and/or implementation partners to readily respond on the hardware components and software elements needed to support the institution's business processes and/or pedagogic needs, and project staff to evaluate those responses and make a reasonable estimate of the project costs and timescales.
Obviously, the more information provided at the earliest possible opportunity gives the best chance of success in selecting the correct system and planning and conducting its implementation. Nevertheless, you must balance the costs and resources needed to fully document its requirements against the total funds available for the whole system acquisition and implementation processes and the risks of not doing so.
Whether the system is intended to support administrative processes or the management of learning, the specification of requirements should describe:
the processes that the system is required to accomplish, both initially and planned for the future, and whether the requirement is mandatory or desirable, but not the manner in which it is to be accomplished (this risks replacing 'like for like' when more modern solutions may be available for current processes);
the types of data files to be maintained, both initially and planned for the future (e.g. suppliers, students, staff, invoices, courses, subjects);
the elements of each data file to be recorded, both initially and planned for the future (e.g. name, address, telephone number, fax number, e-mail address, contact names, bank account details, payment terms for each supplier);
the approximate number of records within each type of data file, both initially and with anticipated growth;
any appropriate business rules, both initially and planned for the future (e.g. a student must not be currently registered for more than one course at a time, an employee must not be paid via the payroll without authority from a line manager, an employee's expenses must be paid via the payroll and not via accounts payable);
any other internal or external systems with which the system should interface, integrate or operate (e.g. in-house Student Accommodation system, national clearing house systems such as UCAS);
who will be using the system and their location;
any user access requirements and constraints (e.g. remotely via a web browser);
the total number of users and the maximum number of users likely to be using the system simultaneously (i.e. concurrent users), both initially and planned for the future;
the different types of user and the purposes for which they use the system;
the level of the users' computer experience or system familiarity;
the main problems faced by users at present (e.g. duplication of data entry);
where the system is to be located and any hardware/environmental constraints;
system availability, reliability, maintenance and support requirements and constraints;
the level of technical resources available in-house;
any security, health and safety and performance requirements and constraints;
any known design, installation or implementation issues (e.g. centralised operation, budgetary constraints, critical deadlines, cyclical demands, staff unavailability); and
any plans for relevant future developments or institutional initiatives.
Having specified its requirements and planned to rely heavily on the specification during the system acquisition and implementation processes, it would be irrational for you not to disseminate the information broadly in order to gain widespread approval and sign-off of the specification. The signed-off specification can then be used to set expectations, maintain scope, allocate resources, phase activities, acquire the right hardware and networking equipment, determine the best levels of system integration, etc.
There are particular problems associated with obtaining useful input from learners. They may view their relationship with the institution as essentially short term and hence it can be difficult to interest them in developments that may not bear fruit for a year or more. It is also the case that some of what they see as desirable may conflict with legislative or security constraints or even sound pedagogic practice. That said they are nonetheless a key user group for many system implementations and every effort should be made to solicit their views. The JISC e-Learning and Pedagogy programme covers the theme 'Understanding My Learning'.
