CHAPTER 3: GATHER REQUIREMENTS

Once you’ve been through the tasks in the previous chapter, you will have a very good overview understanding of what is needed from the new system or service. The next step is to obtain a more detailed specification of what’s needed.

In this chapter, we will look at:

• the purpose and objectives of requirements
• who should be involved
• different ways to gather requirements
• detailing and prioritising requirements
• how to write up requirements
• a requirements specification document template.

Purpose and objectives of requirements

You may ask yourself why this exercise is needed. After all, you already know what you need, don’t you?

There are several reasons:

• You need to make sure that there is consensus and a common understanding of the requirements. Until they are documented in a reasonable level of detail, it’s quite possible for people to think they are talking about the same thing, when actually they have quite different perspectives.
  For example, there may be a general understanding that you want a user help guide with a new system. One person may be thinking of this as a short paper help-sheet whilst another may think of it as a comprehensive and detailed online facility. If you don’t come to an internal agreement before you start assessing options, you will find some wildly differing scores!

• You need to document the requirements in sufficient detail to send out in the Request for Information. The supplier will need a reasonable level of detail in order to decide what to offer you.
• It’s a great opportunity to involve more stakeholders (see below).

The objective of the exercise is to produce a requirements specification document that is agreed by all those involved. The level of formality of the document should be dictated by the needs of the organisation. There’s an example of a reasonably formal document later in this chapter; you can tailor this as appropriate.

The requirements list will be a key input to the Request for Information, and will also be used to determine some of the criteria for assessing responses. If you’re selecting a new system, they will also be used when configuring and implementing the system.

Who should be involved?

The core selection team agreed upon earlier will probably be key participants in this activity. However, the requirements gathering exercise is your opportunity to involve a much wider group of people. You should aim to get a few people involved from each team, or a few of each type of user that will be affected by the new system or service.

This has a number of benefits:

• the more people involved, the better the chance of gathering all the requirements at the start
• it’s an opportunity to increase buy-in to the new system or service
• it’s another chance to find out if there is any hidden dissent (see Chapter 2)
• it’s likely that your core selection team will include a member of each user group, so it should help them to fully understand the needs of the group they are representing.

Of course, the more people you involve, the greater the time needed, so you do need to be sensible. The use of workshops (see below) will allow a greater number of participants without extending the timescale too much.

Ways to gather requirements

There are a number of ways in which you can gather requirements. The main ones are:

• interviews – you could meet each stakeholder individually
• workshops – you could get everyone together in a workshop (or more than one if numbers are high)
• online discussion – if you have a facility like a discussion forum available (possibly on your intranet) you could get everyone to post their requirements and comment on each other’s
• online survey – if you have a reasonable idea of what’s needed, you could post questions to get specifics or to see which choices people would prefer.

All of these have strengths and weaknesses. If there’s a small number of people who are difficult to get together (maybe they are at different locations), then interviews may be best. If you want a very large number of people to be involved, then an online approach may be appropriate. If possible, the workshops approach is probably best. The exchange of views, and the bouncing of ideas off each other, usually gives you a much better set of requirements. This allows you to sort out any dissentions on the spot.

You could also use more than one of the above. You could gather a set of requirements by interviews and/or from workshops and then post them online for a wider group to comment on. Of course, you may not have the luxury of time for this type of two-tier exercise.

Detailing and prioritising requirements

Whichever method you choose, there are a few guidelines to follow:

• Make sure you’ve covered all aspects. Not an easy task! One way is to draft up a list of areas you need to make sure are included before you start to gather requirements; you can use this as a prompt. This should comprise:
  • the overall functions that need to be included – you should have a good idea of these from the scope
  • a checklist for how the system/service needs to work (commonly called ‘non-functional requirements’) – these include elements such as technical, performance, security, usability, look and feel, business and cultural, legal, etc.
• Get people to have an open approach to their requirements. Whilst you don’t want anyone becoming too unrealistic as to what they could get, you also don’t want them artificially bound by, say, the constraints of a current system. It’s better to get them to think about what they would ideally need – if they get carried away, you can always agree to remove the more outlandish later on.

• Aim to capture the fundamental need, not one particular solution. This is related to the point above. It’s common for people to state a requirement in terms of one particular way it could be met. Unless there’s some reason why that solution is the only one you’d want, you should try to get to the business requirement behind the solution.
  A typical example is that people say ‘the system must be password protected’. This is one specific solution; the fundamental business requirement is for access to the system to be secure. There could be other solutions to this need, such as fingerprint verification, code-key, etc., that may be better for you, but if you don’t provide the more open requirement, the supplier may not even mention them and you won’t know they are a possibility.
• Make sure each requirement has a reasonable level of detail. You don’t want to have a blandly written requirement that could mean a number of things. Apart from avoiding situations where people in the team have a different understanding of the requirement (remember the example of the user help guide which could mean a short paper help-sheet or a comprehensive online facility?), remember that you will be asking suppliers to say whether they can meet it. If it’s not clear what it means then their response will be fairly meaningless.
  One way to do this is to get people to think about how they would know that the requirement had been met. A common (and very unclear) requirement for a system is that it is ‘user friendly’. Asking people how they would assess it should give you a much better idea of what’s needed. For example, an accounts team might find shortcuts for rapid data entry ‘user friendly’ in an accounts system; this might be very different from the views of a casual user of the system who just checks a report occasionally. ‘User friendly’ to them might mean ‘I can find my report easily’.
• Consider prioritising the requirements. It’s likely that you’ll have a long list of requirements and it’s also likely that these won’t all have the same level of need. It will make assessing much easier if you prioritise them. There are a number of ways of doing this, but a useful one is:
  • Mandatory: these are the requirements that the new system or supplier HAS to meet or they won’t even be considered. Very useful in the first wave of assessing! (E.g. must be able to produce a year-end report in the format required by our Auditors.)
  • Important: you would really like the new system or service to meet these. However, there would not be an automatic rejection if one wasn’t met, especially if there is a way around it. (E.g. should be able to export a report in CSV format.)
  • Nice to have: what it says! These are the things that it would be useful to have, but really aren’t going to make much of a difference if you don’t have them. (E.g. you may like to be able to put your organisation’s logo in the header of a report, but it’s not a problem if it’s not possible.)

How to write up requirements

Whatever the level of formality you’ve decided upon for your requirements, you will need to document them somehow.

It is, of course, possible simply to have them in an unstructured list. However, this makes life harder later on, both for your suppliers when they are trying to respond to the Request for Information, and for your selection team when reviewing the responses.

So, it’s worth putting some kind of structure around the documentation. There are a few ways of doing this:

• Grouping by category: a common way to do this is to split the requirements into two broad groups:
  • functional (i.e. what the system or service actually needs to do, such as data to be held, reports, interfaces, etc.)
  • non-functional (i.e. how it does them, such as look and feel, performance, security, etc.).
• Grouping by different areas: (e.g. you could split requirements for a new catering service into groups, such as: running the restaurant, providing a sandwich trolley, providing refreshments for meetings, etc.).
• Sorting them by priority.
• Or some combination of these (e.g. by priority order within categories or areas).

As you’re writing them up, make sure that each one has been clearly stated; if not, ask the team for specific feedback on any uncertain ones when you send the specification out for review and agreement.

It aids clarity if your language matches the level of priority. Some examples are:

• for a mandatory requirement use ‘must have ... ’ or ‘has to ... ’
• for an important requirement use ‘should ... ’ or ‘preferred if ... ’
• for a nice to have requirement use ‘could ... ’ or ‘would be nice if ... ’.

Example requirements specification document template

This section includes an example of the composition of a formal specification document, using the categories grouping method. You can tailor this to meet your specific needs.

The text in italics is guidance text, to be replaced with your own content.

Example: Requirements specification document

1 Overview of selection

Provide some background about the current system/service and why it is to be replaced, or why a new system/service is needed.

List the teams/types of user who will be affected and who are involved in the requirements gathering.

2 Objectives for new system/service

List the objectives.

If there are a number of teams involved, it may be worth doing an overview plus some detail about what each team wants to achieve.

3 Current issues

Consider listing the current issues; this can help focus the team on ensuring that the new system/service resolves them.

4 Future plans

Consider listing any future plans that could affect the selection.

5 Functional requirements

List those requirements which detail what the system needs to be able to do. This is usually done in a table. You could put these into sub-group tables such as Data, System functions, Reports, Interfaces. Each requirement should comprise:

6 Non-functional requirements

List those requirements which detail how the system will work, rather than what it does. The format is the same as for functional, above. Unless it’s a long list, these can usually all be in one table.

7 Appendix A: List of people involved

Provide a list, or a table. It could be useful to include the person’s role (e.g. expert user, trainer, technical support).