Skip to main content

Requirement Analysis under Incomplete Assumptions

Context​

In many contexts, Requirement Analysis is understood as "the process of extracting requirements."

However, in software under operation or maintenance projects, requirements almost never align in a complete or consistent way. Specifications are fragmentary, assumptions for decisions are not shared, and stakeholder expectations also change over time.

Requirement Analysis performed in such situations needs to be treated not as the act of gathering requirements, but as organizing assumptions so that decisions can hold.

Objective​

The purpose of this topic is not precise requirements definition or complete specification consensus.

It lies in creating a state where decisions regarding changes and implementation can be taken on even under incomplete assumptions.

Requirement Analysis is treated as a means of avoiding postponed decisions.

Minimal Inputs​

Minimal inputs in Requirement Analysis are composed not of "what to build," but what to fix as assumptions for decisions.

  • SoT (Source of Truth)
    Information source that becomes the ultimate basis for requirements decisions

  • Constraints
    Contracts, deadlines, organizational and technical constraints

  • Non-Changeables
    Assumptions agreed not to change in decisions this time

  • Uncertainties
    Items that cannot be determined at this time and are treated as hypotheses

Unless these are fixed, requirements remain in a state where they can be continually reinterpreted.

Working Model​

Requirement Analysis is not a process to finalize requirements.

It has a working model for handling requirements as hypotheses under incomplete assumptions.

  • Requirements treated as hypotheses
  • Basis supporting those hypotheses
  • Conditions under which hypotheses collapse
  • Deadline allowing them as hypotheses

Hypotheses without deadlines tend to be treated as implicit finalized items.

Tactics​

Intervention in Requirement Analysis is not increasing requirements.

  • First fix assumptions needed for decisions
  • Make undetermined requirements explicit as hypotheses
  • Intentionally leave what not to decide

These are not procedures, but design for maintaining decision-making capability.

Risks​

Requirement Analysis easily turns into the following failures.

  • Requirements are infinitely added and decisions stop
  • Hypotheses are not verified and assumptions become fixed
  • "Requirements still insufficient" is used as evasion of responsibility

These, with Decision Avoidance and Context Erosion as background, become breeding grounds that induce Failure Patterns.

Interaction with Failure Patterns​

Requirement Analysis strongly relates to the following Failure Patterns.

AI Collaboration​

When using AI for Requirement Analysis, rather than requirements themselves, passing decision assumptions becomes important.

  • What to make SoT
  • What constraints not to cross
  • What to treat as non-changeable
  • What uncertainties to allow as hypotheses

If these are not fixed, AI generates plausible requirements, but cannot take on decisions.

Last updated on by Hiroshi Kurabayashi