Catalog
concept#Product#Software Engineering#Delivery#Governance

Requirements Analysis

Structured process to elicit, prioritize, and specify requirements as the foundation for design and validation.

Requirements analysis identifies, prioritizes, and documents functional and non-functional requirements for systems or products.
Established
Medium

Classification

  • Medium
  • Business
  • Design
  • Intermediate

Technical context

Issue tracker / backlog tools (e.g. Jira)Test management systemsRequirements management tools (e.g. DOORS, Azure DevOps)

Principles & goals

Work stakeholder-centered: derive requirements from user and business perspectives.Clarity and precision: avoid vague terms, define acceptance criteria.Ensure traceability: keep requirements traceable to tests and code.
Discovery
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Misunderstandings lead to costly rework.
  • Scope creep due to unclear prioritization.
  • Overdocumentation can block iterative delivery.
  • Use clear, measurable acceptance criteria.
  • Work iteratively and review requirements regularly.
  • Ensure early involvement of all relevant stakeholders.

I/O & resources

  • Business goals and KPIs
  • Stakeholder interviews and workshops
  • Existing system and process documentation
  • Prioritized requirements list
  • Acceptance criteria and test cases
  • Traceability matrix

Description

Requirements analysis identifies, prioritizes, and documents functional and non-functional requirements for systems or products. It aligns stakeholder needs with technical constraints, establishes traceability, and forms the basis for design, validation, and early project decisions. The aim is a clear, verified, and accepted specification.

✔

  • Reduced misdevelopment through clear requirements.
  • Better planning and prioritization of deliveries.
  • Improved communication between business and engineering teams.

✖

  • Outcome depends heavily on stakeholder availability and quality.
  • Can be time-consuming with many participants.
  • Not all requirements can be fully specified in early phases.

  • Requirements volatility

    Number and share of changed requirements over time.

  • Traceability coverage

    Percentage of requirements traced to tests or user stories.

  • Time to approval

    Average time from requirement draft to formal approval.

E-commerce checkout

Requirements for payment flow, fraud prevention, and performance were prioritized and translated into acceptance criteria.

Mobile app release

Platform requirements, offline behavior, and privacy were specified as non-functional requirements.

Regulatory reporting

Regulatory specifications led to additional validation and audit requirements in the specification.

1

Identify stakeholders and secure engagement.

2

Clarify goals and context.

3

Elicit requirements (interviews, workshops, document analysis).

4

Document, prioritize, and assign acceptance criteria to requirements.

5

Establish traceability and set up review/approval process.

⚠️ Technical debt & bottlenecks

  • Unclear requirements lead to increasing maintenance complexity.
  • Missing traceability complicates root-cause analysis.
  • Undocumented trade-offs cause future uncertainties.
Stakeholder alignmentAmbiguity in wordingScope creep
  • Requirements written exclusively by a developer.
  • Prioritization based on subjective opinions without criteria.
  • Documentation is not maintained and quickly becomes outdated.
  • Confusing proposed solutions with requirements.
  • Too late involvement of compliance or operations teams.
  • Lack of validation with real users.
Facilitation and interviewing techniquesDomain knowledgeUnderstanding of testing and development processes
Clarity of requirementsStakeholder availability and engagementTraceability of requirements to tests
  • • Project time constraints
  • • Limited availability of domain experts
  • • Regulatory requirements