04 Quiz: Requirements Engineering - Process & Practice

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

“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.

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.

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.

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.

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.

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.

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.

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.

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.

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.