DDD1 — Analysis: end-user and functional requirements
- I can identify the end-user requirements of a database problem.
- I can identify the functional requirements of a database problem.
- I can write clear, specific requirement statements from a stakeholder's comments.
- I can explain the difference between an end-user requirement and a functional requirement.
- I can read a stakeholder's comment and decide which type of requirement it describes.
- I can write both types of requirement for a new database scenario, using specific detail from the scenario rather than vague statements.
Answer before the lesson begins — it's fine if you're unsure.
Key vocabulary
Analysing a database problem
Why analysis comes first
Before any table can be designed, any query written, or any data entered, the people building a database need to know exactly what it's for. Analysis is the stage where that gets nailed down. For the Higher DDD unit, analysis means one specific thing: identifying the end-user requirements and functional requirements of the problem. Everything built later in this unit — the entity-relationship diagram in DDD2/3, the data dictionary in DDD4/5, the query designs in DDD6, and every SQL statement from DDD7 onward — exists to satisfy the requirements written down at this stage. If the analysis is vague or incomplete, every later stage inherits that vagueness.
End-user requirements — what people need to do
An end-user requirement describes a task from the point of view of the person doing it. It's written in human, task-focused language: what does a receptionist, instructor, or manager need to be able to see, sort, add, change, or remove using the system? End-user requirements don't mention tables, fields, or SQL keywords — they identify which user has a job to get done. A useful sentence frame is: "The [receptionist / manager / instructor] must be able to [see / sort / add / change / remove] <specific detail from the scenario>." The role and bracketed verb should always match what the stakeholder actually said, and the detail should be specific to the scenario, not generic.
Functional requirements — what the database must do
A functional requirement describes the same underlying need, but from the system's side: the processes the database must carry out and the information it must store. This is where the requirement starts pointing toward the data and processing needed, without designing tables or writing SQL yet. Useful sentence frames are: "The database must store <specific information>" and "The database must have a query to [select / order / insert / update / delete] <specific detail>" — or, when a calculation is involved (a Higher-level addition beyond National 5), "...to calculate the [minimum / maximum / average / total / number of] <specific detail>." Notice how closely the process verbs already map onto SQL: select and order point to SELECT/ORDER BY (DDD7), insert/update/delete point directly to those SQL statements (DDD9), and the calculation words point to aggregate functions like MIN, MAX, AVG, SUM, and COUNT (DDD8).
The same comment, read two ways
Often a single comment from a stakeholder contains both kinds of requirement at once — one aimed at the person, one aimed at the system. Learning to spot both readings in the same sentence is the core skill of this lesson, and it's exactly what the worked examples below practise.
The scenario for this unit — Craigmillar Community Sports Club
Every lesson in the Database Design & Development unit builds the same database, so that each new skill — ER diagrams, data dictionaries, and SQL — is applied to data you already understand rather than a fresh scenario every time. The scenario is a (fictional) local sports club that runs fitness classes. It needs to keep track of its members, the classes it runs, the instructors who teach them, and the bookings members make onto classes. That's four entities — comfortably over the minimum of three the Higher course requires — and it's genuinely relational: a class has one instructor but many bookings, and a member can book many different classes over time.
Worked examples
Stakeholder comment: "I have to check whether an instructor is qualified before assigning them a new class."
qualified — rather than saying "instructor information" vaguely.Stakeholder comment: "I'd like to know the average fee per session across all our classes."
feePerSession from the Class entity — rather than "class information".Stakeholder comment: "Members often ask which classes still have spaces before a certain day of the week."
This single comment actually contains two separate requirements, depending on which side of the interaction you focus on:
reception staff comment
Notice the functional requirement is more technical and already hints at what the query will need to compare — bookings against capacity — even though no SQL has been written yet. That comparison is exactly what DDD6's query design and DDD7's WHERE clause will build on.
A reception staff member says: "When someone signs up, I need to add them to the system straight away."
Write both:
- An end-user requirement for this comment.
- A functional requirement for this comment.
- End-user requirement: "Reception staff must be able to add a new member's details to the system."
- Functional requirement: "The database must have a query to insert a new member record, including their name, address, and date joined."
- Mixing up the two types. Writing "The database must be able to see which instructors are qualified" uses functional-requirement phrasing for what is really an end-user task, or vice versa. Check which sentence frame you're using and stay consistent with it.
- Being too vague. "The database must store member information" doesn't name a field, an action, or a specific need — it could apply to almost any database. Always tie the requirement back to something the stakeholder actually said.
- Skipping the calculation verb. If a stakeholder asks for an average, total, minimum, maximum, or count, the functional requirement should say so explicitly ("calculate the average...") rather than just "display fee information" — the calculation is the whole point of the requirement.
- Designing too early. Writing out table names, field lists, or SQL keywords at the analysis stage jumps ahead to DDD2–9. Analysis only needs to state what is needed, not how the database will be built to provide it.
Questions on this topic usually use the command word "identify" — this means state clearly and specifically, without a long explanation. A one-sentence requirement using the correct frame ("The [user role] must be able to...", "The database must store...", or "The database must have a query to...") and naming a specific detail from the scenario is exactly what's expected. Don't pad the answer with justification unless the question specifically asks you to explain or justify.
📁 File this in OneNote under:
Higher Computing Science → Database Design & Development → DDD1
Suggested timing: 8 min warm up · 15 min notes & scenario introduction · 12 min worked examples · 5 min now you try · 20 min Task Set B · 5–10 min Task Set C / review, if time allows.
Key misconception: pupils often omit the specific user role, or treat functional requirements as queries only and miss the information to be stored. Get them to check the role-and-task frame and both functional components before moving on.
Live demo suggestion: read out 2–3 more stakeholder-style comments live (inventing your own, in the same sports-club scenario) and cold-call pupils to classify end-user vs functional before they see the worked examples — this primes the distinction before it's formally taught.
SQA command words covered: "identify" (state clearly and specifically — see the exam tip box).
Extension suggestion: pupils who finish Task Set C early could sketch (in words, not a diagram yet) what fields each of the four entities might need — this previews DDD4's data dictionary without pre-empting DDD2's ER diagram notation.
Scenario note: the Craigmillar Community Sports Club scenario is used across all of DDD1–11 (see ddd/DDD.md §4) — it is not a real club, invented specifically for this course, and mirrors the structural shape (four entities, one resolving a many-to-many relationship) of SQA's own official worked exemplar in the course specification appendices.