SDD  ·  Software Design & Development

Analysis and Requirements

Lesson SDD2 of 18 Approx 50 min Builds on SDD1 — Development Methodologies
Learning intentions
  • Understand what analysis is and why it happens first in software development
  • Identify the purpose of a programming problem
  • Identify the functional requirements of a program in terms of inputs, processes and outputs
Success criteria
  • I can write a clear purpose statement for a given programming problem
  • I can identify inputs, processes and outputs from a program description
  • I can complete a functional requirements table for an unfamiliar problem
  • I can explain why analysis is important before any design or coding begins
Warm up — recall from SDD1

These questions check what you remember from last lesson. It's fine if you're unsure — have a go first.

1. What is the correct order of the stages in the software development process?

2. The software development process is described as iterative. What does iterative mean?

3. Who typically carries out the analysis stage?

Key vocabulary

Analysis
The first stage of software development — working out what the program must do.
Purpose
A clear description of what the program is required to do and what it will be used for.
Functional requirements
A detailed list of every input, process and output a program must handle.
Input
Data that the program collects from the user.
Process
A calculation or transformation the program performs on data.
Output
A result, message or value the program displays to the user.
Systems analyst
The person who meets with clients to determine what the program needs to do.
Software specification
The formal document that records the agreed purpose and functional requirements.

Analysis and Requirements

What is analysis?

Analysis is the very first stage of the software development process. Before a single line of code is written — before any design work begins — a developer must fully understand what the program is supposed to do.

At this stage, a systems analyst works with the client (the person or organisation who wants the software) to investigate the problem. The analyst uses techniques such as interviews, questionnaires and observation of existing systems to gather information. The outcome of analysis is a clear understanding of the problem that everyone involved can agree on.

This matters because mistakes made at the analysis stage are expensive to fix later. If a developer spends weeks coding a program that solves the wrong problem, all of that work is wasted.

Purpose

The purpose is a short, clear statement that describes what the program is for and what it must do. It does not go into the technical details of how the program will work — that comes later in the design stage. A good purpose statement covers:

  • who will use the program
  • what data the program will work with
  • what the program will produce or display

Here is an example of a well-written purpose statement:

The operators of Edinburgh Castle would like a program developed that would allow their staff to enter the number of tickets sold each day. The program should then calculate and output the total number of visitors in a year and the average number of visitors per day, week and month.

Notice that this statement says nothing about variables, loops or data types. It describes the problem, not the solution.

Functional requirements

Once the purpose is agreed, the analyst breaks it down into functional requirements. These are the specific things the program must do, organised into three categories:

  • Inputs — data that the program collects from the user. For example: a number typed into a text box, a selection from a menu, or a value entered on a form.
  • Processes — calculations or operations the program performs on that data. For example: calculating a total, finding an average, or checking whether a value meets a condition.
  • Outputs — results or messages the program displays back to the user. For example: a calculated total shown on screen, a pass/fail message, or a formatted report.

Organising requirements this way forces the analyst to be precise. It also makes it easier to check later — during testing and evaluation — whether the finished program actually does what was agreed.

Why functional requirements matter

The functional requirements form part of the software specification — the contract between the client and the development team. If a feature is not in the specification, the developer is not expected to build it. If the finished program does not meet a requirement in the specification, the client can reject it.

This is why analysis must be thorough. A vague or incomplete specification leads to arguments, delays and wasted effort. Getting the analysis right at the start saves time and money throughout the entire project.

Worked examples

Example 1 — Edinburgh Castle ticket counter

Purpose: Staff enter the number of tickets sold each day. The program calculates total visitors in a year, and averages per day, week and month.

InputsProcessesOutputs
Number of days openCalculate total tickets soldTotal visitors
Number of tickets each dayCalculate average per dayAverage visitors per day
Calculate average per weekAverage visitors per week
Calculate average per monthAverage visitors per month
Example 2 — Rugby points calculator

Purpose: Accept the number of tries scored by each team. Calculate points (5 per try). Display a bonus message if a team scores more than 4 tries.

InputsProcessesOutputs
Home team triesCalculate home team pointsHome team points
Away team triesCalculate away team pointsAway team points
Check if home tries > 4Home bonus message (if applicable)
Check if away tries > 4Away bonus message (if applicable)
Example 3 — Tax calculator

Purpose: Calculate tax and national insurance for an employee. Tax is 20% of income. National Insurance is 7% of income above £10,000. Display both deductions and the remaining net pay.

InputsProcessesOutputs
Employee incomeCalculate tax (20% of income)Tax amount
Calculate NI (7% of income above £10,000)NI amount
Calculate net pay (income − tax − NI)Net pay
Now you try

A school canteen wants a simple program. The lunch supervisor will enter the number of meals sold on Monday, Tuesday, Wednesday, Thursday and Friday. The program should calculate the total meals sold across the week and the average number of meals sold per day. It should also display a message saying "Busy week!" if more than 500 meals were sold in total.

Complete the following:

  1. Write a purpose statement for this program.
  2. Complete a functional requirements table showing all inputs, processes and outputs.

Purpose: The school canteen requires a program that allows the lunch supervisor to enter the number of meals sold on each of the five days of the school week. The program should calculate and display the total meals sold and the daily average. It should also display a "Busy week!" message if the weekly total exceeds 500.

InputsProcessesOutputs
Meals sold on MondayCalculate total meals (Mon + Tue + Wed + Thu + Fri)Total meals sold
Meals sold on TuesdayCalculate average meals per day (total ÷ 5)Average meals per day
Meals sold on WednesdayCheck if total > 500"Busy week!" message (if applicable)
Meals sold on Thursday
Meals sold on Friday
Common mistakes
Confusing purpose with functional requirements. The purpose is one or two sentences describing the overall problem. Functional requirements are the detailed breakdown into inputs, processes and outputs. Don't list inputs and outputs inside your purpose statement.
Missing outputs. Pupils often list inputs and processes correctly but forget the outputs. Every process must produce something — if the program calculates an average, there must be an output that displays it.
Listing processes as outputs. "Calculate total" is a process. "Display total" or "Total meals sold" is the output. The process happens internally; the output is what the user sees.
Writing vague purpose statements. "The program will do calculations" is too vague. The purpose must name who uses the program, what data goes in, and what results come out.
Exam tip

In N5 exam questions, analysis questions give you a scenario and ask you to identify inputs, processes and outputs. Read the scenario carefully and look for three things: what data is typed in or entered (inputs), what the program works out from that data (processes), and what is shown on screen (outputs).

The answer is usually 2–3 marks — one for each correctly identified item. Examiners use words like "calculate", "work out" and "determine" to signal processes, and "display", "output" and "show" to signal outputs.

Task Set

Questions 1–5 are auto-checked. Questions 6–8 are self-marked — write your answer, then reveal the model answer to check your work.

1. What is the purpose of the analysis stage? TYPE 1

2. Which of the following is an example of a process? TYPE 1

3. Which of the following is an example of an input? TYPE 1

4. A purpose statement should: TYPE 1

5. A program asks the user to enter two numbers, multiplies them together, and displays the result. How many processes does this program have? TYPE 1

6. A fitness app allows a user to enter the number of minutes they exercised on each of the 7 days in a week. The app calculates the total exercise time for the week, the daily average, and displays a "Goal achieved!" message if the total is 150 minutes or more. Complete a functional requirements table for this program. TYPE 2

InputsProcessesOutputs
Minutes exercised on each day (7 inputs — one per day)Calculate weekly totalWeekly total exercise time
Calculate daily average (total ÷ 7)Daily average exercise time
Check if total ≥ 150"Goal achieved!" message (if applicable)

Award 1 mark for each correct row. Accept minor variations in wording.

7. A programmer has written this purpose statement: "The program will ask for a number and give an answer." Explain why this is a poor purpose statement, then rewrite it for a program that converts temperatures from Celsius to Fahrenheit. TYPE 2

Why it is poor: The statement is too vague — it does not say who will use the program, what data is being entered, what calculation is being performed, or what result is displayed.

Improved purpose statement: The program allows users to enter a temperature in degrees Celsius. It will calculate and display the equivalent temperature in degrees Fahrenheit.

Award 1 mark for identifying vagueness; 1 mark for naming the input specifically (Celsius temperature); 1 mark for naming the output specifically (Fahrenheit equivalent).

8. A small sports club wants a program to calculate prize money for their annual tournament. The club secretary will enter the total prize fund and the number of players who entered. First place receives 50% of the prize fund, second place receives 30%, and third place receives 20%. The program should display the prize money for each of the three places and the entry fee per player (total prize fund ÷ number of players). Write a purpose statement and complete a full functional requirements table for this program. TYPE 3

Purpose: A sports club requires a program that allows the club secretary to enter the total prize fund and the number of players who entered the tournament. The program will calculate and display the prize money for first, second and third place, as well as the entry fee per player.

InputsProcessesOutputs
Total prize fundCalculate 1st place prize (50% of fund)1st place prize money
Number of playersCalculate 2nd place prize (30% of fund)2nd place prize money
Calculate 3rd place prize (20% of fund)3rd place prize money
Calculate entry fee (total fund ÷ number of players)Entry fee per player

Purpose: 2 marks (must mention context + inputs + outputs). Inputs: 1 mark each (max 2). Processes: 1 mark each (max 3). Outputs: 1 mark each (max 3).

Teacher notes — Shift+T to hide

Suggested timing

Approximately 50 minutes: Warm up 5 min · Notes + examples 1–3 (20 min — model Example 1, pupils attempt Example 2 in pairs, reveal Example 3 together) · Now You Try 10 min individual then reveal · Task set remaining time. Questions 6–8 work well as homework if time is short.

Lesson context

This is lesson 2 of SDD. Pupils have covered the development process stages in SDD1 and should be familiar with the term "analysis". This lesson goes deeper on what analysis actually produces: a purpose statement and a functional requirements table.

Common pupil errors (from SQA marking)

  • Pupils write "calculate and display total" as a single output rather than separating the process (calculate) from the output (display / total shown on screen)
  • Pupils confuse "purpose" with "functional requirements" — worth spending time on this distinction explicitly
  • In extended questions (Q8 type), pupils often identify only 2 of 4 processes — remind them to look for every separate calculation mentioned in the scenario

Exam question mapping

Analysis questions appear in SQA past papers at: 2025 Q10(a), 2024 Q9(a), SQP Q11(a), 2023 Q9(a), 2023 Q11(a), 2022 Q8(a), 2019 Q13(a), 2018 Q19(a).

Assignment relevance

Analysis is worth 0–5 marks in the SDD assignment task. Pupils who write vague purpose statements or miss outputs lose easy marks here. Refer back to this lesson before the assignment window.

SQA command words covered

"Identify" (inputs/processes/outputs), "Complete" (functional requirements table), "Write" (purpose statement).