Requirements gathering and prioritisation

The first sections of this Toolkit look at strategically reviewing technology enhanced learning in your institution. In many cases, having defined what you are setting out to do in broad terms, the next stage will be to complete a more detailed requirements specification against which your existing and other systems can be evaluated.

This is a very important part of the review process because the outputs can be used in many ways:

  • as part of the business case to take the project to the next stage e.g. move into a procurement process;
  • to develop your invitation to tender (ITT);
  • to help devise scripts for testing;
  • as a formal definition of customer requirements to form part of the contract;
  • to help with user acceptance testing (UAT) during an implementation project.

This is however no trivial task - in fact it is one of the most difficult parts of the review process and there are many potential pitfalls. Get it wrong and you risk:

  • just describing what you do at the moment and thus missing opportunities;
  • being overly prescriptive thus eliminating suppliers who do things in a different and better way;
  • creating a wish list that no individual product can live up to;
  • ambiguity that results in tender responses that don't meet your requirements;
  • ambiguity that results in confusion for your own evaluation team.

The good news is that you are part of a community with an outstanding willingness to learn and share together and we have plenty of information about how others have approached this.

Top tip

Your project plan needs to take account of other demands on stakeholders' time. Imperial College London found that requirements gathering took longer than expected because the project started in May and students weren't available over the summer.