Welcome to Unit A2 2: Systems Analysis
Welcome to the first and most crucial stage of your Unit A2 2 Application Development portfolio! Unit A2 2 is an internally assessed, CCEA-moderated coursework component worth 20% of your total A Level (120 raw marks across approximately 60 hours of controlled assessment time).
Every year, CCEA releases a new pre-released case study describing a realistic business or organisational scenario (such as a farm, a musical equipment hire firm, or a holiday booking service). Your mission as a systems analyst is to investigate their existing setup, identify their headaches, and clearly map out what a brand-new database application needs to do.
Don't worry if this feels a bit overwhelming at first. Systems analysis is simply detective work: you investigate the scene, gather clues, and write down a clear plan of action.
1. What is Systems Analysis?
According to the British Computer Society (BCS) glossary, Systems Analysis is the formal process of investigating and studying an existing system (whether it is an inefficient paper-based system or an outdated legacy computer system) to evaluate how it works, pinpoint its limitations and bottlenecks, and establish the precise needs of users and clients to specify requirements for a replacement application.
Core Objectives of the Analysis Phase
When working through your pre-released case study, your analysis must accomplish four vital tasks:
1. Evaluate the Existing System: Understand the current operational workflows and examine how data moves through the business.
2. Identify Problems and Inefficiencies: Pinpoint bottlenecks, manual calculation errors, data duplication, slow turnaround times, and user frustration.
3. Extract User Requirements: Identify both the obvious (explicit) and hidden (implicit) needs of managers, staff, and customers.
4. Establish Constraints and Boundaries: Define the hardware, software, security, and operational limits of the proposed solution.
Analogy to remember: Think of an analyst like an architect. You cannot draw blueprints for a new house (Design) or start laying bricks (Implementation) until you have surveyed the ground and interviewed the family to find out how many bedrooms they need!
Key Takeaway: Analysis is about understanding what the problem is and what the new system must achieve before deciding how to build it.
2. Fact-Finding Techniques (Investigation Methods)
To design a successful application, an analyst must collect accurate information. CCEA specifies four standard fact-finding techniques that you must understand, compare, and apply to your case study scenario:
Method 1: Interviews
An interview is a direct, one-on-one conversation between the analyst and key stakeholders (such as business owners, office administrators, or department managers).
• Advantages: Provides rich, qualitative, in-depth detail. The analyst can immediately ask follow-up questions, probe vague responses, and observe non-verbal body language or hesitation.
• Disadvantages: Very time-consuming and expensive to conduct. It is vulnerable to interviewer bias and is completely impractical for collecting feedback from hundreds of users.
Method 2: Questionnaires and Surveys
Questionnaires are pre-written sets of open and closed questions distributed on paper or digitally (e.g., online forms) to a wider audience.
• Advantages: Highly cost-effective and fast. Ideal for gathering quantitative data from a large or geographically scattered group of users. Answers can be easily converted into graphs and statistical summaries.
• Disadvantages: Response rates are often notoriously low. Questions can be misunderstood, and there is no real-time opportunity to clarify ambiguous answers or probe deeper into interesting points.
Method 3: Observation
Observation involves the analyst watching staff members perform their daily jobs using the current system in their actual workplace environment.
• Advantages: Provides reliable, first-hand, unbiased evidence of day-to-day operations. It allows the analyst to see what users actually do in practice rather than what they say they do, revealing undocumented shortcuts and manual workarounds.
• Disadvantages: Can trigger the Hawthorne Effect (a psychological phenomenon where workers alter their normal behaviour, work more diligently, or follow rules more strictly because they know they are being watched). It is also time-consuming and might take place during an uncharacteristically quiet or chaotic day.
Method 4: Document Inspection / Record Sampling
This technique involves reviewing the physical and digital artefacts currently used by the organisation (such as paper order forms, invoices, receipts, manual stock record cards, Excel spreadsheets, and end-of-month printed summaries).
• Advantages: Gives exact, factual insight into the data fields needed, appropriate data types, field lengths, required validation rules, calculation formulas, and standard report layouts.
• Disadvantages: Existing paperwork may be outdated, filled with uncorrected legacy errors, or fail to document rare exceptions to standard procedures.
Memory Aid: The "I-Q-O-D" Detective Toolkit
Remember the four investigation methods using the acronym IQ-OD:
• I – Interview (talk to the bosses)
• Q – Questionnaire (survey the masses)
• O – Observation (watch the processes)
• D – Document Inspection (study the paperwork)
Key Takeaway: A thorough analyst never relies on a single technique. Using a blend of methods ensures both broad numerical trends and precise operational details are captured.
3. Identification & Classification of User Requirements
Once fact-finding is complete, the analyst collates their findings into a formal document known as the User Requirements Specification (URS). In Unit A2 2, you must classify these requirements using two distinct dimensions:
Dimension 1: Essential vs. Non-Essential (Desirable)
• Essential Requirements: Core functional features that the database application must provide to resolve the client's problems. Without these, the system is considered a failure (e.g., recording client bookings, automatically calculating totals with VAT, updating stock quantities, enforcing relational referential integrity, and printing booking invoices).
• Non-Essential / Desirable Requirements: Secondary features or enhancements that add convenience or aesthetic value, but are not strictly critical for basic day-to-day viability (e.g., exporting summaries to external spreadsheet software, custom colour skinning for user interfaces, or automated trend forecasting).
Dimension 2: Functional vs. Non-Functional / Environmental
• Functional Requirements: What the system must actively do. These detail the inputs, processing tasks, queries, calculations, validations, and outputs. For example:
– Input: Custom data entry forms with automated validation checks.
– Processing/Queries: Parameter queries, Make-Table queries, Update queries, and Append queries.
– Output: Professional grouped reports, client receipts, and monthly management summaries.
• Non-Functional / Environmental Requirements: The quality standards, operational boundaries, and security constraints of the system. For example:
– Security: Tiered password logins and user access privilege levels (e.g., manager vs. standard staff).
– Data Integrity: Automated backup routines and referential integrity enforcement.
– Performance & Usability: Clear navigation menus, consistent form layouts, and standard keyboard shortcuts.
– Hardware/Software Constraints: Operating system compatibility and target screen resolutions.
The Power of Traceability (Numbering Your Requirements)
Every single user requirement you write down in your Analysis section must be numbered and indexed (e.g., UR1, UR2, UR3...).
Why is this mandatory? In your A2 2 portfolio, every later section depends on this list:
• In Design, you show how your forms, queries, and reports address requirement UR1.
• In Testing, you test whether requirement UR1 works under normal, extreme, and erroneous conditions.
• In Evaluation, you create a final matrix categorising each requirement as Fully Met, Partially Met, or Not Met.
Key Takeaway: Clear, numbered user requirements create an unbreakable golden thread connecting your Analysis, Design, Testing, and Evaluation stages.
4. Common Pitfalls & Examiner Tips
To achieve top mark bands in your Analysis chapter, keep these examiner insights in mind:
• Avoid Vague Requirements: Never write ambiguous statements like "the system must be easy to use" or "the system must save money". These cannot be proven or tested! Instead, write clear, measurable statements: "The system must validate that hire dates are in the future and calculate total rental costs including standard rate VAT."
• Always Justify Your Classifications: Do not simply label a requirement as "Essential" or "Desirable" without explaining why. State why the business would fail or suffer without that feature.
• Contextualise to the Annual Case Study: Do not copy generic textbook descriptions. Tailor every requirement, field name, and business rule directly to the specific company, entities, and processes detailed in your official CCEA pre-released case study brief.
• Maintain Complete Traceability: Ensure you never invent new requirements later in the project that were not introduced during the Analysis stage.
Quick Review Quiz Checklist
Before moving on to the Design phase, ensure you can confidently answer the following:
1. Can you define Systems Analysis using formal BCS terminology?
2. Can you explain the difference between the Hawthorne Effect in observation and interviewer bias in interviews?
3. Why is Document Inspection particularly useful for designing database tables and validation rules?
4. What separates an Essential functional requirement from a Desirable non-functional requirement?
5. Why must every requirement have a unique reference code (e.g., UR1) for final portfolio evaluation?