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.
Original
TranslatedPrimary 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