04 Quiz: Requirements Engineering - Process & Practice
December 2025 (2563 Words, 15 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 Part 2 (Requirements Engineering: From Process to Practice)
- 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: Business Perspectives
The same requirement “Display intersection point” looks different to different roles. Which perspective focuses primarily on “Is there a market for this?”
A) The Developer
B) The Project Manager
C) The Product Manager
D) The Startup Founder
Show Answer
Correct Answer: D
The Startup Founder’s view focuses on product-market fit, validation, and pivoting. They ask questions like “Is there a market for this?” and “Will people pay for it?” The Developer focuses on implementation details, the Project Manager on the iron triangle (scope, time, budget), and the Product Manager on value delivery and prioritization.
Question 2: The Iron Triangle
A Project Manager must balance three competing constraints. According to the “iron triangle” concept, which set of constraints applies?
A) Speed, Security, and Scalability
B) Scope, Time, and Budget
C) Testing, Documentation, and Training
D) Features, Users, and Revenue
Show Answer
Correct Answer: B
The iron triangle consists of Scope, Time, and Budget - with Quality in the center affected by all three. The saying “Good, Fast, Cheap - pick two” captures the trade-off. You can’t have everything: expanding scope while maintaining quality typically requires more time or budget.
Question 3: Elicitation Techniques
You need to understand what users actually do (not just what they say they do). Which elicitation technique is BEST suited for this?
A) Surveys
B) Interviews
C) Observation
D) Workshops
Show Answer
Correct Answer: C
Observation is best for understanding actual workflow versus what users say they do. People often describe idealized or simplified versions of their work in interviews. Observation lets you see the workarounds, shortcuts, and pain points they might not think to mention. However, watch out for the Hawthorne effect - people may change their behavior when being observed.
Question 4: Good Questions
Which of the following is an example of a GOOD elicitation question?
A) “You want the button to be blue, right?”
B) “Is the system fast enough?”
C) “What’s the most frustrating part of your current workflow?”
D) “Do you like the current design?”
Show Answer
Correct Answer: C
Option C is open-ended and exploratory, inviting the stakeholder to share their experience and pain points. The other options are closed or leading questions: A leads toward a specific answer, B can only be answered yes/no without insight, and D is subjective without revealing actionable information. Good questions help discover requirements, not confirm assumptions.
Question 5: The 5 Whys Technique
When a user says “I need the intersection calculation to be faster,” the 5 Whys technique helps discover:
A) The exact algorithm optimization needed
B) How many milliseconds to shave off
C) The underlying need behind the stated request
D) Which competitor has faster calculations
Show Answer
Correct Answer: C
The 5 Whys technique digs deeper into the real need. By repeatedly asking “why,” you might discover that “faster calculation” isn’t really what they need - perhaps they need a real-time feedback loop for camera adjustment, which could be solved with prediction/preview rather than faster calculation. The stated request is often not the true requirement.
Question 6: Bug vs Change Request Definition
According to the lecture, what distinguishes a BUG from a Change Request?
A) Bugs are found by testers, change requests by customers
B) Bugs mean the software doesn’t meet documented requirements; CRs request something different or additional
C) Bugs are always free to fix, CRs are always billable
D) Bugs are technical problems, CRs are user interface issues
Show Answer
Correct Answer: B
The key distinction is whether documented requirements exist: A bug means the software doesn’t meet an existing, documented requirement. A change request means the stakeholder wants something different or additional to what was specified. This distinction has significant business implications - bugs are typically the vendor’s responsibility (warranty), while CRs may be billable and extend deadlines.
Question 7: The Gray Area
A customer reports: “The intersection calculation returns wrong results for angles greater than 180 degrees.” If the requirement says “angle in range 0-180,” this is:
A) Definitely a bug that must be fixed for free
B) A change request - the customer wants new capability
C) A documentation error
D) A performance issue
Show Answer
Correct Answer: B
If the requirement explicitly specifies “angle in range 0-180,” then handling angles greater than 180 degrees is new capability not covered by the original specification. This is a change request. If the requirement said “angle in range 0-360,” it would be a bug. If the requirement was silent on angle range, it becomes a gray area requiring stakeholder discussion. Clear requirements documentation prevents these disputes.
Question 8: Why Bug vs CR Matters
Beyond software development, why is the bug vs change request distinction particularly important?
A) It determines which developer gets assigned the task
B) It has legal and financial implications that can escalate to contract disputes
C) It affects the code review process
D) It determines the Git branch naming convention
Show Answer
Correct Answer: B
The bug vs CR distinction has direct financial and legal consequences. Vendors might charge for “change requests” when fixing genuine bugs. Customers might claim “bugs” to get new features free. Ambiguous requirements lead to disputes that can escalate to contract negotiations or legal cases. This is why clear requirements documentation protects both parties.
Question 9: POC-Driven Requirements
The Lean Startup approach (Build-Measure-Learn) addresses which fundamental problem with traditional requirements engineering?
A) Stakeholders give too many requirements
B) Developers write too much documentation
C) Customers don’t know what they want until they see it
D) Testing takes too long
Show Answer
Correct Answer: C
The uncomfortable truth about requirements is that customers often don’t know what they want until they see it. Traditional RE assumes you can interview stakeholders, write complete requirements, build the system, and deliver what they wanted. Reality: they describe what they think they want, you build it, they say “Actually, I meant…” Lean Startup addresses this through rapid iteration with MVPs.
Question 10: MVP Definition
In the context of Lean Startup, what is an MVP (Minimum Viable Product)?
A) A fully-featured product with minimal bugs
B) The smallest thing you can build to test a hypothesis about what users want
C) A detailed requirements document
D) A prototype that demonstrates technical feasibility
Show Answer
Correct Answer: B
MVP stands for Minimum Viable Product - the smallest thing you can build to test your hypothesis about what users want. It’s not about building something complete with minimal defects (A), nor just about technical feasibility (D). Each MVP iteration refines requirements based on real feedback, replacing guesswork with validated learning.
Question 11: Design Thinking
Design Thinking emphasizes “Empathize First.” What does this mean in the context of requirements discovery?
A) Feel sorry for users who have difficult jobs
B) Observe users, interview them, and experience their pain before defining solutions
C) Write empathetic error messages
D) Make the UI more emotionally appealing
Show Answer
Correct Answer: B
“Empathize First” means understanding users deeply before jumping to solutions. This involves observing users in their environment, interviewing them about their experiences, and trying to understand their pain points firsthand. Requirements emerge from this understanding rather than being assumed upfront. The Design Thinking process then continues through Define, Ideate, Prototype, and Test.
Question 12: Gen AI and Prototyping
How does Gen AI-assisted prototyping (“vibe coding”) change the requirements discovery process?
A) It eliminates the need for stakeholder interviews
B) It lets you create working prototypes quickly, making requirements discovery interactive
C) It automatically generates perfect requirements documents
D) It replaces the need for testing
Show Answer
Correct Answer: B
Gen AI enables rapid prototyping - what might take weeks traditionally can be done in hours or minutes. This transforms requirements discovery: instead of long interviews followed by written requirements followed by building (and often building the wrong thing), you can have quick chats, show working prototypes the same day, and iterate rapidly. Requirements become conversations with working software as a shared reference.
Question 13: Traditional RE Limitations
Traditional requirements engineering (Big Upfront Requirements) works BEST in which scenario?
A) High uncertainty and novel product development
B) Fast-moving markets where requirements change rapidly
C) Regulated environments with stable, well-understood requirements
D) Innovation contexts where you’re discovering, not just building
Show Answer
Correct Answer: C
Traditional RE works well for regulated environments (medical, aviation), well-understood domains with stable requirements, fixed-price contracts with clearly defined scope, and large systems with many integration points. It struggles with uncertainty, “I’ll know it when I see it” requirements, fast-moving markets, and innovation contexts where POC-driven approaches excel.
Question 14: The Royce Irony
Winston Royce’s 1970 paper is often cited as the origin of the Waterfall model. What’s ironic about this?
A) Royce never actually worked on software
B) Royce actually warned against the pure sequential approach in that same paper
C) The paper was about hardware, not software
D) Royce preferred Agile development
Show Answer
Correct Answer: B
The irony is that Royce called the basic waterfall approach “risky and inviting failure” in his paper. He presented it as a cautionary example and the rest of his paper described iterative improvements and feedback loops. The industry adopted his diagram but ignored his warnings. What was meant to show “don’t do this” became the standard process.
Question 15: V-Model Innovation
What is the key innovation of the V-Model compared to the basic Waterfall model?
A) It eliminates the need for documentation
B) Each development phase has a corresponding testing phase, with test planning happening in parallel
C) It removes the sequential constraint entirely
D) It focuses only on unit testing
Show Answer
Correct Answer: B
The V-Model’s key innovation is pairing each development phase (left arm of the V) with a corresponding testing phase (right arm). Crucially, test planning happens in parallel with development - acceptance tests are designed when requirements are written, not after coding. This addresses Waterfall’s weakness of treating testing as an afterthought.
Question 16: V-Modell XT
V-Modell XT is relevant to software engineering students because:
A) It’s required for all open-source projects
B) It’s mandatory for German federal government IT projects and used by many large German companies
C) It’s the simplest development model to learn
D) It eliminates the need for requirements documentation
Show Answer
Correct Answer: B
V-Modell XT is the mandated standard for German federal IT projects - it’s not optional, it’s required by law. Many large German companies (Siemens, Bosch, SAP) also use it or variants. Understanding it demonstrates how regulated industries handle software development and is often relevant in German industry job interviews.
Question 17: The Late Feedback Problem
All sequential models (Waterfall, V-Model) share a fundamental limitation. What is it?
A) They require too many developers
B) Working software appears only at the end, so requirement errors are discovered late
C) They don’t allow any testing
D) They can only be used for small projects
Show Answer
Correct Answer: B
The core problem with sequential models is that working software appears only at the end. If requirements were wrong, you discover it months (or years) after the decision was made - leading to expensive rework. The V-Model improves on Waterfall by planning tests earlier, but it still suffers from this fundamental late-feedback problem.
Question 18: Cost of Change
Barry Boehm’s research on the “cost of change curve” demonstrates that:
A) All changes cost the same regardless of when they’re made
B) Changes in production are actually cheaper because the code is finished
C) Defects found late in development are significantly more expensive to fix than those found early
D) Documentation prevents all change costs
Show Answer
Correct Answer: C
Boehm’s research showed that defects found late are dramatically more expensive to fix. A requirements error found during requirements means changing a document. The same error found in production means: changing requirements, updating design, rewriting code, re-running tests, redeploying, handling customer impact, and possibly data migration. The exact ratios are debated, but the principle is robust: late changes cost more.
Question 19: Sequential Model Assumptions
Sequential models assume we can “know all requirements upfront.” Reality contradicts this because:
A) Requirements documents are too long to read
B) Users don’t know what they want until they see working software
C) Developers refuse to read requirements
D) Requirements tools are too expensive
Show Answer
Correct Answer: B
Users often can’t fully articulate their needs until they interact with something concrete. This isn’t a failure - it’s human nature. Design decisions also need feedback from implementation. Software is learned through iteration, not manufactured like physical products. Sequential models assume stability, but software development is inherently uncertain.
Question 20: The Agile Response
According to the Agile Manifesto preview, what is the Agile response to constant requirements change?
A) Create more detailed documentation to prevent changes
B) Freeze requirements at the start and reject all changes
C) Embrace change as inevitable, iterate quickly, and deliver value early
D) Hire more project managers to control the process
Show Answer
Correct Answer: C
While the traditional response to change is “more planning, more documentation, change control,” the Agile response is to embrace change as inevitable. This means iterating quickly (sprints), delivering value early (working software over comprehensive documentation), and collaborating with customers rather than rigid contract negotiation. Requirements become living artifacts refined through frequent feedback.
Scoring Guide
- 18-20 correct: Excellent! You have a strong grasp of requirements processes, from elicitation to change management to development models
- 14-17 correct: Good understanding! Review the areas you missed, particularly the distinctions between approaches
- 10-13 correct: Fair understanding. Revisit the lecture sections on elicitation techniques, bug vs CR, and development model trade-offs
- Below 10: Please review the lecture carefully. Focus on understanding why different approaches exist and when each is appropriate. Reach out if you need clarification!
Key Takeaways to Remember
- Different Roles, Different Views - The same requirement looks different to developers, PMs, product managers, and founders
- Iron Triangle - Scope, Time, Budget (pick two) with Quality in the center
- Observation Beats Asking - Watch what users do, not just what they say
- Ask Open Questions - “What’s frustrating?” beats “You want it blue, right?”
- 5 Whys Reveal True Needs - The stated request often isn’t the real requirement
- Bug vs CR Has Legal Weight - Clear documentation prevents expensive disputes
- Customers Don’t Know Until They See - Build to learn, not just to deliver
- MVP Tests Hypotheses - The smallest thing that validates your assumption
- Royce Warned Us - The “father of Waterfall” actually warned against it
- V-Model Pairs Dev with Test - Plan tests when you write requirements, not after coding
- Late Changes Cost More - Boehm’s principle: find errors early
- Agile Embraces Change - Don’t fight uncertainty, work with it
Remember: Requirements engineering isn’t just about writing documents - it’s about discovering what to build through conversation, prototyping, and iteration. The best requirement is one that lets you build the right thing the first time, or helps you learn faster when you don’t!