Tutorial 1: Requirements, Architecture, and Release Review

Unit 8 · Analysis, testing, and capstone

Objectives

Start with users, goals, constraints, and acceptance criteria. A useful architecture makes boundaries visible: browser, API, domain logic, persistence, external services, and operations. Each boundary should have an owner, contract, and failure behavior.

Requirement: A student can search courses by code.
Acceptance: A valid search returns matching results within 500 ms
and an empty search result explains what to try next.

Testing should cover units, integration boundaries, browser workflows, security controls, and accessibility. A release review is evidence-based: use tests, logs, measurements, threat-model checks, and playtest observations.

Exercises

  1. Write five user stories and acceptance criteria for a web system.
  2. Draw a component diagram and mark trust boundaries.
  3. Create a release checklist with rollback and monitoring steps.

Self-check

  1. What makes a requirement testable?
  2. Why mark trust boundaries?
  3. What evidence belongs in a release review?

Self-Check Quiz

1. What does an acceptance criterion describe?

AnswerObservable conditions that demonstrate a requirement has been met.

2. Why include failure behavior in architecture?

AnswerDistributed dependencies fail; explicit behavior prevents accidental outages and confusing user experiences.

Homework

  1. Plan a small web-system capstone with users, requirements, architecture, and risks.
  2. Define unit, integration, browser, security, and accessibility tests.
  3. Write a release-review report with three prioritized improvements.
Sample answerA strong capstone is narrowly scoped, names measurable acceptance criteria, documents data and trust boundaries, and includes a rollback plan. Priorities should be based on user impact and risk, supported by test results and observed behavior rather than feature novelty.
👤