04 Quiz: Requirements Engineering

The lecture’s central message is that when you struggle to improve test coverage, you’re often encountering implicit or missing requirements. Questions like “What should happen when the ray is vertical?” reveal that you don’t know the expected behavior - that’s a requirements gap, not just a testing gap. You can’t write meaningful tests without knowing what “correct” behavior means.

Options A, B, and D describe what the system does - these are functional requirements. Option C describes how well the system does it (a quality attribute: performance). Non-functional requirements include categories like performance, security, usability, reliability, and maintainability. The 100ms response time is a performance constraint, not a feature.

Comments and docstrings are not enforced by the compiler or runtime - nothing forces them to stay synchronized with the code. When you refactor or add features, the docstring might not get updated, leaving you with documentation that lies about the actual behavior. This is why the lecture recommends encoding requirements in the type system where possible, and using tests as executable documentation.

By creating an Angle class that normalizes values to [0, 360) on construction, the requirement “angle must be in valid range” becomes impossible to violate. Angle(500) automatically becomes Angle(140). This is better than a comment that says “angle should be 0-360” because the type system enforces it - you can’t even represent an invalid angle. This is the principle of “making illegal states unrepresentable.”

Stakeholders include anyone affected by the system, which typically includes end users, customers/purchasers, developers, operations teams, business roles (product managers, marketing, support), and even regulators. The same feature looks different to different stakeholders - an intersection calculation is a measurement tool to the engineer, a cost saving to the manager, an algorithm to the developer, and a behavior to verify to QA.

Option B illustrates a genuine conflict: making something “trainable in under 1 hour” might favor a simpler interface with fewer options, while “modular architecture for testing” might add complexity that increases learning time. These are competing concerns from different stakeholder perspectives that need to be balanced. Option A describes complementary desires (no conflict), C shows alignment, and D is too vague to be a real requirement.

The “T” in INVEST stands for Testable, which is the criterion most directly tied to verification. If you can’t write a test for a requirement, you can’t objectively determine if it’s been met. This connects directly to the lecture’s core message: vague requirements like “user-friendly” need to be refined into testable criteria like “response time < 200ms” before they’re useful for development and verification.

Option C provides specific, measurable criteria: a defined user type (new user), a defined task (core workflow), a measurable outcome (within 5 minutes), and conditions (without training). You can write a test for this! Options A, B, and D remain vague and subjective - “very user-friendly,” “more than competitors,” and “enjoy” are not objectively measurable without further refinement.

Derived requirements (also called child requirements) are requirements that emerge from implementation decisions. When you decide to use ray-casting and return None for vertical rays, that becomes a derived requirement (REQ-GEOM-001) that your unit tests must verify. The stakeholder didn’t ask for this behavior specifically - it derived from your technical design choice. ISO/IEC/IEEE 29148 formally defines this term.

Stakeholder requirements like “load and calculate in under 2 seconds” are system-level concerns that span file I/O, state management, and calculation. The stakeholder doesn’t care about individual functions - they care about the whole experience. Unit tests verify derived requirements (implementation details like “vertical rays return None”), while module/E2E tests verify the stakeholder requirements. This is why the pyramid has few integration tests and many unit tests.

The User Story format “As a [role], I want [feature], so that [benefit]” captures WHO needs it (stakeholder), WHAT they need (the feature, not the solution), and WHY (the value it provides). Option A is more like a traditional requirement specification, Option C is the Given-When-Then format for acceptance criteria (not the story itself), and Option D is just a feature label.

Acceptance criteria turn vague user stories into testable specifications. The Given-When-Then format specifies exact scenarios: initial state, action, and expected outcome. These can even be executed as automated tests using tools like pytest-bdd. They’re not optional (D) - without acceptance criteria, you can’t objectively determine if a story is complete. They don’t specify implementation (B) - only behavior.