How is a project judged feasible, and how are requirements gathered and recorded?
The purpose and types of feasibility (technical, economic, legal, operational and schedule), fact-finding techniques for requirements gathering, and functional and non-functional requirements.
A CCEA A-Level Digital Technology answer on the feasibility study (technical, economic, legal, operational and schedule), fact-finding techniques for gathering requirements, and the difference between functional and non-functional requirements.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
CCEA wants you to explain the purpose and types of a feasibility study, describe how requirements are gathered through fact-finding, and distinguish functional from non-functional requirements. These are the activities of the early life-cycle stages, and they decide what the system must do before any design begins.
The feasibility study
CCEA expects the five recognised types:
- Technical feasibility. Can the system be built and run with the available hardware, software and technical skills?
- Economic feasibility. Do the expected benefits justify the cost, judged with a cost-benefit analysis?
- Legal feasibility. Does the system comply with relevant law, for example data protection and copyright?
- Operational feasibility. Will the organisation and its staff accept the system and use it effectively, fitting their working practices?
- Schedule (time) feasibility. Can the system be delivered within the required timescale?
Fact-finding (requirements gathering)
Once a project is judged feasible, the analyst gathers requirements using fact-finding techniques. The main ones are interviews (rich detail, but time-consuming), questionnaires (reach many people cheaply, but shallow), observation (shows what users actually do, not just what they say), and inspection of existing documents and records (reveals current data and rules). These are covered in depth in the investigation dot point; the point here is that the requirements specification is built from this evidence.
Functional and non-functional requirements
The distinction matters because a system that does everything it should (functional) but is too slow, insecure or hard to use (non-functional) still fails its users. Both kinds are recorded, and both are later tested.
How this feeds the next stage
The requirements specification produced here is the input to design. Clear, testable requirements make design and later testing straightforward; vague requirements (for example "the system should be fast") cannot be tested and lead to disputes. Good non-functional requirements are measurable, such as "respond within two seconds for 95 percent of requests".
Try this
Q1. Name the document produced at the end of a feasibility study. [1 mark]
- Cue. The feasibility report.
Q2. Give one functional and one non-functional requirement for a school registration system. [2 marks]
- Cue. Functional: the system records each pupil as present or absent. Non-functional: the register must be completed in under a minute, or only authorised staff may mark the register.
Q3. Explain why economic feasibility uses a cost-benefit analysis. [2 marks]
- Cue. It compares the total expected costs against the expected benefits so the organisation can judge whether the system gives value for money before committing funds.
Exam-style practice questions
Practice questions written in the style of CCEA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
CCEA AS 15 marksDescribe the different types of feasibility a feasibility study should consider.Show worked answer →
List the recognised types and define each in a sentence; CCEA expects the five-way breakdown.
Technical feasibility: can the system be built with available hardware, software and skills. Economic feasibility: do the benefits justify the cost, judged with a cost-benefit analysis. Legal feasibility: does the system comply with the law, for example data protection and copyright. Operational feasibility: will the organisation and its staff accept and use the system effectively. Schedule (time) feasibility: can the system be delivered within the required timescale.
Markers award one mark per type correctly named and explained. Naming a type without explaining it, or merging two types into one vague point, limits the marks. A strong answer also states that the study ends in a feasibility report recommending whether to proceed.
CCEA AS 14 marksDistinguish between functional and non-functional requirements, giving an example of each.Show worked answer →
Define both and make the contrast explicit, then give a concrete example of each.
A functional requirement states what the system must do, a specific behaviour or feature, for example the system must let a member reserve a book online. A non-functional requirement states a quality or constraint on how the system performs, for example the reservation page must load within two seconds, or the system must be available 99 percent of the time.
Markers reward the core distinction (what it does versus how well or under what constraint it does it) plus one valid example of each. Giving two functional examples, or describing a non-functional requirement as just another feature, loses the example mark for that type.
Related dot points
- The stages of the systems development life cycle, the activities carried out in each stage and the documented outputs each stage hands on to the next.
A CCEA A-Level Digital Technology answer on the systems development life cycle: its stages from feasibility through analysis, design, implementation, testing and maintenance, the activities in each, and the documents each stage produces.
- The waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, advantages, disadvantages and the situations that suit each.
A CCEA A-Level Digital Technology answer comparing the waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, strengths, weaknesses and the projects that suit each approach.
- Designing the inputs, outputs, processing, data storage and user interface of a system, and the design tools used: data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
A CCEA A-Level Digital Technology answer on the design stage: specifying inputs, outputs, processing, data storage and the user interface, and the design tools used including data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
- The fact-finding techniques used during investigation: interviews, questionnaires, observation and inspection of documents, with the advantages and disadvantages of each.
A CCEA A-Level Digital Technology answer on the fact-finding techniques used during system investigation: interviews, questionnaires, observation and document inspection, with the advantages, disadvantages and suitability of each.
- The purpose and contents of technical documentation and user documentation, and the audience each serves during development, use and maintenance.
A CCEA A-Level Digital Technology answer on system documentation: the purpose, contents and audience of technical documentation and user documentation, and why each matters during development, use and maintenance.
Sources & how we know this
- CCEA GCE Digital Technology specification — CCEA (2016)