I85PREP
⌘ K
Module 15 study materials
Module 15 study resources

Module 15: Fundamentals and Core Concepts

Module 15 · Work through your exam, one topic at a time.

All guide sections

Fundamentals and Core Concepts

This domain tests whether you can reason about a solution as a lifecycle system rather than a feature list. Questions target boundaries, requirement quality, constraints, trade-offs, and the feedback loops that keep a system fit for purpose.

Core rules

  • Define the system boundary and actors first. Anything outside the boundary is an external dependency with its own failure modes.
  • Separate functional requirements (what the system does) from non-functional requirements (how well: performance, availability, security, maintainability).
  • Every requirement needs a testable acceptance criterion: observable, measurable, and pass/fail.
  • Constraints are non-negotiable limits such as budget, regulation, or a legacy interface. Assumptions are beliefs to validate and retire.
  • Design is trade-off management, not maximization. Name the trade-off and the owner.
  • Keep one source of truth for data definitions, configuration, and decisions.
  • Model failure as normal: dependencies fail, data arrives late, humans err. Feedback loops close the gap.

Worked example

Statement: 'The portal must be fast.' That is not testable. Decompose it: actor = authenticated customer; action = load account summary; condition = peak hour at three times normal load; metric = p95 server response; threshold = under 800 ms; evidence = load test report. Resulting criterion: 'At 3x baseline request rate, p95 latency for GET /account/summary is under 800 ms with error rate under 0.5%, verified by a staging load test.' Reasoning: the criterion names the observable, the measurement, and the evidence. 'Fast' becomes a pass/fail gate.

Traps

  • Treating non-functional requirements as optional. They usually drive architecture and cost.
  • Writing acceptance criteria that cannot be observed, such as 'user-friendly', or measured only after go-live.
  • Confusing constraints with assumptions. Constraints are fixed inputs; assumptions must be tested.
  • Optimizing one dimension while silently degrading another, for example cutting latency by weakening security.

Key points

  • Boundaries and actors define scope and external dependencies.
  • Functional versus non-functional requirements drive different design decisions.
  • Acceptance criteria must be observable, measurable, and evidenced.
  • Constraints are fixed; assumptions must be validated.
  • Every design choice trades one quality against another.