04 Quiz: Requirements Engineering
December 2025 (1821 Words, 11 Minutes)
New: Interactive Quiz Available!
Want to track your progress and get instant feedback? Try our new interactive version with progress tracking, immediate explanations, and score calculation.
Instructions
- This quiz tests your understanding of key concepts from Chapter 04 (From Tests to Specifications)
- Each question has 4 options with exactly one correct answer
- Try to answer without referring to the lecture materials
- Focus on understanding concepts, not memorizing details
Question 1: The Core Problem
In Chapter 04 (Requirements Engineering), we discovered that coverage gaps in tests often reveal something more fundamental. What do coverage gaps typically indicate?
A) The code is too complex and needs refactoring
B) Requirements gaps - you can’t write good tests if you don’t know what the software should do
C) The testing framework is misconfigured
D) The developers are lazy and haven’t written enough tests
Show Answer
Correct Answer: B
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.
Question 2: Functional vs Non-Functional Requirements
Which of the following is a NON-FUNCTIONAL requirement for a Road Profile Viewer?
A) “The system shall load road profile data from CSV files”
B) “The system shall display the road profile as a 2D line chart”
C) “The UI shall update within 100ms after user input”
D) “The system shall calculate and highlight the intersection point”
Show Answer
Correct Answer: C
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.
Question 3: The Problem with Comments
The lecture argues against using comments/docstrings as the primary way to document Design by Contract requirements. What is the MAIN problem with this approach?
A) Comments take up too much disk space
B) Comments can become outdated and lie about the actual code behavior
C) Comments are not visible in the IDE
D) Comments slow down code execution
Show Answer
Correct Answer: B
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.
Question 4: Type System as Requirements Enforcement
How does using an Angle class instead of a raw float for angle_degrees help enforce requirements?
A) It makes the code run faster through compiler optimizations
B) It encodes the valid range constraint directly in the type, making it impossible to violate
C) It allows the angle to be any value without restrictions
D) It removes the need for any testing
Show Answer
Correct Answer: B
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.”
Question 5: Stakeholder Definition
According to the lecture, who qualifies as a stakeholder?
A) Only the people who pay for the software
B) Only the end users who interact with the system daily
C) Any person or organization that has an interest in or is affected by the system
D) Only the development team building the software
Show Answer
Correct Answer: C
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.
Question 6: Stakeholder Conflicts
The Road Profile Viewer has different stakeholders with potentially conflicting requirements. Which scenario best illustrates a stakeholder conflict?
A) The road engineer wants accurate measurements AND fast calculations
B) The lab manager wants “trainable in under 1 hour” but the developer wants “modular architecture for testing”
C) The IT admin and the safety officer both want documentation
D) All stakeholders agree the system should work correctly
Show Answer
Correct Answer: B
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.
Question 7: The INVEST Criteria
Which INVEST criterion is most directly connected to our ability to verify that a requirement is met?
A) Independent - can be implemented without depending on other stories
B) Negotiable - details can be discussed
C) Testable - has clear criteria for “done”
D) Small - can be completed in one sprint
Show Answer
Correct Answer: C
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.
Question 8: Testable Requirements
“The system should be user-friendly” is considered a poor requirement. Which of the following would be a testable refinement?
A) “The system should be very user-friendly”
B) “The system should be more user-friendly than competitors”
C) “A new user shall complete the core workflow within 5 minutes without training”
D) “Users should enjoy using the system”
Show Answer
Correct Answer: C
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.
Question 9: Implementation Decisions
When implementing a stakeholder requirement like “Calculate intersection point,” developers make design decisions that create new requirements. What are these called?
A) Hidden requirements
B) Derived requirements
C) Optional requirements
D) Legacy requirements
Show Answer
Correct Answer: B
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.
Question 10: Testing Pyramid and Requirements
Why are stakeholder requirements typically tested at the module/E2E level rather than with unit tests?
A) Unit tests are too fast to test stakeholder requirements
B) Stakeholder requirements span multiple components and concern the system’s observable behavior
C) Unit tests can only test non-functional requirements
D) Module/E2E tests are cheaper to write than unit tests
Show Answer
Correct Answer: B
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.
Question 11: User Story Format
What is the correct format for a User Story?
A) “The system shall [do something] when [condition] with [parameters]”
B) “As a [role], I want [feature], so that [benefit]”
C) “Given [context], When [action], Then [outcome]”
D) “Feature [name]: Description of functionality”
Show Answer
Correct Answer: B
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.
Question 12: Acceptance Criteria Purpose
What role do Acceptance Criteria (Given-When-Then) play in requirements engineering?
A) They replace the need for any other documentation
B) They specify the exact code implementation to use
C) They define specific, testable conditions that must be met for a user story to be “done”
D) They are optional decorations for user stories
Show Answer
Correct Answer: C
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.
Scoring Guide
- 11-12 correct: Excellent! You have a strong grasp of requirements engineering concepts and their connection to testing
- 8-10 correct: Good understanding! Review the areas you missed, particularly the connections between requirements, stakeholders, and testing
- 5-7 correct: Fair understanding. Revisit the lecture sections on INVEST criteria, derived requirements, and the testing pyramid
- Below 5: Please review the lecture carefully. Focus on understanding why requirements engineering matters and how it connects to the testing concepts from previous lectures. Reach out if you need clarification!
Key Takeaways to Remember
- Coverage Gaps = Requirements Gaps - When you can’t write tests, you often don’t know what the software should do
- Functional vs Non-Functional - FR describes what the system does, NFR describes how well it does it
- Comments Lie - Document requirements in the type system or tests, not just comments that can become outdated
- Type System Enforcement - Better data types can make invalid states impossible to represent
- Stakeholders Are Everyone Affected - Not just users and customers, but developers, ops, regulators, and more
- Stakeholder Conflicts Are Normal - Different perspectives lead to competing requirements that must be balanced
- Testable is Critical - If you can’t write a test for it, it’s not a good requirement (the T in INVEST)
- Derived Requirements - Implementation decisions create new requirements that unit tests verify
- Pyramid Makes Sense - Stakeholder requirements → module/E2E tests; Derived requirements → unit tests
- Traceability is Bidirectional - You should be able to trace from requirement to test AND from test to requirement
Remember: Requirements engineering isn’t about bureaucracy - it’s about knowing what you’re building before you try to verify it works. The concepts from this lecture explain why we write the tests we do, and why 100% code coverage doesn’t mean your software is correct!