Requirements questionnaire

This is a guide to questions you can ask stakeholders within an organisation when gathering requirements. Use it to interview individuals or when facilitating a workshop to discuss and gather requirements.You don’t need to ask to all questions of everyone but keep a record of who was asked what.

Why do you need this new system? What is the business need?

Describe why you need this system. What has happened/is happening that has triggered your system search? Focus on the business benefits to deliver or challenges/problems to solve.

For example:

  • We need to give our funders RBA outcomes reports.
  • We need better communication between our services to provide a wrap-around service to our clients.
  • We had a critical incident with a client and would like to be able to manage and monitor our high-risk clients better.

Services

Current state context

Get a high level overview of the service area.

  • Example: Can you please give me an overview of the service’s key functions or processes?

Current state service process specifics

  • What is the purpose of this process? Why is this process important? What service objective does this process meet?

  • What triggers this process to start?

  • Who is responsible for performing this process?

  • How does this process work today?
  • What is the end result or output of this process?
  • Is there a system that supports this process today?
  • If there is a system, are you able to show me how this system works?
  • If there is a system, are you able to give me some screen shots from this system?
  • If there is a system, are you able to provide the user guide for this system?

Identify problems/opportunities for improvement

  • Which areas of this process can be improved?

  • Is this a problem area? If so, why this is a problem area?
  • What do you believe will help address this problem?
  • What else do you think can help address this problem?

Reports

Do you currently have any existing operational reports that help you manage this service or team?

If yes:

  • Are you able to tell us about your most important reports?
  • Which systems produce your reports for you?
  • How often to you receive these reports?
  • Are you able to share some examples of these reports with me/us?

If no:

  • Tell us about some of your reporting requirements. What would you really like to see produced as a report? Why?
  • Discuss the content, frequency, audience and layout of the report at a high level.

Key interactions

Explain how the various user groups and elements of the system will interact, including any integration with external data or systems. Often a diagram is very helpful here. Remember to consult all users indicated in this process to ensure that you have an understanding of all user requirements.

  • Example: Show how ACC activities are assigned to clients by staff, and the service manager runs a standard set of reports and the accountant can export data to the accounting package in order to bill ACC. ACC has secure access to the system to view specific reports on the progress of their clients.

‘Must have’ requirements

List any features or capabilities that are essential (not just ‘nice to have’). In other words, if a system doesn’t have these ‘must have’ capabilities, it will not be considered as a valid option. Try to be realistic, taking costs, time and other resources into consideration. Not all requirements are essential.

Some examples of possible ‘must have’ requirements are:

  • ability to refer into a team and work as a team with a client
  • ability to take anonymous phone calls
  • automatic alerts for high risk clients
  • integration with a particular accounting system.

Top priorities

Consider the various characteristics of software in the list below, and identify the three that are most important to you. These are not really ‘features’ like the must-have requirements above, but instead are less tangible ‘benefits’ or ‘characteristics’ that are nonetheless critical to project success.

Identify the characteristics that are most important, and explain why and/or what you mean.

For example:

  • easy to use
  • low cost
  • powerful reporting
  • well supported
  • flexible to customise
  • can grow with your business
  • large, well-known vendor
  • good feedback from others
  • knows your industry well.
  • integrates with other software

Scenarios to test

Explain the scenarios that you will be most interested in during a demonstration with vendors. These should address major ‘use cases’ – i.e. the critical processes that users of the system will have to perform, and for which a demonstration will provide useful insights into the functionality and usability of the system.

For example:

  • Add a new client manually, note that a phone call was made and add notes about it, set a reminder to follow up in two months.
  • Import existing data from CSV format, run a report to identify records with incomplete data.

Other factors to consider

This is your place to list other things that matter significantly but didn’t get a good mention in the sections above. Provide additional context and information where relevant, but try to keep it succinct and focused.

For example:

  • Explain any factors impacting on the timeline of the software project
  • Outline the decision process at a high level so that vendors know what to expect
  • Do you have other software needs that might be related or solved at the same time?
  • Detail any relevant constraints (budgetary, resourcing, timing, etc)
  • Describe current workaround and/or options under consideration

Future requirements

(For discussion with CEO / GM / board of the organisation)

What is the strategy for your organisation? Five years – ten years. Are there considerations that need to be taken into account?