As you gather stakeholder requirements when preparing to acquire a new system, you can use this checklist to interview individuals or facilitate workshops. 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?
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.
- We need to give our funders RBA outcomes reports (be specific).
- We need better understand of clients that use multiple services to provide a wrap-around service.
- We had a critical incident with a client and would like to be able to manage and monitor our high-risk clients better.
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?
Do you currently have any existing operational reports that help you manage this service or team?
- 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?
- 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.
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.
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.
Consider the various characteristics of software in the list below. 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.
- 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.
- 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.
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.
- 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.
(For discussion with organisation CEO, general manager and/or board.)
- What is the strategy for your organisation across 5/10 years?
- Are there considerations that need to be taken into account?
- Client information
- Support requirements
- Client Plans
- Case notes & history
- Service Costing
- Client/member portal
- Management & exception
Integration (if required)
- HR, Incidents, etc
Multiple services areas
- Smart device
- Your own servers