This is when you need to start thinking in real detail about what you need your database to do. You’ll need to make some decisions about input and output.
Input:
- Who are you collecting data about?
- What data do you specifically want to capture?
- Where will you be using the database? (Out and about when delivering services? At an office? When working from home?)
- Who inputs the data and how? (Frontline staff? On mobile devices?)
Output:
- Who needs to see what level of data?
- How do you want data to be analysed? (e.g. Aggregation / Segmentation)
- What reports do you need? (Tables? Graphs? Funder reports?)
In order to get both of these aspects right, you’ll need to sketch out what data you need for what purposes and create some user personas & user stories.
User personas
User personas are important in helping you design your product to meet the needs of your users by creating personas which represent job roles & requirements. Ideally you would create one for each stakeholder (Stage 1) to ensure everyone's specific needs are met. They provide a clear focus on the needs and preferences of users by identifying specific user characteristics, such as demographics, behaviours, and attitudes to prevent the creation of a one-size-fits-all solution and allowing for a more tailored and personalised user experience.
This is a good exercise to do with the team to get them to think through their own role and their own unique goals, tasks and usage practices. It's also a great place to get people to identify the pain points/frustrations with how things are currently done. Capturing these now and building these into your requirements will help ensure your team feels consulted, help you to define requirements that meet everyone's needs and give you something to return to once the database is up and running to check you're meeting people's needs.
Example user personas:
User stories
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer. The purpose of a user story is to get users to articulate what they need and why they need it. Get your team to focus on individual things they want from a new database and to phrase it using the structure below:
As a <type of user> — Who are we building this for? Who is the user?
I want <some feature> — What are we building? What is the intention?
So that <some reason> — Why are we building it? What is the value for the user?
For example:
As a Support Worker who organises the food bank deliveries
I want to produce a list of beneficiaries and their requirements for each ward in the borough
So that I can know what and how much is needed for each ward to prepare parcels and map the addresses for the delivery drivers
Again, you should involve the whole team to ensure you co-produce the organisations requirements for your new database. User stories are a great way to get people to really focus on what they need and why and it will help your project lead and the vendor to understand the context of a requirement. As with User personas, it also gives you something to come back to when testing the new database.
Creating a user requirements document
Once you've established who your users are and what specific needs they have, you're ready to start drafting your user requirements. We've created a template to help you with this process and put in some of the standard requirements people usually need. Add in your own unique organisational requirements and then go through it specifying what is essential, desirable, wish list or not required. This is another good exercise to do with the team to make sure everyone is on board with the choices you're making and invested in decisions about what you have to have versus what is nice to have. When you've completed the document you're ready to share it with vendors and get them to check off what can and can't be done in their database.