# 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

```mermaid
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

1. **Ask "why" repeatedly** - Get to root need, not just stated solution
2. **Separate problem and solution** - Spend time in problem space
3. **Involve all relevant stakeholders** - Include operators, maintainers, security, etc.
4. **Capture context of use** - When, where, how will it be used?
5. **Document assumptions** - Explicitly call out assumptions
6. **Validate needs** - Review with stakeholders before deriving requirements
7. **Consider constraints early** - Regulatory, technical, budget, schedule

## Related Notes

- [[Requirements-Engineering/Writing-Good-Requirements.md]] — How to write verifiable requirements
- [[Requirements-Engineering/Requirements-Analysis-Traceability.md]] — Tracing and managing
- [[Architecture/Functional-Architecture.md]] — Mapping needs to functions
- [[Case-Studies/Software-Intensive-Systems.md]] — Bridge to software
- [[../AgenticEngineering/Domains/Customer-Facing-Agents.md]] — Example domain

## 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*