📁 Paper 2 · 3.8 Software Development
3.8a Analysis & Design
AQA 8525 · GCSE Computer Science · ~12 min read
Notes
──
Video
──
Worksheet
──
Quiz

The Software Development Life Cycle (SDLC)

All software is developed through a structured process. The Software Development Life Cycle (SDLC) is a framework describing the stages from identifying a problem to delivering a working solution. AQA requires you to understand the analysis and design phases.

🔍
1
Analysis
📐
2
Design
💻
3
Implementation
🧪
4
Testing
📊
5
Evaluation

Stage 1: Analysis

The analysis stage establishes what the system needs to do. It begins with understanding the problem and identifying the stakeholders — anyone affected by or who will use the new system.

Requirements Gathering Methods

MethodDescriptionStrengthWeakness
InterviewsTalking directly to stakeholdersDetailed, qualitative informationTime-consuming; subjective
QuestionnairesWritten surveys sent to many usersReaches many people quicklyMay miss nuance; low response rates
ObservationWatching users perform current tasksReveals real workflow (not what they think they do)Time-consuming; Hawthorne effect
Document analysisReviewing existing forms, reportsReveals current data structuresMay miss unwritten processes

Functional vs Non-Functional Requirements

⚙️ Functional requirements

What the system MUST DO

  • The system must allow users to log in with a username and password
  • The system must display customer orders in date order
  • The system must send a confirmation email after purchase
  • The system must allow administrators to add and remove products

📋 Non-functional requirements

Constraints on HOW it must work

  • Performance — must load in under 2 seconds
  • Security — passwords must be hashed and salted
  • Usability — must be operable by non-technical users
  • Reliability — 99.9% uptime; maximum 8 hours downtime per year
  • Maintainability — code must be documented and modular

Stage 2: Design

The design stage determines how the system will meet the requirements. Good design produces a blueprint detailed enough for developers to implement without ambiguity.

Decomposition

Decomposition is the process of breaking a large, complex problem into smaller, more manageable sub-problems. Each sub-problem can then be solved independently. This is a fundamental technique in computational thinking.

Online Booking System
↓
User Authentication
Search & Browse
Booking & Payment
Confirmation & Email
Admin Dashboard

Abstraction

Abstraction means focusing on the essential features of a problem while ignoring irrelevant detail. At the design stage, this means capturing what information needs to flow through the system without specifying every line of code.

Design Notations

NotationUsed forExample use
Structure chartsShow hierarchical decomposition of a program — modules and sub-modulesShowing how a login module calls password validation and session creation
PseudocodeDescribe algorithms in plain language before coding; platform-independentWriting out the logic of a search algorithm
FlowchartsVisualise algorithms with decision branchesShowing the logic of a login validation with loops
Data flow diagramsShow how data moves between processes, data stores, and external entitiesShowing how customer data flows from form submission to database
PrototypesEarly working versions to demonstrate features and gather feedbackA clickable wireframe of an app for user testing

Prototyping

A prototype is an early, incomplete version of a system created to explore ideas and gather feedback before full implementation. Showing a prototype to stakeholders reveals misunderstandings about requirements early — when fixing them is cheap — rather than after full development.

Two types: throwaway prototyping (built quickly to test an idea, then discarded) and evolutionary prototyping (prototype is refined iteratively into the final product).

Exam tip: Know the difference between functional requirements ("what it does") and non-functional requirements ("how well it does it"). For design, know at least three notations and what each is used for. Decomposition and abstraction are computational thinking concepts — be ready to apply them to a given problem scenario.
⚠️ Common Mistakes
  • Confusing functional and non-functional requirements — "the system must log in users" = functional; "the login must take under 0.5 seconds" = non-functional (performance).
  • Saying analysis produces the design — analysis produces requirements; design produces the technical blueprint showing how to meet those requirements.
  • Saying prototypes are the final product — most prototypes are deliberately incomplete and may be thrown away after gathering feedback.
▶
Video coming soon

Key points

  • SDLC stages: analysis → design → implementation → testing → evaluation
  • Analysis: stakeholders, requirements gathering (interviews, questionnaires, observation)
  • Functional requirements = what the system does; non-functional = constraints (speed, security, reliability)
  • Design: decomposition (break problem down), abstraction (focus on essentials)
  • Design notations: structure charts, pseudocode, flowcharts, DFDs, prototypes
  • Prototyping: early incomplete version to test ideas and gather feedback
Click slide or press arrow keys to navigate
✍️

Worksheet — 3.8a Analysis & Design

8 questions · 20 marks

Q1State the five stages of the Software Development Life Cycle in order.[2]
✅ Mark scheme
Mark scheme
Analysis [1], Design, Implementation, Testing, Evaluation [1 for all four remaining in order].
Q2Explain the difference between functional and non-functional requirements. Give one example of each.[4]
✅ Mark scheme
Mark scheme
Functional requirements describe what the system must do — the specific behaviours and functions it must provide [1]; example: "the system must allow users to log in with a username and password" [1]; non-functional requirements describe how well the system performs — constraints on quality, performance, security, and other attributes [1]; example: "the login process must complete in under 0.5 seconds" / "passwords must be stored encrypted" / "the system must have 99.9% uptime" [1].
Q3Give one advantage and one disadvantage of using observation as a requirements-gathering method.[2]
✅ Mark scheme
Mark scheme
Advantage: observation reveals what users actually do — rather than what they think they do or describe in interviews; it captures real workflow including workarounds and informal processes that users may not think to mention [1]; disadvantage: it is time-consuming and may cause a Hawthorne effect (users change their behaviour when they know they are being observed, so the observed behaviour may not represent normal operation) [1].
Q4What is decomposition? Why is it useful in software development?[2]
✅ Mark scheme
Mark scheme
Decomposition is the process of breaking a large, complex problem into smaller, more manageable sub-problems [1]; it is useful because each sub-problem can be solved independently, different team members can work on different components simultaneously, each component can be tested separately, and the overall system becomes easier to understand, build, and maintain [1].
Q5What is abstraction in the context of software design?[2]
✅ Mark scheme
Mark scheme
Abstraction is the process of focusing on the essential features of a problem while ignoring irrelevant detail [1]; in software design this means capturing the key data, processes, and behaviours needed without specifying the implementation details — for example, designing a "sort data" function without yet deciding which sorting algorithm to use [1].
Q6Describe what a structure chart shows and how it helps in software design.[2]
✅ Mark scheme
Mark scheme
A structure chart shows the hierarchical organisation of a program — how it is broken down into modules and sub-modules, and how they call each other [1]; it helps in design because it makes clear the relationships between different parts of the system, supports parallel development by multiple programmers, and shows the overall architecture before any code is written [1].
Q7What is a prototype and how does it help the development process?[2]
✅ Mark scheme
Mark scheme
A prototype is an early, incomplete version of a system created to test ideas and demonstrate features to stakeholders [1]; it helps development by revealing misunderstandings about requirements at an early stage (when changes are cheap to make), enabling user feedback before full implementation, and allowing design decisions to be validated before committing to full development [1].
Q8Classify each of the following as either a functional (F) or non-functional (NF) requirement for a school management system, and briefly justify each: (a) The system must allow teachers to record student attendance. (b) The system must be accessible on mobile devices. (c) The system must respond to user actions within 1 second. (d) The system must generate end-of-term reports.[4]
✅ Mark scheme
Mark scheme
(a) F — Functional: this describes a specific behaviour the system must perform — recording attendance [1]; (b) NF — Non-functional (usability/compatibility): being accessible on mobile is a constraint on how the system works, not a specific behaviour [1 — accept performance or usability]; (c) NF — Non-functional (performance): the 1-second response time is a performance constraint, not a behaviour [1]; (d) F — Functional: generating reports is a specific function the system must perform [1].
✓
Check your answers above.
Topic Quiz
Q 1 of 10
You scored
out of 10
Card 1 of 8
Click to flip
🎉
All done!
TermDefinition
🎯

Mini Test — 3.8a Analysis & Design

Timed exam conditions.

  • 8 questions · 10 minutes
  • 5 MCQ + 3 short answer
← 3.7.2b Environmental
55 of 57 · AQA 8525
3.8b Development & Testing →