Tom Goldring

Product Owner

Tom has held a number of different roles during his 10 years with Headforwards. In Tom's current capacity, he works as an internal product owner for the Special Projects Division, building on his previous experience as a quality analyst and business analyst to help facilitate the timely delivery of high quality products. Outside of work, Tom performs stand-up comedy, plays in a local band, and loves a good game of squash.

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.

Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770