This was written entirely with AI.
One page for the exam. It has the exam template
(what each question asks and how to spend the time) and a
template for each question type. Each chapter’s
Quick reference feeds the section for that chapter. Each
section comes from the Quick reference and the
Exam patterns of its chapter.
Exam template
| Time | 2 hours, 4 questions of 25 marks. About 30 minutes for each question, so about 1 minute for each mark. |
| Project description | Appendix A on the last page. Every paper has one. Read it first: it feeds Q1 to Q3. |
| Q1 | Use case model. Use case diagram (10–19 marks). Use case description (6–8). Sometimes an activity diagram. Some papers start with stakeholders, FRs and NFRs (AY24/25 S2: 10 marks). |
| Q2 | Conceptual class diagram (8–9), state machine or dialog map (4–8), Waterfall vs Agile (3–5), Scrum situation or calculation (5–8). Sometimes an activity diagram with swimlanes (7–8). |
| Q3 | (a) architecture and detailed class diagram (8), the one NFR and an alternative architecture (8). (b) a scenario with more than one design pattern (6), evaluate patterns (3). |
| Q4 | Testing: equivalence classes, boundary values, defensive test cases (about 4–8 marks each), and a discussion part (testing levels, maintenance, shift left, LLM testing). |
Before each question. Underline in Appendix A: each actor (people, devices, other systems), each function (verbs), each limit (words such as “only”, “within”, “at least”, “must always”), each stored thing (nouns). The limits are the NFR clues.
Count what is asked. “THREE and THREE for 6 marks” is six one-line items. Marks show how much to write.
Requirements (Part 2)
Answer templates
| Question | Template |
|---|---|
| Stakeholders (4 marks for 4) | Table: stakeholder · interest (what they want) · concern (what they fear). Take each from a sentence of Appendix A. |
| List FRs | “The system must + verb + object.” One verb, one line. Take the verbs that Appendix A states firmly. |
| List NFRs | Category · clue (quote) · requirement with a number. Say that numbers are assumptions. |
| “The one NFR” (Q3a) | Pick the category with the strongest clue. Quote it. One sentence with a number. Then design for it. |
| Atomise | Mark verbs → conditions → data lists. One “must” sentence each. Number it as a hierarchy. Give each leaf a one-line test. |
| Make verifiable | Vague word → number, range, time or exact message |
| Elicitation technique | Name + a scenario where it fits (observation: replacing a manual process. Prototype: unsure about the UI. Interview: unsure of the exact demands. Workshop: groups disagree) |
Facts
| FR / NFR test | “must do X” = FR. “must be X” or “X within Y” = NFR. |
| NFR categories | Usability, reliability, performance, supportability, security, availability, scalability, maintainability |
| Clue → category | login, role, authenticated, log → security. real-time, within → performance. no downtime, 24 hours → availability. flexibly adapt, at least N, new types → supportability. many users → scalability. user-friendly → usability. |
| Good requirement | Atomic (one thing) · verifiable (pass or fail) · traceable (unique number, forward and backward) · “must” · active voice |
| Elicitation | Interview · observation · workshop · legacy product study · competitive product study · prototype |
| Validation | Review (walkthrough, inspection, critical review; checklist: complete, consistent, unambiguous, correct) or prototype (storyboard, still images, interactive) |
| Data dictionary | Problem-domain terms only. Types, ranges, allowed values. No implementation terms. |
| Unclear point | TBD, then ask the client. Never guess. |
| Traps | “should” is not “must”. “fast” has no number. A topic (“authentication”) is not a requirement. One sentence with two functions is two requirements. |
Use case model (Part 3)
Q1 is the largest block of marks: the diagram gets 10 to 19 of the 25, the description about 7.
Use case diagram: 8 steps
- Actors. Each human, device and external system in the description. The system is never one.
- One use case for each goal. Verb + noun. Take each from a function in the description.
- Boundary. A rectangle with the system name, round all use cases. Actors outside.
- Plain solid lines from each actor to the use cases it starts or takes part in. No arrows, no labels.
<<include>>for a step that is always needed (login, check access, log activity). Dashed, base → included.<<extend>>for a step that happens only if a condition holds (clarify an unclear command, handle a network fault). Dashed, extending → base. Write the condition and the extension point.- Generalisation (hollow triangle, special → general) where two actors share use cases.
- Check. Every use case comes from the description. No data flow. No order of steps.
| Clue | Draw |
|---|---|
| always, must first, before, for every, shared step | include |
| if, only when, optionally, when there is a problem | extend |
Use case description
Give exactly the fields that the question lists. Usually: actors, preconditions, flow of events, alternative flows.
- Mark the initiating actor (NULL if a system event starts it).
- Numbered steps. Actor step, then system step.
- Alternative flow:
AF-S<n>: if …, its own numbered steps, return to step m. - Exception
EX<n>: the use case ends. - Show an include as a step: “The system uses the included use case X.”
- Use the terms of the description.
Facts
| Include | Base always runs it. Base is not complete without it. Decomposition or reuse. |
| Extend | Base is complete alone. Extension is exceptional and has a condition and an extension point. |
| Actor | Role outside the system: human, device, external system |
| Traps | System as an actor. A missing device. Arrows reversed. Extend with no condition. Exception written as an alternative flow. An invented use case. |
Conceptual class diagram, Q2(a) (Part 5)
- Only the function that the question names.
- Boundary for each human actor (a UI) and for each device or external system (an interface).
- Control for each use case. Entity for each stored noun.
- Show the stereotype of every class. No attributes or operations unless asked.
- Links: actor → boundary → control → entity. A control may call a boundary to a device. No boundary–entity. No boundary–boundary.
- Entity associations with multiplicities (read the far end). Generalisation for “kinds of”.
- Label dependencies:
<<call>>,<<read>>,<<write>>,<<signal>>,<<create>>.
| Aggregation | Hollow diamond at the whole. The part lives on. |
| Composition | Filled diamond. The parts die with the whole. |
| Generalisation | Solid line, hollow triangle at the parent |
| Realisation | Dashed line, hollow triangle at the interface |
| Dependency | Dashed line, open arrow |
State machine and activity diagram (Part 6)
State machine (one object). States are conditions
that last (Idle, Active), never verbs. Start node; end
node if it ends. Label event [guard] / action. Add
entry /, do /, exit / where it
helps. Every non-final state has a way out. Guards cover every case and
do not overlap. A dialog map is a state machine of
screens: a composite state holds a group of forms, and an arrow from its
border means “from any sub-state”.
Activity diagram with swimlanes. One lane for each actor, the system and each device or external system. Start in the lane of the initiator. Decision (diamond): a guard on every outgoing arrow. Fork (bar): all paths at once. Join (bar): waits for all. Merge (diamond): continues on any. End node.
Waterfall versus Agile, Scrum (Parts 7 and 8)
Compare. Use the headings that the question gives. One advantage of each.
| Waterfall | Agile | |
|---|---|---|
| Flexibility | Low. Each phase is fixed. | High. The backlog changes every sprint. |
| Customer | Start and end | Throughout |
| Delivery | One, at the end | Small, every 2–4 weeks |
| Advantage | Easy to manage. Clear milestones. | Quick response to change. Early feedback. |
A change in requirements. Waterfall: assess impact → formal change request → update SRS, design, code, tests in order → re-plan. Agile: product owner changes the backlog → new priority → a later sprint → review.
Scrum. PO owns the product backlog. Scrum Master removes impediments and does not assign work. Development Team (5–9) owns the sprint backlog. Sprint 2–4 weeks, goal fixed. Daily Scrum 15 min. Review 1 h × weeks. Retrospective 45 min × weeks. DEEP backlog. INVEST stories.
| Calculation | Formula |
|---|---|
| Velocity | points ÷ sprints (an average, in points, not hours) |
| Sprints | ⌈points ÷ velocity⌉ (round up) |
| Cost | sprints × (PO + SM + developers) × cost per member per sprint |
| Sprint problem | Fix |
|---|---|
| Commits to more than its velocity | Plan with the measured velocity |
| Items too large or unclear | Refine the backlog. Split. Add acceptance criteria. |
| Scope changes in the sprint | New requests go to the product backlog |
| Customer unhappy | Gather gaps at the review. Re-prioritise with the PO. Involve the customer in refinement. |
Architecture, patterns, MVC: Q3 (Parts 9 to 11)
Q3(a)(i) Architecture and detailed class diagram
- Name the style (layered, or MVC for many UIs or views) and justify it with a fact of the description.
- Draw the layers: Presentation (boundary), Application Logic (control), Persistent Data (entity).
- Key attributes with types (from the data dictionary) and methods (from the use case steps).
- Dependencies go down only, to the next layer. A UI never calls an entity. Add multiplicities.
- Interfaces where the design must be flexible.
Q3(a)(ii) One NFR and an alternative architecture
- Name the NFR and quote the clue. 2. Say why the first design is weak. 3. Propose the alternative and say how it meets the NFR.
| NFR | Alternative |
|---|---|
| Many users | Client–server, replicated servers, load balancer |
| Always available | Redundant servers, replicated database |
| Real-time updates | Event-based, or MVC with Observer |
| Security | A security layer or authentication server |
| Extensibility | Interfaces + Strategy + Factory |
| Many UIs | MVC |
Q3(b) Patterns
Answer order: design problem → pattern → class diagram with the role of each class.
| Pattern | Use when | Roles |
|---|---|---|
| Strategy | One thing is done in several interchangeable ways | Context, Strategy, ConcreteStrategy |
| Observer | One-to-many notification | Subject (register, unregister, notify), Observer (update). Pull, push, or both. |
| Factory | Something must choose and create the concrete class | Factory (create), product interface |
| Façade | A complex subsystem needs one simple interface | Façade, subsystem classes |
Scenario with more than one pattern: a feature with a notify problem (Observer), a vary problem (Strategy) and a create problem (Factory). Evaluate patterns: agree in part. They give loose coupling and flexibility when the problem is real, and cost classes and indirection when it is not.
MVC: model = subject. Views observe it (Observer). Each view has a controller (Strategy). Pros: simultaneous development, many views, high cohesion, low coupling. Cons: hard to learn, three artifacts to keep consistent.
Testing: Q4 (Part 12 and Part 1)
(a)(i) Equivalence classes
For each input, range (one valid, two invalid) or discrete set (one valid, one invalid). Write your assumptions (sign, leading zeros, inclusive limits, empty value).
(a)(ii) Boundary values
For each boundary of each range: just below, on, just above, in the right unit. A discrete input has none.
(a)(iii) Defensive test cases
One table: a column for each input, then the expected result. Valid rows first, with the valid boundary values. Then one invalid input per row, from each invalid class and boundary.
Discussion parts
| Topic | Answer |
|---|---|
| Levels | Unit (one class, developer) · integration (interfaces) · system (whole system, NFRs, test team) · acceptance (customer) |
| Late faults | Cost 15–20 times more in test and over 100 times in operation, so test and review early (shift left) |
| Maintenance | People (understanding, morale, priority) and technical (documents, code, tests, hardware). Remedies: up-to-date documents, reviews, automated regression tests, change control. |
| White box | Basis paths: CC = E − N + 2 = decisions + 1, one test for each path |