Needs vs Requirements
One of the most important distinctions in Systems Engineering: needs describe what stakeholders want to achieve, requirements describe what the system must do/satisfy to meet those needs.
The Key Distinction
| Aspect |
Stakeholder Needs |
System Requirements |
| Language |
Natural language, outcome-focused, often vague |
Precise, verifiable, "shall" statements |
| Source |
Stakeholders, users, operators, business goals |
Derived from needs, analyzed and clarified |
| Question |
"What do we want to accomplish?" |
"What must the system do/be?" |
| Scope |
Broad, may include wants/preferences |
Specific, testable, constrained |
| Example |
"I need to be able to find documents quickly" |
"The system shall return search results within 2 seconds for queries with < 100 characters" |
The Translation Process
graph LR
A[Business/Mission Need] --> B[Stakeholder Needs]
B --> C[Stakeholder Requirements]
C --> D[System Requirements]
D --> E[Design/Implementation]
style A fill:#e1f5fe
style B fill:#fff3e0
style C fill:#f3e5f5
style D fill:#e8f5e9
style E fill:#c8e6c9
Stakeholder Needs vs Stakeholder Requirements vs System Requirements
| Term |
Definition |
Audience |
| Stakeholder Needs |
Captured desires, expectations, constraints from stakeholders in their own terms |
All stakeholders |
| Stakeholder Requirements |
Translated stakeholder needs into a set of requirements from stakeholder perspective (often in CONOPS context) |
Stakeholders + SE team |
| System Requirements |
Technical requirements for the system to be built, derived from stakeholder requirements |
Engineering/design teams |
Common Pitfalls
| Pitfall |
Problem |
Solution |
| Jumping to solution |
"We need a chatbot" instead of "We need to reduce support response time" |
Stay in problem space longer; explore alternatives |
| Gold-plating |
Adding features not traceable to needs |
Use traceability to needs; ask "why" |
| Ambiguous needs |
"User-friendly" means different things to different people |
Elicit specific examples, scenarios, acceptance criteria |
| Assuming unstated needs |
Missing critical needs leads to rework |
Involve diverse stakeholders, use scenarios/use cases |
| Confusing wants and needs |
Wants are preferences, needs are necessities |
Prioritize - must have vs nice to have |
Elicitation Techniques
| Technique |
When to Use |
Notes |
| Interviews |
Understanding complex needs, sensitive topics |
One-on-one, prepare open-ended questions |
| Workshops/Focus Groups |
Multiple stakeholders, consensus needed |
Good for resolving conflicts |
| Observation/Shadowing |
Users don't know how to articulate needs |
See actual workflow vs stated workflow |
| Surveys/Questionnaires |
Many users, quantitative data needed |
Good for validation, less depth |
| Use Cases/Scenarios |
Understanding interactions |
Walk through "day in the life" |
| Prototyping |
Unclear or visual needs |
Get feedback early |
| Document Analysis |
Existing systems, regulations, contracts |
Review current state, constraints |
Example: AI Support Agent
| Level |
Example |
| Business Need |
"Reduce customer support costs while maintaining satisfaction" |
| Stakeholder Need |
"Support agents need help answering common questions faster; customers want answers 24/7" |
| Stakeholder Requirement |
"The system shall provide automated answers to top 80% of support inquiries" |
| System Requirements |
"The system shall integrate with knowledge base, use RAG with source citations, escalate to human when confidence < threshold, log all interactions for audit" |
Best Practices
- Ask "why" repeatedly - Get to root need, not just stated solution
- Separate problem and solution - Spend time in problem space
- Involve all relevant stakeholders - Include operators, maintainers, security, etc.
- Capture context of use - When, where, how will it be used?
- Document assumptions - Explicitly call out assumptions
- Validate needs - Review with stakeholders before deriving requirements
- Consider constraints early - Regulatory, technical, budget, schedule
Sources
- INCOSE Systems Engineering Handbook
- ISO/IEC/IEEE 29148
- NASA Systems Engineering Handbook
- MITRE Systems Engineering Guide
- Kossiakoff et al. - Systems Engineering Principles and Practice
