Analysis of the problem — OCR A-Level Computer Science

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.

• →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.

• 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.

• 💡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.

• 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.