007. the client brief: gathering requirements (ks4)
Learn to turn a client's vague 'cool website' idea into a solid technical plan.
If a client asks you to build a "cool website", how do you know what they actually want? In the professional tech world, guessing is a disaster. You need clear instructions. In this lesson, we will learn the art of gathering requirements. You will discover how to ask the right questions, transforming a client's vague ideas into a precise, actionable technical brief.
The Art of the Brief: From Vague Idea to Watertight Plan
The first meeting with a new client is often the most dangerous part of any software project. They have a brilliant idea, but they are not a technical expert. They use words like "user-friendly," "modern," and "engaging," but what do those words actually mean in practice? A programmer cannot write code to "make it cool." This is where the Systems Analyst comes in. Their job is to bridge the gap between the client's vision and the development team's reality.
The Analyst's Toolkit
The process of turning a vague idea into a solid plan is called requirements gathering. An analyst has several tools to do this. They might conduct detailed interviews with the client and their target users, asking probing questions to uncover the real needs. They could send out questionnaires to gather data from a wider group or even use observation, watching how people currently perform a task to see where the problems are.
The goal is to produce a technical specification or 'brief'. This is the master document that describes exactly what the software will do. This document is crucial because it becomes the single source of truth for the entire team.
Functional vs. Non-Functional
The technical specification is usually split into two key categories. Functional requirements define what the system must do. For example, "The user must be able to add an item to a shopping basket." This is a testable action.
Non-functional requirements define how the system must be. For example, "The website must load in under two seconds," or "The system must be secure against common cyber attacks." These are about quality and constraints. Getting both types of requirements right is essential. A website that lets you add items to a basket but takes a minute to load has failed. At the end of the process, the client must formally 'sign off' on the brief, agreeing that it perfectly captures their needs. Only then can the coding begin.
Plugged Task: The Vague Client
You are a Systems Analyst at a top digital agency. A new client, 'The Hungry Caterpillar Cafe', has sent you a very brief email asking for a new website. Your task is to transform their vague request into a professional, one-page technical brief that a development team could actually use.
The Persona
As The Analyst, your job is to think logically, ask critical questions, and bring structure to a chaotic situation. You are not building the website yourself; you are creating the perfect blueprint for the builders.
1
Read the client's email
Open a new word-processed document and copy the following 'client email' into it.
Subject: New Website!
Hi,
We're a small, friendly cafe and we need a new website to get more customers. We want it to look really professional and cool, and show off our amazing cakes. We also need people to be able to see our menu and find out where we are.
Can you help?
Thanks,
The Hungry Caterpillar Cafe
2
Formulate your questions
The client's email is very vague. Below the email in your document, create a new heading: `Clarifying Questions`. Write a list of at least five specific questions you would need to ask the client to get the detail you need. Think about things they have not mentioned.
Who is the target audience? (e.g., students, families, business people?)
Do you want to take online bookings?
What is your budget?
3
Define the requirements
Now, imagine the client has answered your questions. In your document, create a new heading: `Technical Specification`. Based on their original email and your own assumptions, write out a clear list of requirements for the new website.
Start by making a list of Functional Requirements - the things the website must do.
The website must have a homepage.
The homepage must display pictures of the cafe's cakes.
The website must have a 'Menu' page showing food and prices.
Learn more about Functional vs Non-Functional Requirements.
Next, make a list of Non-Functional Requirements - the qualities the website must have.
The website must load in under 3 seconds on a mobile device.
The design must be modern and reflect the cafe's friendly brand.
The website must be easy to navigate for non-technical users.
4
Create user stories
To help the developers understand the user's perspective, you will now write two 'user stories'. Create a new heading: `User Stories`. These must follow the strict format: "As a {user}, I want to {goal} so that {benefit}".
You are a computer science teacher. Explain what a user story is to a 15-year-old in under 70 words. Give one example for a cafe website. NO intro, NO outro, NO deviation from the topic, NO follow-up questions
Example: As a new customer, I want to find the cafe's opening hours so that I know when I can visit.
Outcome
Your final document should be a single, professional page.
It must contain the original email, a list of clarifying questions, and the technical specification.
The technical specification must be clearly separated into functional and non-functional requirements.
It must include at least two well-written user stories.
Unplugged Task: The App Blueprint
Based on the technical brief you created for 'The Hungry Caterpillar Cafe', it is time to think about the user interface. Don't worry about coding or graphic design - we are creating a blueprint.
Grab a piece of A4 paper and a pencil.
1
Divide the paper into three large sections. Each section will represent a screen on the cafe's new website: the Home page, the Menu page, and the Contact page.
2
For each screen, sketch a 'wireframe'. This is a very simple black-and-white layout diagram.
3
Use simple boxes and lines. Where will the cafe's logo go? Where will you put the navigation buttons? How will the menu be laid out - in a list or a grid?
4
Label each box clearly (e.g., "Image of cake", "Map", "Opening Times"). This is a low-fidelity prototype, focusing only on structure and user journey, not on colour or style.
Last modified: June 24th, 2026
