Solution requirements for QCE Digital Solutions Unit 3
“Identify and specify the functional and non-functional requirements, constraints and data requirements of a real-world problem to define the scope of a digital solution”
Requirements specify what a solution must do and how well; functional requirements are the actions and features the solution must perform, non-functional requirements are quality attributes such as performance, security and usability, and constraints are the fixed limits (time, budget, platform); together with the data requirements they define the scope against which the solution is later evaluated.
Jump to a section
What this dot point is asking
Before designing or coding, QCAA wants you to define exactly what the solution must do and the conditions it must satisfy. Requirements describe the needed capabilities and qualities of the solution; constraints are the limits you must work within; scope is the boundary of what is and is not included. This is the foundation of Unit 3 because every design decision, and every later evaluation, is judged against these requirements. Weak requirements are the most common reason an otherwise good IA1 loses marks.
Functional requirements
A functional requirement is a specific behaviour or feature the solution must provide, usually phrased as something a user can do. They describe what the system does.
- The system shall allow a teacher to record a student's mark for an assessment.
- The system shall generate a report of class averages by subject.
- The system shall let a user search students by name or ID.
Each functional requirement should be specific, testable and traceable, so you can later point to the feature that meets it and the test that proves it.
Non-functional requirements
A non-functional requirement is a quality the solution must have, describing how well it works rather than what it does. Common categories:
- Performance: a search returns results within two seconds.
- Usability: a new user can record a mark without training.
- Accessibility: the interface meets WCAG AA.
- Security: passwords are stored hashed, not in plain text.
- Reliability and maintainability: the solution handles invalid input without crashing.
Non-functional requirements are easy to forget and heavily rewarded, because they show you understand quality, not just features.
A client says they want an easy app to track club memberships. Translated:
- Functional: add a member, renew a membership, mark a member inactive, list members due to renew this month.
- Non-functional: a volunteer can add a member in under a minute (usability), member data is validated on entry (integrity), the member list loads in under two seconds for 500 members (performance).
- Data: each member has a name, join date, expiry date and status.
The vague brief becomes a checklist you can design to and test against, which is exactly what IA1 markers look for.
Constraints
Constraints are fixed limits outside your control that shape the solution. They include time and budget, the chosen platform or language, available data, legal obligations (privacy law), and the skills of the users. A constraint is different from a requirement: a requirement is something the solution must achieve, while a constraint is a boundary it must stay within. Naming constraints shows you understand the real context and explains why your design made the trade-offs it did.
Data requirements
Data requirements specify what data the solution must store, where it comes from, and the rules it must obey. This feeds directly into your data structures and database design: each entity, its attributes, their types, and the validation rules. Identifying data requirements early prevents the common failure of designing an interface for data the database was never set up to hold.
Scope
Scope is the agreed boundary of the project. A clear scope statement says what is included and, just as importantly, what is excluded (out of scope). Defining scope prevents scope creep, the gradual addition of features that derails timelines. In a school project, narrow, well-justified scope usually scores better than an over-ambitious solution that is half finished.
How requirements anchor assessment
In IA1 you investigate the problem and specify requirements, then justify your design against them. In IA2 you evaluate the finished solution by testing each functional requirement and assessing each non-functional one. Because evaluation is requirement-by-requirement, vague requirements make a strong evaluation impossible. Write them specific and testable from the start so the whole project chains together.
- Mixing functional and non-functional. Record a mark is functional; record it within two seconds is non-functional. Keep them in separate lists.
- Unmeasurable requirements. Be fast is not testable; respond within two seconds is.
- Ignoring non-functional requirements. Listing only features misses the quality attributes that markers reward.
- Confusing constraints with requirements. A constraint is a limit you work within; a requirement is something you must deliver.
- No defined exclusions. Without out-of-scope statements, the project balloons and is never finished.
Exam-style questions
Questions in the style of QCAA exam questions on this dot point, each with a worked answer. They are written by ExamExplained unless tagged "Past paper"; the year shows the paper a question is modelled on.
Practice8 marksFor a tutoring centre that wants an app to book sessions, analyse the scenario to identify two functional and two non-functional requirements, and justify why distinguishing them matters when defining the scope of the solution.Show worked answer →
An 8 mark analyse-and-justify answer rewards correctly classified requirements drawn from the scenario.
Functional requirements (what the system does): allow a student to book an available session; allow staff to view the day's bookings. Non-functional requirements (how well it does it): respond within two seconds; restrict booking access to authenticated users.
Justify: functional requirements define the features that must be built and tested, while non-functional requirements set the quality, performance and security the solution must meet. Separating them keeps the scope clear, prevents quality goals being mistaken for features, and gives measurable criteria for later evaluation. Markers reward correct classification tied to the scenario and a clear reason the distinction shapes scope.
Practice4 marksExplain the role of constraints in defining the scope of a digital solution, and give two examples of constraints a school project might face.Show worked answer →
A 4 mark explain answer needs the function of constraints plus examples.
Constraints are the fixed limits the solution must work within, so they bound the scope by ruling out options that cannot be delivered. Examples: a time constraint (the project must be finished in one term) and a technology constraint (it must run on the school's existing devices or a specified language).
Markers reward defining constraints as limits that shape scope and two plausible, distinct examples such as time, budget, hardware or platform.