Stakeholders and requirements

Updated 27 Oct 2026

•
Stakeholders and engagement
- •
  Stakeholders -> people or groups who affect or are affected by a system.
  - •
    examples: users, funders, operators, maintainers, suppliers, regulators, and communities.
- •
  identify their goals, influence, impact, and conflicting expectations
- •
  Roles and authority
  - •
    customer, sponsor, and end user can be different people.
  - •
    job title alone does not establish decision authority
  - •
    job title alone does not establish access rights.
- •
  a power-interest grid helps plan engagement:
  - •
    High power, high interest -> manage closely
  - •
    High power, low interest -> keep satisfied
  - •
    Low power, high interest -> keep informed
  - •
    Low power, low interest -> monitor appropriately
  - •
    Engagement cautions
    
    •
    the grid is an aid, not a reason to ignore low-power groups.
    
    •
    categories can change.
    
    •
    consider who bears the consequences, not just who can authorize the work.
•
From needs to requirements
- •
  Requirements -> describe verifiable system behavior, quality attributes, or constraints based on stakeholder needs.
- •
  Need versus requirement
  - •
    Need -> the problem or desired outcome.
  - •
    Requirement -> what the proposed system must provide.
- •
  Requirement types
  - •
    Functional requirements -> describe services and behavior in specified situations.
  - •
    Non-functional requirements -> describe quality attributes or constraints, such as timing or standards.
  - •
    Domain requirements
    
    •
    arise from the operating domain
    
    •
    may affect behavior, quality, or constraints
    
    •
    can overlap with functional and non-functional requirements
- •
  Levels of detail
  - •
    User level -> high-level needs in language suitable for customers.
  - •
    System level -> detailed behavior and processing for implementation.
- •
  Related distinctions
  - •
    keep business rules, constraints, assumptions, and dependencies distinct from requirements
  - •
    business rules govern how the business works.
  - •
    identify which rules the system must enforce, then express that enforcement as requirements.
•
Elicitation and communication
- •
  Elicitation -> discovers and clarifies needs rather than simply collecting a requested feature list.
- •
  Methods to combine
  - •
    interviews and document analysis.
  - •
    process and organizational models.
  - •
    brainstorming and mind maps.
  - •
    lessons learned and risk analysis
- •
  Interview structure depends on the purpose:
  - •
    Structured -> fixed questions for consistent comparison.
  - •
    Semi-structured -> allows follow-ups.
  - •
    Unstructured -> supports exploration.
- •
  a practical interview sequence:
  1. 1.
    prepare objectives
  2. 2.
    use open, closed, and follow-up questions
  3. 3.
    listen actively
  4. 4.
    record only with permission
  5. 5.
    record findings
  6. 6.
    confirm key interpretations with the people involved
- •
  Checking understanding
  - •
    clear communication helps establish shared meaning.
  - •
    it does not by itself settle conflicting priorities or prove a requirement correct.
  - •
    check findings against documents, observed work, and relevant models.
•
Risk as elicitation evidence
- •
  risk analysis can reveal needs for protection, recovery, or operating limits
- •
  loss estimates support discussion; they do not automatically become system requirements
- •
  Single-loss expectancy
  - •
    Formula -> $\mathrm{SLE}=\mathrm{AV}\times\mathrm{EF}$ .
  - •
    Asset value (AV) -> value of the asset being assessed.
  - •
    Exposure factor (EF) -> fraction lost in one incident.
- •
  Annualized-loss expectancy: $\mathrm{ALE}=\mathrm{ARO}\times\mathrm{SLE}$ , where ARO is the expected number of incidents per year.
- •
  Annualized-loss expectancy
  - •
    Formula -> $\mathrm{ALE}=\mathrm{ARO}\times\mathrm{SLE}$ .
  - •
    Annual occurrence rate (ARO) -> expected number of incidents per year.
- •
  record risk owners and responses, not just a loss estimate
•
Applications
- •
  information systems: turning information needs into requirements

Linked references 2

◌ Explore connections in Graph view

Stakeholders and requirements

Stakeholders and engagement

From needs to requirements

Elicitation and communication

Risk as elicitation evidence

Applications

Linked references 2