To avoid the pitfalls previously outlined, we recommend that you address the following as a starting point for the statement of requirements:
Justify each item
You must be able to justify why you have included every item in the specification. To assist in this, it is helpful to state a purpose at the top of the requirements section. This helps to constantly focus on the strategic (why?) considerations that are often overlooked.
It is also worth listing definitions that will help understand the detailed requirements − for example, stating what is meant by terminology such as “course” and “unit” within the context of an academic programme.
Think “out of the box”
A process review should have already provided you with a list of requirements that encapsulate what you want to do rather than just what you do now (see our process review infoKit for further details). It is also worth stating any existing critical constraints alongside the purpose and definitions within the requirements section, again as a way of focusing on the new requirements.
Decide what is a must and then what (if any) requirements you could manage without for a brief period of time; which of these you may be able to produce yourself, agree with your prospective vendor or a third party for these to be written, or source a package that will interface readily with your other systems. This exercise can often help eliminate items if the justification isn’t there!
As well as considering requirements in the three broad categories (general, technical, functional) it can be helpful to further sub-divide up the requirements into smaller chunks – for example: data management, data input, data output, configuration and usability. This helps to focus appropriate input from the relevant constituents, balancing between business specialists, technical staff and end-users. It also promotes consistency between the separate strands of requirements – for example if your statement of requirements includes a section for admissions as well as enrolment you are likely to want data output in the same formats for both.
Defining the requirements for the support of learning, teaching and assessment can be carried out in much the same way as the requirements for administrative functions ie by defining what it is you want to do and why before investigating the tools that are available. Once you have this information you may find that comparative evaluations of different tools are more readily available for these types of application.
We have produced this brief checklist to assist in the compilation of a statement of requirements.
You might want to consider what type of company you want to engage with. Are you looking for a specific relationship, eg a development partnership? What information do you want to consider about the vendor – financial stability, market share, future plans? Any specifications you wish to make can be elaborated on within the Invitation to Tender (ITT) itself.
Access and security
What security model(s) do you need? A ‘horizontal’ model (access based on system functionality), a ‘vertical’ model (access based on data values) or both? Does it vary across different business components (eg, do student marks’ recording requirements differ from student application records?). Do you need access/sign-on to converge with other existing protocols, eg, are you looking for single sign-on to all organisation applications?
- Consider the typical level of ‘set-up’ data volatility (how much it changes) and if this requires regular reconfiguration (eg changing organisational structures) think how you might draft this in as a requirement in terms of flexibility and streamlining of reconfiguration
- What capabilities do you need to extract, transform and load data from other systems?
- Does this include storage of items other than data, eg, scanned documents?
- What are your data management requirements in terms of auditing, tracking, validation and error-trapping?
- Ensure you have covered statutory and legislative requirements – eg, external auditing, external agencies, Freedom of Information (FOI) Act and Data Protection Act (DPA) compliance
- In relation to the point above, consider specific requirements for archiving and destruction of data (this will vary between business areas).
- What interfacing capabilities do you need to other products?
- Do you need to consider packages such as messaging/email facilities as well as other business and learning systems?
- How do the interfaces needs to operate – do they need to pull data from other systems or push data out?
- Do they need to be real time
- Do you require workflow capabilities within the product or other automation requirements such as diary/scheduling or automatic triggering of reports?
- Do you have any specific requirements for the user interface, navigation, report layouts, help and search facilities?
- Do you require a web interface?
- Are you considering self-service or portal functionality?
- Consider the user base and training implications – does this lead to specific requirements such as drop-down lists containing intuitive descriptions rather than specialist codes
- Do you need facilities for “fast track” data entry?
- Consider the skillsets you have available to you to support the hardware and software. What are the limitations in terms of resources and training? Coupled with your IT architecture/strategy/policy, does this lead you to any specific requirements? What are your likely support requirements?
- Do you have specific customisation/localisation requirements, and if so take care to investigate whether the methods proposed by the vendor are supported (ie are upgrade-proof) and are not localisations that require consultancy and recoding every time you upgrade
- Do you have existing or desired service standards to which the product must comply? What are your requirements for backup and disaster recovery facilities?
- Consider transaction and record volumes, peak processing times, and state scalability requirements
- Are there resources or scheduling constraints whereby you need to state limits on frequencies and scale of upgrades and desired length of support for previous versions
- Consider the number of environments you are likely to need (eg training, development, production and testing areas) and the resource implications of these
- Are there any technical standards you require for interaction/interfacing/interoperability with other products
- Do you want to specify any constraints about use of third party suppliers (subcontracting)?
- Are there any stipulations you wish to make about licensing structures?
- Are there limiting factors on running software relating to the kit available to users, eg specification of PCs?
These detailed requirements should fall naturally out of your process review, but it is worth paying particular attention to:
- Any specialist areas of business – eg, specific data requirements or reporting for professional bodies within a subject specialism or legitimately differing processes for a satellite campus
- New requirements arising from aspirations of greater interoperability between systems
- Do you require all functionality outlined to be in one core product or set of products from one supplier? If so state this up front – there could be third-party “bolt-ons” hidden within the proposed solution with additional implications for licensing and ongoing maintenance
- Remember to state expectations of coverage of statutory obligations eg, for agencies such as UCAS or HESA.