Anatomy of a software brief - that actually works
3 Feb 2022
Distributed helps companies build better quality software faster and more cost-efficiently than ever before. With access to the world’s best freelance tech talent, developers are specifically selected for each client project from a global Elastic Team, onboarded and managed, allowing us to deliver software at any speed or scale while maintaining the highest quality outcomes.
To ensure we do this smoothly and efficiently every time, we have codified the customer experience from start to finish.
This article is part one of a three-part series, taking you through the initial stages of our process, starting with the first point of engagement we typically have with our customers – the briefing.
Working with external software development companies and contractors can be a lifeline for any business looking to expand their capacity to drive digital change. But to ensure a project achieves the best results possible, it’s critical to provide them with a clear and comprehensive brief. Every organisation is different and so both parties should fully understand the desired outcomes of the project before progressing to a more formal stage of engagement.
The initial brief should be at a fairly high level, yet capture enough detail so your delivery team can consider the size and personnel of the project team, as well as the appropriate technologies and architecture. Only then will they be able to give you a more accurate gauge of what it will take to deliver the desired results.
This sounds simple enough, but getting the brief right can be challenging and sometimes, inaccuracies are only discovered when it’s too late. A project that is fully understood by those within an organisation – who are already familiar with the flow of operations, culture and processes – can be confusing when presented to an outsourcing partner. Briefs can be overly detailed and complex, or sometimes vague – either way, missing the most important detail – what is it that the end-user actually wants to do?
Because of this challenge, we’ve built a step-by-step process to understand the necessary details from our initial conversations with clients. So, if you’re looking to brief freelancers, a development company – or simply gain a better understanding of what constitutes a great software development brief – read on.
(You can download our template via the link at the end of the article.)
The Project Overview
The first critical step is to create the project overview – a brief description of what it seeks to do from an end user’s perspective.
Enterprise Incorporated wants to modernise its B2C customer application. This handles the customer front end, giving the company the ability to share 3D print files with clients without them having access to the original file. The system should allow clients to log into the print function and print out the file. The solution must be secure from end to end, even where clients are logging in from remote locations.
Starting with outcomes allows developers to think ahead about the best way to deliver the solution. As we progress through the process, the project overview also provides a compass for both parties to qualify at every stage whether the proposed features and deliverables will bring about the key outcomes.
At this stage, you should outline where the project fits into the larger business architecture. For example, this could cover:
If it is a standalone build or a small part of a larger project;
What the broader business impact would be;
What value it provides to different stakeholders;
What is most important to you: speed of delivery, quality or cost?
It’s also crucial here to give a succinct answer to the question “What problem are you trying to solve?”
This scraping tool is part of a larger project where the main aim of Fintech Ltd’s clients is to help get better prices or better value by assessing different FX trading firms. The first step is to compile a dataset of FX trading firms, with a recommendation engine built on top of this scraped data.
What problem are you trying to solve? To create a simplified method in the application form to automate the gathering of FX data from third-party websites.
With the initial scope clear, we can start delving into more details about the specifics of project delivery. A great way to start is by listing all the major features (or epics, as they’re referred to in agile development) to be included.
Let’s say you’re a fintech company, building a set of new features into an existing customer-facing mobile app. You want to add a payments function, an account monitoring function using open banking, and a dashboard for users to view data from their accounts.
Once you’ve listed those three main features, each of them should be broken down into a list of requirements (not tasks).
By focusing on requirements rather than tasks, development teams are given the freedom to think about solving the problem in the most effective and efficient way. Every developer in the Distributed Elastic Team is an expert with years of experience to bring to each specific project. While each developer will be able to show their work, a requirements-focused approach will give the project team more flexibility to find an effective path to the end goal.
Against each requirement, you should state:
The what – e.g. a sign-in page;
The where and when – e.g. the user journey, screens and workflow;
The how – e.g. link to design, or needs to be designed based on X brand palette.
The most important thing here is to keep it simple. Go through each function or feature and list its specific requirements as clearly and concisely as possible. For the aforementioned payments function, you’d state what each component needs to do, where it sits in the app, when interactions will occur, and how it should look or function.
Next, it’s essential to understand the configuration of what is being built on. If the app is a new build, this may be an easier step that doesn’t add any constraints. But building on existing systems will almost certainly raise some limitations.
At this stage, the key information to include here should be:
What environment you’re using (e.g. on-premise, or a cloud-hosted such as AWS, Azure or GCP);
Whether you’re building on an existing code base, and if so its size, language and any preferred development frameworks;
Existing documentation of your app architecture;
An outline of your tech stack, integrations, API availability/maturity, and data schema.
A clear picture of the constraints faced helps developers to sharpen their thinking. The combination of sharing requirements at the previous stage to keep developers open-minded and creative, along with the technical parameters, helps to hone the solution in a targeted way.
As the final step, it’s important to explore what your quality assurance (QA) process will look like. To do this, you’ll need to note:
Whether you already have a user acceptance testing (UAT) process;
Any bugs to be aware of (or a bug list);
Whether you adhere to particular performance standards or guidelines.
Consider and note down all the types of testing required, whether functional (e.g. UAT, unit testing, interoperability, etc), non-functional (e.g. performance, endurance, scalability, etc) or maintenance.
Typically, code goes through three reviews – two phases of peer review and one check from the QA lead – before we move on to user/client acceptance testing (UAT/CAT).
Once you’ve been through these steps – balancing detail with simplicity and clarity – you’ll be on your way to creating a winning brief. If you need more help, feel free to download our briefing template here.
In part two of this series, we take a detailed look at the next part in our process – firming up Deliverables, Milestones and Acceptance Criteria.