MAIE6000C Chap.2 Requirements and System Decomposition
Requirements and System Decomposition
Scope is set here and rarely recovered later
The published framing for this week is that good projects start by framing the problem cleanly, designing a workflow that is realistic, and holding scope down, and that the task is reducing a sprawling or ill-defined operational problem to an engineering plan small enough that one complete path through it can actually run before the semester ends.
Every clause in that sentence is a constraint, and the last one is a deadline: whatever you choose has to be demonstrable by Week 7.
Six questions that come before any tool choice
Who the user is. What they are trying to get done. What arrives at the boundary. Which facts have to survive. What decision or result comes out. And how the system behaves when it is unsure or mistaken.
The sixth is the one teams answer last and it is the one that determines the shape of everything else, because it decides whether there is a review step, a fallback route, or a manual queue in the design at all.
The published problem-statement shape
For a named user, the system helps a named task by a specific workflow, so that a named operational value follows.
Around that sentence the course asks for operational context, a trigger event, what success looks like, and one or two explicit exclusions. The contrast it draws between weak and strong statements is not about length: a weak statement names a technology and a domain, while a strong one names who acts, on what, and what measurably changes.
You do not need the measurement to be right in Week 2, but the sentence needs a place where a number goes.
Functional and non-functional requirements
A functional requirement states what the system does, and the course gives a blunt test: they must contain verbs: store, classify, retrieve, create, accept, approve, override, notify, show, process and persist.
It attaches a second instruction that is easy to skim, which is not to confuse the AI step with the system. Non-functional requirements describe qualities, and the taught families are reliability, reproducibility, auditability, maintainability, security, privacy, throughput, latency, operability and cost.
The exercise asks for three of them, each with why it matters and what it implies for the build.
Entities, states and the four questions
The recurring candidate records are a submitted item, a processing job, an AI result and a review decision, and the taught lifecycle runs from submitted through queued and processing to completed, reviewed or error.
Four questions turn that into a schema: what exists immediately after submission, what exists after background processing, what exists after human review, and which states a reader can see once something has broken.
Teams that answer all four in Week 2 rarely rewrite their schema; teams that defer the fourth usually discover in Week 6 that failure has no state.
Scope cuts are graded evidence
The Week 4 proposal rubric carries a criterion on risks, assumptions and fallback thinking, and the course states directly that a scope cut is not a weakness but evidence that a team understands what must be postponed.
That changes how the proposal should read. A section naming three things you will not build, each with one sentence on why the project remains coherent without them, scores better than silence and protects you at the midterm when somebody asks why a feature is missing.
What this chapter covers
- 01
The six workflow questions that precede any tool choice
- 02
The published problem-statement shape and what makes one strong
- 03
Functional requirements, and why they must contain verbs
- 04
Ten non-functional families, and how to make one testable
- 05
The four candidate records and the lifecycle they move through
- 06
Four state questions that turn nouns into a schema
- 07
Buildability against novelty as the selection criterion
- 08
Risks, mitigations, and the first three scope cuts
Narrow a broad direction into a demonstrable slice
- 3Write the statement with a user, a task, a workflow and an operational value.
- 4Name the five slice elements in the order they occur.
- 2Give two cuts and say why the project stays coherent without them.
Key terms
- Problem Statement
- A single sentence naming the user, the task, the workflow and the operational value, around which context, trigger and exclusions are added.
- Functional Requirement
- A statement of what the system does, containing a verb and attached to an observable piece of evidence that somebody other than the author could check.
- Non-functional Requirement
- A statement about a quality the system should have, such as auditability or latency, made useful by a threshold and the population it applies to.
- Candidate Record
- A persistent entity identified during decomposition, named with its purpose and two or three likely attributes, before any table is designed.
- Trigger Event
- The occurrence that starts the workflow, which fixes what enters the system and therefore what the first stored record must contain.
- Observable Evidence
- The fourth column of the requirements table: what somebody could inspect to confirm that a requirement is met, without relying on the author's intention.
- Scope Cut
- A capability the team decides not to build, recorded with its reason, which the proposal rubric reads as evidence of judgement rather than as a shortfall.
- Buildability Checklist
- The eight questions used to compare candidate directions by whether they can be finished rather than by how interesting they sound.
Requirements and System Decomposition FAQ
How narrow should a semester project be?
Narrow enough that you can say in one sentence what you would show running at the midterm. The course frames this as specificity rather than modesty: a project with one clear user, one concrete workflow, one input and one bounded AI step can produce a demonstrable path within a fortnight and then has ten weeks to make it reliable.
A direction that covers several user groups or several workflows has no single path to demonstrate, so the midterm requirement for a live end-to-end run is unreachable. The published buildability checklist is the fastest test, and its last question asks what you will deliberately not build.
What makes a requirement testable rather than aspirational?
Somebody other than you has to be able to check it. The requirements table the course uses has a column for observable evidence for exactly this reason. If the requirement is that a reviewer can see why a decision was made, the evidence is a stored record containing the input, the proposal and the final decision. If it is that typical jobs finish inside a stated time, the evidence is a timestamped job record you can query.
A requirement whose only evidence is your intention cannot constrain the build and cannot be reported on in the final technical brief.
Do I lose marks for cutting features from my proposal?
The opposite, provided the cut is recorded with a reason. The Week 4 rubric includes a criterion on risks, assumptions and fallback thinking whose top band describes identifying important risks clearly and including credible fallback or scope-cut logic. The course states plainly that a scope cut is evidence that a team understands what must be postponed.
What loses marks is an unexplained absence, because a reviewer cannot distinguish a deliberate cut from work that was not finished. One sentence per cut is enough.
Assessment move
Write your problem statement, your five slice elements and your three scope cuts on one page, then show that page to somebody outside your team and ask them to tell you back what the system does. If they cannot, the statement is still describing a topic. Doing this in Week 2 costs twenty minutes; discovering it in Week 7 costs a milestone.
Working through Requirements and System Decomposition in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Requirements and System Decomposition question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
