Why data quality is so important – and how you can improve yours
Data Solutions Designer Kanaga Selvi Nachiyar explains how we measure data quality and help organisations improve their data practices.
When we’re working on a software development project, we’ll always keep coming back to the requirements document. It’s a living record of the project, which contains all the important information about what stakeholders have asked for and how we’re building it.
We create this document as part of the initial scoping process, and update it throughout the project using an iterative approach that’s similar to the way we code. It helps us create estimates and organise the backlog – and it’s a handy place to find all the little bits of detail that are important for the project, like client-specific acronyms we’re likely to encounter, and any security considerations.
Before we write the document, we need to collect the relevant information – and that’s why we start with a requirements gathering meeting. Here’s how it all works.
Initial conversations for high-level planning
To kick us off, the account lead will set up a meeting with our team and the client. Generally, our team will include a product owner (that’s me) or a business analyst, and a few technical team members, including any specialists the project might need. We’ll have a preliminary conversation about what the client wants and why they want it, chatting about budgets and timescales. This gives us a high-level understanding of the challenges they’re facing, and the benefits they’re looking for.
After that, I’ll break the software down into its key features, creating a table that separates out the main pieces of work. This allows us to provide rough estimates for how long it’ll take to code the main components of the software, and how much it’ll cost.
In-depth decision making
We’ll then take this back to the client for a deeper discussion. This is where we can dig out other functionality, or even descope if the current plan is overkill for what the client really needs. It’s the perfect opportunity for us to highlight those ‘no-brainer’ features that the software needs but may not have been explicitly discussed yet.
What we’re really focused on here is what’s required for the MVP, or minimum viable product. The scope for that will guide our early sprints and ensure we’re delivering value quickly and getting a usable product in our client’s hands from the first deployment.
Creating the functional requirements document
All the information from these discussions combines to make the functional requirements document, which looks a lot like a wiki page. Each one looks slightly different, depending on the project, but they’ll generally include headers like these:
- Overview
What’s the high-level summary of the project?
- Stakeholders
Who’s involved in the project, and what are they responsible for?
- Terminology
Is there any client- or sector-specific vocabulary we need to look out for?
- Detailed Summary
What exactly are we aiming to achieve with this project?
- Diagrams and Wireframes
What does the user journey look like? How do all the features connect up?
- Technical Requirements
Which languages should we code with? What integrations are required?
- Scope Limitations
Are there parts of the project we won’t be involved in? Are there any pre-built or off-the-shelf components?
- Assumptions
What assumptions do we need for the project to succeed? For example, “the main stakeholder will be available to answer questions regularly”.
- Success Parameters/Project Goals
What does success look like? What milestones do we need to hit?
- Impact Assessment
What will these features allow the users to do? What’s the value of building these functions?
- User Stories
What individual features and functions do we need to build?
- Customer Support
How can we help the client use and maintain the software effectively?
- Testing
How are we going to assess the quality of the software? What parameters do we have to meet to progress?
- Security
Are there any regulations, data protection requirements, or other security concerns?
How we use the requirements document
This document is shared among the team – and with the client; it’s great for transparency, as everyone always has the same understanding of the work and what’s involved. And it means that when something changes, we can update everyone at once.
And it likely will change a lot during the project, especially if it’s a significant piece of software with lots of different moving parts. Agile development practices allow for small course corrections or even massive rescoping without having to throw the whole requirements document out – we can simply adjust the relevant sections and move on.
Throughout the project, the requirements document acts as our guide and record of the work completed so far, and what’s next on the agenda. It’s just one example of how collaborative Agile development is – and how working closely with our clients helps us deliver high quality software with speed and ease.
Related posts
Off-the-shelf products or bespoke software development – which would you choose?
Andy Roberts discusses why you don’t need to pit bespoke development against off-the-shelf tools when you’re choosing software.
That ‘quality’ thing: how do Agile teams create high-quality software?
Software QA Leader Przemek Furtak explores the challenge of building high-quality software – and the complexity of defining ‘quality’ in the first place.