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

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.

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.