Criterion 1: Problem Decomposition (9 marks)
| Band | Marks | Descriptor |
|---|
| 1 | 1–3 | Identifies SOME problems, decomposes SOME |
| 2 | 4–6 | Identifies MOST problems, decomposes MOST |
| 3 | 7–9 | FULLY identifies ALL, effectively decomposes ALL |
Band 3 Example
Problem: "Provide customizable workout plans"
├─ User fitness level assessment
│ ├─ Input collection (age, weight, experience)
│ ├─ BMI/BMR calculation
│ └─ Fitness level categorisation
├─ Workout plan generation
│ ├─ Exercise database
│ ├─ Matching exercises to fitness level
│ ├─ Creating schedule
│ └─ Setting goals/targets
├─ Plan customisation interface
│ ├─ Exercise selection UI
│ ├─ Schedule modification
│ └─ Goal adjustment
└─ Progress tracking
├─ Workout completion recording
├─ Achievement calculation
└─ Progress visualisation
Criterion 2: Wider Issues (9 marks)
| Band | Marks | Descriptor |
|---|
| 1 | 1–3 | Limited reasoning, PARTIALLY justifies |
| 2 | 4–6 | Good reasoning, MOSTLY justifies |
| 3 | 7–9 | COMPREHENSIVE reasoning, FULLY justifies |
You must fully justify: how solution meets needs, how risks are mitigated, how regulations are addressed. All three. Comprehensively.
Risks to Cover
General: Data breaches, unauthorized access, data loss,
privacy misuse, user confusion, accessibility barriers
Context-specific: Incorrect health calculations, injury liability,
data sensitivity, overexertion, medical conditions
Regulations to Reference
GDPR (2018) — access, deletion, portability, consent, minimisation
Data Protection Act 2018 — UK-specific complement
WCAG 2.1 AA — perceivable, operable, understandable, robust
Copyright Act 1988 — asset licensing
Computer Misuse Act 1990 — security requirements
Equality Act 2010 — accessibility, non-discrimination
Criterion 3: Business Context (6 marks)
| Band | Marks | Descriptor |
|---|
| 1 | 1–2 | Basic definitions |
| 2 | 3–4 | Good, clear definitions |
| 3 | 5–6 | Comprehensive AND perceptive |
"Comprehensive & perceptive" means: don't just say what. Say what, why, how, acceptance criteria, and business value for every single requirement.
Criterion 4: Visual/Interface Design (6 marks)
Demonstrate sophisticated and highly effective use of layout, white space, visual hierarchy, and common conventions. Annotate every design decision.
Design Principles Checklist
- Professional spacing with clear grid system
- F-pattern or Z-pattern layout
- Clear importance levels (primary → secondary → tertiary)
- Logo top-left, nav expected location, search where expected
- Consistent typography, colours, imagery
- Responsive mockups (mobile + tablet + desktop)
Criterion 5: Algorithm Design (9 marks)
5 complex algorithms showing excellent decomposition, correct computational thinking, appropriate abstraction, well-structured pseudocode.
Algorithm Template
ALGORITHM: Name
// Purpose: What it does
// Input: What it takes
// Output: What it returns
// Complexity: O(?)
BEGIN
// Step 1: [clear description]
// Step 2: [with validation]
// Step 3: [error handling]
RETURN result
END
// Test Cases:
// 1. Normal: [input] → [expected output]
// 2. Boundary: [edge case] → [expected output]
// 3. Erroneous: [bad input] → [expected handling]
Criterion 6: Data Requirements (9 marks)
Complete ERD, detailed data dictionary, normalization to 3NF, security/integrity/performance considerations.
Data Dictionary Entry Template
TABLE: Users
Purpose: Store core user account information
Relationships: 1:1 User_Profiles, 1:N Workouts, 1:N Eating_Plans
| Field | Type | Size | Constraint | Default | Validation |
|---------------|-----------|------|---------------|---------|--------------------|
| user_id | INT | - | PK, NOT NULL | AUTO | Auto-increment |
| email | VARCHAR | 255 | UNIQUE, NN | - | Regex validated |
| password_hash | CHAR | 60 | NOT NULL | - | BCrypt, 12 rounds |
| account_type | ENUM | - | NOT NULL | 'free' | free/premium/admin |
INDEXES: PK(user_id), UNIQUE(email), INDEX(account_type)
SECURITY: password_hash never exposed in API, email masked in logs
GDPR: Soft delete → hard delete after 90 days, included in data export
Criterion 7: Test Strategy (6 marks)
Phase 1: Unit Tests → isolated components (2 days)
Phase 2: Integration Tests → component interactions (3 days)
Phase 3: System Tests → end-to-end scenarios (3 days)
Phase 4: UAT → real user testing (2 days)
Phase 5: Security & Performance → parallel with Phase 4 (2 days)
Each phase requires previous phase complete with 0 critical bugs.
Development Band 3 Requirements
Code Quality
- 2+ languages (front-end + back-end)
- Comments explain WHY, not just WHAT
- Consistent naming, modular structure, DRY
- Input validation on ALL user inputs
- SQL injection / XSS prevention
- Passwords hashed (BCrypt, 12 rounds)
- Error handling throughout
Development Log Template
Date: [date] | Session: [n] | Hours: [start–end]
PLANNED: [what you intended]
IMPLEMENTED: [what you did + screenshots]
CHALLENGES: [problems hit]
SOLUTIONS: [how you solved them]
CHANGES FROM DESIGN: [what changed + WHY]
TESTS CONDUCTED: [what you tested]
NEXT SESSION: [what's next]
Test Log Template
Test ID: T001
Date: [date]
Test: [description]
Data: Normal / Boundary / Erroneous
Input: [specific input]
Expected: [expected result]
Actual: [actual result]
Status: PASS / FAIL
Action: [if failed, what you did]
Retest: [result after fix]
Task 3A: Feedback & Evaluation
Stakeholders to Include
- Client (business perspective)
- End users — varied types (beginners, advanced, elderly, young)
- Technical reviewers
- Accessibility experts
Analysis Framework
1. Identify patterns & themes across all feedback
2. Evaluate against ORIGINAL requirements
3. Prioritise by impact × feasibility
4. Justify every decision with evidence
5. Create development plan:
SHORT-TERM (1–3 months)
MEDIUM-TERM (3–6 months)
LONG-TERM (6–12 months)
Each improvement: Description, Justification, Approach,
Resources, Timeline, Success Criteria