DDD1 — Analysis: end-user and functional requirements
📅 To be scheduled
⏱ ~50–60 minutes · single period
Learning intentions
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.
Success criteria
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.
Warm up — what do you already know?
Answer before the lesson begins — it's fine if you're unsure.
WU1
1. In SDD2 you met the term "functional requirement". Which of these best matches how it was used there?
WU2
2. National 5 recap: a single piece of information about a specific object (for example, one member's surname) is called a ___.
WU3
3. A sports club receptionist says: "I need to check whether a member has any overdue fees before letting them book a class." Who is this comment really about?
Key vocabulary
End-user requirement
A statement of what a person using the system needs to be able to do — written from the point of view of the user's task.
Functional requirement
A statement of what the database itself must do — the queries, calculations, and data-handling processes it must support.
Stakeholder
Anyone with an interest in the finished database — for example a member of staff who will use it, or a manager who needs reports from it.
Entity
A person, place, thing, event or concept that the database needs to store data about — for example Member, Class, or Booking.
Relational database
A database made up of linked tables, where records in one table can be connected to records in another using keys.
Query
A request for the database to retrieve, sort, calculate, or change specific information.
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 describe a job someone has to get done. A useful sentence frame is: "The user must be able to [see / sort / add / change / remove] <specific detail from the scenario>." The 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: what must the database actually be able to process? This is where the requirement starts pointing toward SQL, without writing any SQL yet. A useful sentence frame is: "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 these 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.
Reception staff
I need to see the full booking history for a member, including which classes they've attended.
Reception staff
Members often ask which classes still have spaces before a certain day of the week.
Club manager
I have to check whether an instructor is qualified before assigning them a new class.
Club manager
I'd like to know the average fee per session across all our classes.
Reception staff
When someone signs up, I need to add them to the system straight away.
Club manager
Show me a list of members sorted by the date they joined, oldest first.
Worked examples
Example 1 — Writing an end-user requirement
Stakeholder comment: "I have to check whether an instructor is qualified before assigning them a new class."
Step 1
Who is speaking?The club manager — a person doing a task, not the system itself.
↓
Step 2
Choose the verbThey need to see a specific piece of information (whether the instructor is qualified) before doing something else.
↓
Step 3
Add scenario detailName the exact field involved — qualified — rather than saying "instructor information" vaguely.
↓
Result
End-user requirement"The user must be able to see whether an instructor is qualified before assigning them to a class."
Example 2 — Writing a functional requirement
Stakeholder comment: "I'd like to know the average fee per session across all our classes."
1
This comment is aimed at the system — it's asking for a calculation the database must be able to produce, not describing a task a person carries out step by step.
2
The word "average" points directly to an aggregate function — this is a calculation requirement, not a simple retrieval.
3
Name the exact field the calculation applies to — feePerSession from the Class entity — rather than "class information".
✓
Functional requirement: "The database must have a query to calculate the average fee per session across all classes."
Example 3 — One comment, two requirements
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:
Same comment — different requirement depending on who it's written forreception staff comment
End-user requirement"The user must be able to see which classes have spaces available before a given day."
Functional requirement"The database must have a query to select classes with available spaces (bookings below capacity) and a search date before a given day of the week."
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.
Now you try
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: "The user 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."
⚠️ Common mistakes — examiner feedback
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.
📝 Exam tip
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 must be able to..." 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.
Task Set B — Core questions
Work through all questions. Written answers use self-assessment — compare with the model answer.
B1
Fill the gap: an end-user requirement describes what a ___ needs to be able to do.
B2
Which of these is written as a functional requirement, not an end-user requirement?
B3
Fill the gap: a functional requirement describes what the ___ itself must be able to do.
B4
An instructor says: "I need to know the total number of members booked into my class before it starts." Which SQL feature does this functional requirement point toward?
B5
The club manager says: "I want to see the class timetable in order, Monday first." Write an end-user requirement for this comment.
Model answer
B6
Using the same comment as B5 ("I want to see the class timetable in order, Monday first."), write a functional requirement instead.
Model answer
B7
Explain, in your own words, why a real database problem usually needs both end-user requirements and functional requirements, using the sports club scenario as your example.
Model answer
B8
Which of these statements is too vague to be a good functional requirement?
B9
A stakeholder says: "I need to remove a member from the system if they cancel their membership." Which SQL statement (covered in DDD9) does this functional requirement point toward?
Task Set C — Extension · Beyond the specification
Optional challenge questions. Not required for your exam.
C1
Why might a badly-written, vague requirement cause real problems later in the DDD9 (SQL implementation) and DDD10 (testing/evaluation) stages, not just at the analysis stage itself?
One possible answer
C2
Invent one new, original stakeholder comment for the Craigmillar Community Sports Club scenario (not one already used in this lesson), then write both an end-user and a functional requirement for it.
One possible answer
C3
Looking back at the stakeholder comments in this lesson's notes, how many separate entities do you think the finished database will need, and which one do you think exists mainly to link two of the others together?
One possible answer
📁 File this in OneNote under: Higher Computing Science → Database Design & Development → DDD1
📌 Teacher notes — Shift+T to hide
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 write a functional requirement in end-user language (or vice versa) without noticing — get them to physically check which sentence frame they used before moving on. The B2/B8 questions are designed to catch this directly.
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.