Analysis — AQA A-Level Computer Science
Analysis in AQA A-Level Computer Science is the foundational stage of the systems development lifecycle where a problem is identified, investigated, and decomposed into measurable functional and non-functional requirements. It requires gathering data from stakeholders using methods like interviews and observations to establish clear, testable success criteria for proposed computational solutions.
Analysis explained
Analysis is the first stage of the software development life cycle and it comes before any design or coding.
Read the full explanation
The statement sets out three things that must happen before a problem can be solved. First, the problem must be defined: you need a clear statement of what the system is meant to achieve, its boundaries, and what is out of scope, so that the solution is aimed at the right target. Second, the requirements of the system must be established: these are the things the finished system must do (functional requirements) and the qualities it must have (non-functional requirements such as speed, security or usability). Third, a data model must be created: this identifies the entities the system must store and process, their attributes, and the relationships between them, often shown as an entity-relationship diagram.
Your focus
- Be aware that before a problem can be solved, it must be defined, the requirements of the system that solves the problem must be established and a data model created.
Which command word is this?
Set out the causes, reasons, or mechanisms clearly with linking conjunctions, showing why a specific analysis technique or requirement type applies directly to the context given.
Analysis exam tips
Topic Overview
The analysis phase forms the bedrock of the Systems Development Life Cycle (SDLC) and Component 3 (NEA) in AQA A-Level Computer Science. It focuses on identifying a real-world problem, interrogating existing processes, and dissecting user requirements to verify that a computational solution is both technically viable and commercially necessary.
Mastery of this topic demands an understanding of computational methods, such as problem decomposition and abstraction, alongside practical requirement-gathering techniques like stakeholder interviews and document analysis. Establishing unambiguous, quantifiable success criteria at this stage ensures that downstream architectural design, coding, and iterative testing are robustly directed.
Key Concepts
- →Fact-Finding Methods: Systematically uncovering stakeholder needs via structured interviews, questionnaires, document inspection, and direct workplace observation.
- →Functional vs Non-Functional Requirements: Distinguishing between what a system must do (functions, inputs, outputs, database operations) and how it must perform (latency, security, concurrency, usability, compliance).
- →Problem Decomposition & Abstraction: Stripping away non-essential real-world nuances to isolate primary entities, data models, user roles, and algorithmic workflows.
- →Feasibility Analysis: Evaluating technical, economic, legal, operational, and schedule constraints before committing resources to development.
- →Measurable Success Criteria: Creating objective, testable statements that allow post-development evaluation to verify whether the system successfully solved the original problem.
Marking Points
- Identifies that the problem must be defined clearly before a solution is attempted
- Explains that requirements are the functions and qualities the system must have
- Describes a data model as the entities, attributes and relationships the system uses
- Recognises that all three activities belong to the analysis stage, before design
Examiner Tips
- 💡Use the three-part structure of the statement (define, establish requirements, create a data model) to organise your answer
- 💡When asked about a data model, name entities, attributes and relationships with an example
- 💡Keep analysis distinct from design by focusing on what the system must do rather than how it will do it
- 💡Tie requirements directly to verification: When outlining a requirement in an exam question or your NEA, ask yourself whether an automated unit test or concrete user acceptance test can objectively prove that the requirement has been satisfied.
- 💡Reference both operational and legal constraints: Examiners award top marks when students evaluate non-functional requirements such as Data Protection Act/GDPR compliance, network bandwidth limits, and automated backup redundancy alongside basic user-facing features.
Common Mistakes
- Treats analysis as the coding stage; correct the learner by placing analysis before design and implementation
- Lists requirements without linking them to the problem they solve; state each requirement as something the system must do for the defined problem
- Describes a data model as a list of data types only; explain that it shows entities and their relationships
- Believing that systems analysis merely involves asking a client what software they want, rather than independently auditing data flows, structural bottlenecks, and operational constraints.
- Defining success criteria with subjective descriptors such as 'user-friendly' or 'fast' instead of specifying measurable metrics such as maximum allowable error rates, WCAG accessibility tiers, or sub-two-second query latency.
- Assuming analysis ends before development starts in all paradigms; while Waterfall treats analysis as a strictly completed upfront stage, Agile lifecycles revisit and refine analysis iteratively across sprint backlogs.
Revision Plan
- 1Step 1: Construct a comparative matrix of the four core fact-finding methods (interviews, questionnaires, document review, observation), contrasting sample size, qualitative depth, cost, and typical sources of bias.
- 2Step 2: Practice categorising lists of requirements from past paper scenarios into functional and non-functional requirements, rewriting any vague statements into measurable criteria.
- 3Step 3: Analyze past AQA Paper 2 scenario questions on software engineering and SDLC methodologies to practice structuring 6-mark and 9-mark analytical responses.
- 4Step 4: Audit your NEA Component 3 Analysis section against the AQA mark band criteria, checking that user identification, data structures, and measurable objectives align seamlessly.
Exam Question Types
- 📋Scenario-Based Fact-Finding Questions (4-6 marks): Assessing which data collection methods are optimal for a specific organisation (e.g., healthcare, logistics, e-commerce) and explaining their trade-offs.
- 📋Requirement Classification & Formulation (2-4 marks): Requiring candidates to distinguish between functional and non-functional constraints or convert ambiguous client demands into formal requirements.
- 📋Methodology Comparison Essays (9-12 marks): Assessing how the depth and timing of the analysis stage diverge between Waterfall, Spiral, and Agile methodologies.
Command Word Expectations (AQA)
Set out the causes, reasons, or mechanisms clearly with linking conjunctions, showing why a specific analysis technique or requirement type applies directly to the context given.
Provide reasoned arguments and balanced evidence supporting why a chosen technique, metric, or boundary condition is the most appropriate compared to realistic alternatives.
Review multiple perspectives (such as benefits, drawbacks, resource implications, and technical feasibility) to reach a well-supported, authoritative final judgment.
How Students Lose Marks (Examiner Pitfalls)
Step-by-Step Worked Solutions
Question: A medical clinic relies on paper filing to book patient appointments and record prescriptions. An analyst has been hired to develop a bespoke digital appointment system. Discuss two suitable fact-finding methods the analyst should use during the analysis phase to determine system requirements, justifying your choices with reference to the clinic scenario. [6 marks]
- 1.Step 1: Identify and evaluate the first fact-finding method in context. Direct observation of reception staff managing incoming phone calls and physical paper diaries allows the analyst to see the genuine workflow, bottlenecks, and interruptions firsthand without relying on subjective staff recollections.
- 2.Step 2: Note limitations of the first method. Staff might alter their regular speed or adherence to protocol under observation (the Hawthorne effect), meaning edge cases might not occur during the observed period.
- 3.Step 3: Identify and evaluate the second fact-finding method in context. Semi-structured interviews with doctors and clinic managers enable the analyst to uncover complex scheduling constraints, privacy requirements (e.g., patient data confidentiality under data protection legislation), and administrative priorities.
- 4.Step 4: Note limitations of the second method and conclude. Interviews take key medical personnel away from patients, making them costly and difficult to schedule; however, pairing direct observation of daily operational workflows with targeted interviews of administrators ensures both procedural realities and strategic policy constraints are captured.
Question: During the analysis stage of developing an inventory management system for a boutique retailer, the analyst must establish the data requirements and processing rules. Explain how abstraction and problem decomposition are applied during this phase to formulate measurable system objectives. [6 marks]
- 1.Step 1: Define decomposition in the context of system analysis. Decomposition breaks the complex retail operation into distinct, manageable sub-problems, such as stock level tracking, automated re-ordering thresholds, point-of-sale updates, and supplier billing.
- 2.Step 2: Apply decomposition to formulate measurable objectives. Each decomposed component can be assigned explicit functional criteria (e.g., 'generate a purchase order when stock drops below 10 units').
- 3.Step 3: Define abstraction in the context of data modelling during analysis. Abstraction strips away irrelevant physical details (e.g., shelf color or exact box dimensions) to isolate core entities and computational data structures (e.g., ItemID, SKU, StockLevel, UnitCost, SupplierID).
- 4.Step 4: Synthesize how both computational methods lead to success criteria. Together, decomposition establishes modular functional requirements while abstraction defines relational data schemas, forming an unambiguous specification that dictates the testing strategy.