Analysis of the problem — OCR A-Level Computer Science Revision

    This topic focuses on the initial phase of the non-exam assessment (NEA) programming project, requiring learners to identify and justify a problem suitable

    Topic Synopsis

    This topic focuses on the initial phase of the non-exam assessment (NEA) programming project, requiring learners to identify and justify a problem suitable for a computational solution. It involves researching the problem, identifying stakeholders, and specifying measurable success criteria and requirements for the proposed system.

    Key Concepts & Core Principles

    Exam Tips & Revision Strategies

    Common Misconceptions & Mistakes to Avoid

    Examiner Marking Points

    Analysis of the problem

    OCR
    A-Level

    This topic focuses on the initial phase of the non-exam assessment (NEA) programming project, requiring learners to identify and justify a problem suitable for a computational solution. It involves researching the problem, identifying stakeholders, and specifying measurable success criteria and requirements for the proposed system.

    0
    Objectives
    5
    Exam Tips
    5
    Pitfalls
    0
    Key Terms
    8
    Mark Points

    Topic Overview

    Analysis of the problem is the foundational first stage of the software development lifecycle, where the developer works with the client to understand exactly what the new system must achieve. This phase involves defining the problem scope, identifying user requirements, and establishing measurable success criteria. In the OCR A-Level Computer Science specification, this topic is critical because a flawed analysis leads to wasted time and resources in later stages, such as design and implementation. Students must learn to distinguish between functional requirements (what the system must do) and non-functional requirements (how the system should perform, e.g., speed, security).

    The analysis phase typically includes fact-finding techniques such as interviews, questionnaires, observation, and document analysis. Each method has strengths and weaknesses: interviews provide rich, detailed data but are time-consuming, while questionnaires can reach many users but may lack depth. Students should understand how to select appropriate techniques based on the project context. Additionally, the output of analysis includes a requirements specification document, which serves as a contract between the client and developer. This document must be clear, unambiguous, and agreed upon before any design work begins.

    Mastering problem analysis is essential because it directly influences the quality of the final software. A thorough analysis reduces the risk of costly changes later and ensures the system meets user needs. In exams, students are often asked to evaluate fact-finding methods or propose suitable techniques for a given scenario. Understanding the trade-offs between different approaches and being able to justify choices is key to achieving high marks.

    Key Concepts

    Core ideas you must understand for this topic

    • →Functional vs non-functional requirements: Functional requirements describe specific behaviours or functions (e.g., 'the system must calculate VAT'), while non-functional requirements define quality attributes (e.g., 'the system must respond within 2 seconds').
    • →Fact-finding techniques: Interviews, questionnaires, observation, and document analysis. Each has advantages and disadvantages regarding cost, time, depth of data, and potential bias.
    • →Requirements specification: A formal document that lists all agreed requirements, serving as a reference for design, testing, and acceptance. It must be clear, complete, and consistent.
    • →Stakeholders: Individuals or groups affected by the system (e.g., end-users, managers, IT staff). Identifying all stakeholders ensures no critical requirements are missed.
    • →Feasibility study: A preliminary investigation to determine if the project is technically, economically, and operationally viable before committing resources.

    What You Need to Demonstrate

    Key skills and knowledge for this topic

    • Description and justification of features making the problem solvable by computational methods.
    • Explanation of why the problem is amenable to a computational approach.
    • Identification and description of stakeholders and their specific needs.
    • In-depth research into the problem and existing solutions to justify the chosen approach.
    • Identification and description of essential features of the proposed solution with justifications.
    • Explanation of limitations of the proposed solution with justifications.
    • Specification and justification of solution requirements, including hardware and software.
    • Identification and justification of measurable success criteria.

    Marking Points

    Key points examiners look for in your answers

    • Description and justification of features making the problem solvable by computational methods.
    • Explanation of why the problem is amenable to a computational approach.
    • Identification and description of stakeholders and their specific needs.
    • In-depth research into the problem and existing solutions to justify the chosen approach.
    • Identification and description of essential features of the proposed solution with justifications.
    • Explanation of limitations of the proposed solution with justifications.
    • Specification and justification of solution requirements, including hardware and software.
    • Identification and justification of measurable success criteria.

    Examiner Tips

    Expert advice for maximising your marks

    • 💡Ensure the problem chosen is non-trivial and allows for a substantial coded element.
    • 💡Use the command words in the assessment criteria to drive the depth of your evidence.
    • 💡Ensure all evidence is authentic and individual to the learner.
    • 💡Focus on justifying decisions made during the analysis phase, not just describing them.
    • 💡Ensure the problem is well-defined and user-driven.
    • 💡When evaluating fact-finding methods, always compare at least two techniques and justify which is more suitable for the given scenario. Use specific criteria such as cost, time, depth of data, and user availability.
    • 💡In exam questions that ask you to 'analyse the problem', ensure you mention both functional and non-functional requirements. Many students focus only on functional ones and lose marks.
    • 💡Remember that the output of analysis is a requirements specification, not a design. Avoid discussing algorithms or data structures in your answer unless the question explicitly asks for design aspects.

    Common Mistakes

    Pitfalls to avoid in your exam answers

    • Choosing a problem that is too trivial to demonstrate the required range of skills.
    • Failing to justify why the problem is suitable for a computational approach.
    • Lack of depth in researching existing solutions.
    • Defining success criteria that are not measurable.
    • Failing to link the proposed solution features back to the identified stakeholder needs.
    • Misconception: Analysis is just about asking users what they want. Correction: Users often don't know what they need or may give contradictory information. Analysis involves interpreting, clarifying, and prioritising requirements, not just recording them.
    • Misconception: The requirements specification is fixed once written. Correction: Requirements can evolve, but changes should be managed through a formal change control process to avoid scope creep. However, the initial specification should be as complete as possible.
    • Misconception: All fact-finding methods are equally useful. Correction: The choice depends on the context. For example, observation is good for understanding current workflows but may not reveal user preferences; interviews are better for exploring complex issues.

    Frequently Asked Questions

    Common questions students ask about this topic

    Before You Start

    Prior knowledge that will help with this topic

    • •Basic understanding of the software development lifecycle (SDLC) and its stages (analysis, design, implementation, testing, maintenance).
    • •Familiarity with the concept of a 'system' and the difference between manual and computer-based systems.
    • •Knowledge of what a stakeholder is and why their input matters in system development.

    Likely Command Words

    How questions on this topic are typically asked

    Describe
    Justify
    Explain
    Identify
    Specify

    Ready to test yourself?

    Practice questions tailored to this topic

    Related Topics in OCR A-Level Computer Science

    Algorithms

    View Topic

    Applications Generation

    View Topic

    Boolean Algebra

    View Topic

    Compression, Encryption and Hashing

    View Topic