Blame
|
1 | > **DRAFT** — under teacher review. |
||||||
| 2 | ||||||||
| 3 | # Scope vs Constraints — What's the Difference? |
|||||||
| 4 | ||||||||
|
5 | The Hamilton and Alexandra College · Year 12 · 2026 |
||||||
|
6 | |||||||
| 7 | In C3-1 interviews, students frequently say "we couldn't do X because of budget" and call it out-of-scope — when it is actually a constraint. These two concepts live in different sections of the SRS and serve different purposes. |
|||||||
| 8 | ||||||||
| 9 | --- |
|||||||
| 10 | ||||||||
| 11 | ## The one-sentence rule |
|||||||
| 12 | ||||||||
| 13 | | Concept | One-sentence definition | Where it lives in the SRS | |
|||||||
| 14 | |---|---|---| |
|||||||
| 15 | | **Scope** | What the solution **will and will not do** — the boundaries of the deliverable | SRS scope section; often expressed with MoSCoW | |
|||||||
| 16 | | **Constraint** | A **real-world limit** that restricts what can be done — budget, law, hardware, time | SRS constraints section; categorised (economic, legal, social, technical, usability) | |
|||||||
| 17 | ||||||||
| 18 | --- |
|||||||
| 19 | ||||||||
| 20 | ## The key distinction |
|||||||
| 21 | ||||||||
| 22 | **Scope** is about the solution's **boundary** — you are deciding, with the client, what features are in and out. You have some agency in this decision. |
|||||||
| 23 | ||||||||
| 24 | **Constraints** are **facts of the world** — limits imposed on the project by external realities. You cannot remove them by negotiating with the client. |
|||||||
| 25 | ||||||||
| 26 | > Budget, existing hardware, privacy law, school policy, and the six-week timeline are all constraints — they existed before you wrote a single line of requirements. |
|||||||
| 27 | > |
|||||||
| 28 | > Whether the app will support multiple languages or only English is a scope decision. |
|||||||
| 29 | ||||||||
| 30 | --- |
|||||||
| 31 | ||||||||
| 32 | ## Side-by-side: same project, two tables |
|||||||
| 33 | ||||||||
| 34 | The scenario: a school canteen ordering app. |
|||||||
| 35 | ||||||||
| 36 | ### Scope table (MoSCoW) |
|||||||
| 37 | ||||||||
| 38 | | Priority | Feature | In scope? | |
|||||||
| 39 | |---|---|---| |
|||||||
| 40 | | **Must** | Students can place a lunch order by 10 am | Yes | |
|||||||
| 41 | | **Must** | Staff can view and print daily orders | Yes | |
|||||||
| 42 | | **Should** | SMS notification when order is ready | Yes | |
|||||||
| 43 | | **Could** | Loyalty points system | No — out of scope | |
|||||||
| 44 | | **Won't** | Integration with the school's finance system | No — out of scope for this version | |
|||||||
| 45 | ||||||||
| 46 | The "Won't" and "Could (excluded)" items are **out of scope** — the team has decided not to include them in this version. |
|||||||
| 47 | ||||||||
| 48 | ### Constraints table |
|||||||
| 49 | ||||||||
| 50 | | Category | Constraint | |
|||||||
| 51 | |---|---| |
|||||||
| 52 | | **Economic** | Development must be completed with no additional software licences — free/open-source tools only. Budget for hosting is $0 (school server only). | |
|||||||
| 53 | | **Legal** | Must comply with the Privacy Act 1988 (Cth) — student names and order histories cannot be stored beyond 30 days without consent. | |
|||||||
| 54 | | **Social** | The canteen is staffed by volunteers with low technical confidence — the interface must require no training to operate. | |
|||||||
| 55 | | **Technical** | Must run in any modern web browser; school iPads run iOS 15. No native app — web-based only. | |
|||||||
| 56 | | **Usability** | Must be operable with one hand (to hold a tray) by primary-school users (Year 5+). | |
|||||||
| 57 | ||||||||
| 58 | --- |
|||||||
| 59 | ||||||||
| 60 | ## The test: budget as constraint, not scope |
|||||||
| 61 | ||||||||
| 62 | A very common error: |
|||||||
| 63 | ||||||||
| 64 | > ~~"The loyalty points system is out of scope because we don't have the budget to build it."~~ |
|||||||
| 65 | ||||||||
| 66 | Budget is a **constraint** (economic). The loyalty points system may be out of scope — but the reason it is out of scope is a separate matter. Write them separately: |
|||||||
| 67 | ||||||||
| 68 | - Constraints → "Economic constraint: development resources are limited to the 6-week timeline and free tools; no budget for third-party APIs." |
|||||||
| 69 | - Scope → "Won't: loyalty points system — excluded from this version to keep scope achievable within the economic constraint." |
|||||||
| 70 | ||||||||
| 71 | You can **cross-reference** them like that in your SRS. That is what the 9–10 band looks like. |
|||||||
| 72 | ||||||||
| 73 | --- |
|||||||
| 74 | ||||||||
| 75 | ## MoSCoW and constraints work together |
|||||||
| 76 | ||||||||
| 77 | MoSCoW is how you **communicate scope**. Constraints are the **reasons** some things end up in "Could" or "Won't". A strong SRS makes that link explicit — a "Won't" item that exists because of a legal or economic constraint should say so. |
|||||||
| 78 | ||||||||
| 79 | At **7–8** band, students describe scope and constraints separately but don't connect them. |
|||||||
| 80 | ||||||||
| 81 | At **9–10**, students show that the constraint drove the scope decision: *"The loyalty points system is classified as Won't due to the economic constraint — no budget for third-party payment processing or secure token storage within the project timeline."* |
|||||||
| 82 | ||||||||
| 83 | --- |
|||||||
| 84 | ||||||||
| 85 | ## Why VCAA cares |
|||||||
| 86 | ||||||||
| 87 | At **5–6**, the rubric requires you to *"document the constraints that may impact the development of the proposed solution"* and to *"describe the scope of the proposed software solution"*. These are two separate indicators — they must both appear in the SRS, in separate sections, clearly labelled. |
|||||||
| 88 | ||||||||
| 89 | Mixing them up (writing constraints under scope, or calling constraints "things we won't do") signals to the examiner that the student does not understand the analysis stage of the problem-solving methodology. |
|||||||
| 90 | ||||||||
| 91 | --- |
|||||||
| 92 | ||||||||
| 93 | ## See also |
|||||||
| 94 | ||||||||
| 95 | - [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — the other common C3-1 pair confusion |
|||||||
| 96 | - C03 Resources: [external reading and videos](/sd/Resources/C03-Resources) |
|||||||
| 97 | ||||||||
| 98 | --- |
|||||||
| 99 | ||||||||
| 100 | ← Back to [C03 Home](/sd/C03/C03-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
|||||||
