“Software Requirements” brings design back to its true starting point: good architecture rarely begins with components or technologies; it begins with correctly understood requirements. The book shows how fuzzy business and user expectations become a buildable engineering frame.
Its day-to-day value comes from connecting requirement levels, stakeholders, elicitation techniques, prioritization, and change management into one system. That makes it much easier to see how weak requirements turn into expensive architecture mistakes, while strong ones define clear constraints and realistic scope.
In interviews and discovery sessions, this chapter strengthens the most underrated part of the conversation. It helps you ask sharper clarifying questions, separate must-haves from nice-to-haves, and frame quality attributes before the first diagram shows up.
Practical value of this chapter
Requirements as input
Shows how requirements quality directly impacts architecture correctness.
Prioritization
Helps separate critical requirements from optional ones and avoid unnecessary complexity.
Traceability
Connects business goals, requirements, and architecture artifacts into one rationale chain.
Interview clarity
Improves the requirement-clarification phase and signals mature discovery thinking.
Software Requirements
Authors: Karl Wiegers, Joy Beatty
Publisher: Microsoft Press, 2013 (3rd Edition)
Length: ~670 pages
Classics from Karl Wiegers: requirements levels, elicitation techniques, MoSCoW and Kano prioritization, change management.
Primary source
Official page of Software Requirements by Karl Wiegers and Joy Beatty.
Key Concepts
Requirement levels
- Business Requirements — business goals
- User Requirements — what users will be able to do
- Functional Requirements — system behavior
- Non-functional - quality attributes
Quality Attributes
- Performance (latency, throughput)
- Scalability (load growth)
- Availability (uptime)
- Security, Maintainability, Usability
Stakeholders
Different stakeholders have different requirements. It is important to identify all stakeholders and understand their priorities. During an interview, it helps to ask the right follow-up questions.
Use Cases
Description of user interaction with the system. Includes the main scenario and alternative paths. Helps not to miss edge cases when designing.
Book structure
Software Requirements: What, Why, and Who
Basics: what are requirements, why are they important, roles in the process. The Business Analyst role. Requirements engineering as a discipline.
Requirements Development
Elicitation (detection), Analysis (analysis), Specification (documentation), Validation (validation). Interview and workshop techniques.
Requirements for Specific Project Types
Agile projects, package solutions, outsourcing, embedded systems, business intelligence.
Requirements Management
Change management, versioning, traceability, requirements reuse.
Requirements Elicitation Techniques
Interview
Structured and unstructured conversations with stakeholders. Open questions for research, closed questions for clarification.
Observation
Observe users in their work environment. Helps to identify unconscious requirements and real workflows.
Prototyping
Rapid prototypes to validate understanding of requirements. Helps identify gaps in the early stages.
Requirements prioritization
Interviews often ask you to define an MVP or prioritize features. Wiegers suggests several approaches:
MoSCoW
- Must have - required for release
- Should have - important, but not critical
- Could have - preferably
- Won't have - not in this release
Kano Model
- Basic - expected (must be)
- Performance - the more the better
- Excitement - wow effect
Common mistakes
❌ At the interview
- Jump straight to a solution without specifying requirements
- Don't ask about scale and load
- Ignore non-functional requirements
- Don't specify feature priorities
✓ How to do it correctly
- Start with business context and goals
- Identify the main use cases
- Specify SLA/SLO (availability, latency)
- Agree on scope and priorities
Application at System Design interview
Checklist of questions (from the book):
Main conclusions
Related chapters
- What is software architecture and why is it in System Design? - sets the architecture context where requirements become constraints, quality attributes, and design decisions.
- Discussion of frameworks for conducting/passing system design interviews - helps structure the discovery phase: which questions to ask and how to frame the problem before design.
- Approaches to conducting design interviews - shows a step-by-step process to formalize functional and non-functional requirements.
- Recommendations for preparing for an interview (short term) - provides a practical training plan for clarifying questions and scope prioritization.
- Clean Architecture (short summary) - connects requirements to boundary design, dependency direction, and module responsibilities.
- Decomposition strategies - translates requirements into service boundaries and contracts between subsystems.