Requirements Analysis

Definition

Requirements Analysis

the requirements engineering task during which the reused and elicited raw requirements are analyzed

Classification

As illustrated in the preceding figure, Requirements Analysis is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Engineering Task
• Subclasses: None

Responsibilities

The typical responsibilities of Requirements Analysis are to:

• Study, categorize, decompose and organize, model, quantify, refine, prioritize, justify, and trace each requirement to its source(s).
• Transform informal textual requirements into semiformal or formal requirements (if formal methods are used).
• Negotiate the prioritization and validity of requirements with the requirements stakeholders.
• Verify any related assumptions.
• Turn potental raw requirements and related information into real requirements that have the necessary quality characteristics:
  • Clarity (i.e., lack of ambiguity)
  • Completeness
  • Consistency
  • Correctness
  • Feasibility (e.g., technical, financial, schedule, etc.)
  • Verificability
  • Understandability
• Ensure that the requirements are sufficiently understood that they can be properly specified.

Preconditions

Requirements Analysis can typically begin when the following preconditions hold:

• The requirements team is staffed and adequately trained in requirements analysis techniques.
• Some requirements to be analyzed have been either elicited or selected for reuse.

Completion Criteria

Requirements analysis is typically complete when the following postconditions hold:

• Each requirement has been properly analyzed:
  • Studied
  • Categorized
  • Organized
  • Related to associated requirements (e.g., via decomposition, dependency, and inheritance)
  • Modeled (e.g., textual requirements are transformed into state models or use case models)
  • Formalized:
    • Quality requirements are quantified
    • Informal textual requirements are transformed into semiformal or formally specified requirements (e.g., if formal methods supporting proof of correctness are used)
  • Refined
  • Prioritized
  • Validated and justified
  • Traced to their source(s)
  • Provided appropriate metadata (i.e., attributes)
• All requirements models exist.
• All requirements diagrams exist.
• All requirements, models, and diagrams have the necessary quality:
  • Complete
  • Consistent
  • Correct (semantically and syntactically)
  • Feasible
  • Mandatory
  • Relevant
  • Understandable
  • Validatable (e.g., Testable)
• All related assumptions have been verified as relevant and correct.
• A consensus among the members of the requirements team exists regarding the requirements.

Steps

Requirements analysis typically involves the following producers performing the following steps in an iterative, incremental, parallel, and time-boxed manner:

• Requirements Team:
  • Study, refine, and understand the raw and reusable requirements.
  • Categorize, organize, and determine relationships between the raw and reusable requirements.
  • Justify the raw and reusable requirements.
  • Analyze the raw and reusable requirements by building one or more of the following models including the associated diagrams:
    • Context Model
    • Data Model
    • Function Model
    • Object Model
    • Process Model
    • Quality Model
    • State Model
    • Use Case Model
  • Develop semiformal or formal requirements specifications.
  • Verify all related assumptions as relevant and correct.
  • Informally determine the quality of the analyzed requirements, models and diagrams.
  • Iterate the requirements, models, and diagrams as necessary.
  • Trace the analyzed requirements back to their sources.
  • Allocate prioritized requirements to releases and associated milestones.
• Architecture Team:
  • Prioritize the requirements from the standpoints of implementability and technical feasability.
• Customer Management Team:
  • Prioritize the requirements from the standpoints of their business and marketing needs.
• Endeavor Management Team:
  • Prioritize the requirements from the standpoint of the development organization.

Techniques

Requirements analysis can typically be performed using the following techniques:

• Categorization.
  Use a classification scheme to categorize and thereby organize and analyze the requirements.
• Cost Benefit Analysis.
  Produce a cost/benefit analysis for requirements that may be cost-prohibitive to implement.
• Cross Functional Teams.
  Use cross functional teams to analyze the requirements.
• Incremental Development.
  Incrementally analyse the requirements.
• Iteration.
  Iterate the requirements models and diagrams.
• Joint Application Development (JAD).
  Hold JAD requirements modeling sessions using actor cards, use case cards, diagrams, and printing whiteboards.
• Parallel Development.
  Analyze the requirements in parallel with:
  • Other requirements engineering tasks (e.g., requirements elicitation, requirements reuse, requirements specification, requirements management).
  • Other activities (e.g., architecting, design, testing, management, configuration management, training).
• Requirements Tracing.
  Trace the requirements back to their sources (e.g., goals, stakeholders, vision statements), and trace requirements to related requirements (e.g., quality requirements to related functional requirements).
• Timeboxing.
  Timebox the requirements analysis task so that new increments of potential requirements are available at regular intervals for driving the architecting, design, implementation, and testing activities.
• Modeling including:
  • Object Techniques:
    • Context Modeling
    • Use Case Modeling
    • Object Modeling of the application/problem domain
    • State Modeling
  • Structured Analysis Techniques:
    • Functional Decomposition
    • Data Flow Analysis
    • Control Flow Analysis
  • Information Engineering Techniques:
    • Entity Relationship Modeling
    • Entity Relationship Attribute (ERA) Diagrams
  • Decision Trees
  • Formal specification and formal proofs of correctness

Work Products

Requirements analysis typically results in the production of the following work products:

• Analyzed requirements including associated requirements attributes (metadata):
  • Unique Identifier (for requirements identification and traceability).
  • Categorization (e.g., data requirement, external API requirement, functional requirement, quality requirement, constraint)
  • Criticality to Customer (e.g., high, medium, low)
  • Criticality to Users (e.g., high, medium, low)
  • Estimated Cost Range (e.g., high, medium, low)
  • Frequency of Execution (e.g., high, medium, low - if functional requirement)
  • Implementation Status (e.g., not implemented, implemented)
  • Justification (i.e., rationale)
  • Owner (e.g., owning producer for implementation)
  • Prioritization (e.g., current release, next release, eventually)
  • Probability of Defects (in the implementation)
  • Risk (associated with implementation) (e.g., high, medium, low)
  • Source (i.e., requirements trace to document, goal)
  • Status (e.g., Proposed, Analyzed, Specified, Evaluated, Approved, Baselined, Frozen, Retired)
  • Stakeholder (i.e., requirements trace to stakeholder)
  • Validation Method (e.g., analysis, demonstration, inspection, testing)
  • Validation Status (e.g., not validated, validated)
  • Volitility (e.g., high, medium, low)
• Requirements Models:
  • Context Model
  • Data Model
  • Function Model
  • Object Model
  • Process Model
  • Quality Model
  • State Model
  • Use Case Model
  • Formal, mathematical models of the requirements
• Requirements Diagrams:
  • Context Diagram
  • Use Case Diagram
  • Use Case Sequence Diagram
  • Class Diagram (e.g., Domain Object Diagram)
  • Data Design Diagram (e.g., ERA Diagram)
  • Sequence Diagram
  • State Transition Diagram
• Requirements traceability matrices.
• Allocation of requirements to milestones.

Guidelines

• Requirements analysis should be performed iteratively, incrementally, and in parallel with other tasks (e.g., requirements elicitation, requirements reuse, requirements prototyping, requirements management, requirements specification).
• There are few great analysis techniques for modeling quality requirements, constraints, and required external APIs.
• There is considerable confusion in industry concerning the meaning of the word “analysis”. Whereas it has traditionally been used in the phrase “requirements analysis” to mean the definition given above, some methodologists have misused the word ”analysis” in the phrase “analysis and design” to mean either “architecture and design” or “logical design and physical design”. The OPEN Process Framework avoids these sources of misunderstanding by clearly differentiating:
  • The requirements analysis task from other requirements tasks.
  • Requirements engineering, architecting, and design as three separate activities.
  • Logical vs. physical architectures and logical vs. physical designs, whereby:
    • ‘Logical’ means ‘implementation and technology independent’.
    • ‘Physical’ means ‘implementation and technology dependent’.
• Requirements prioritization can be a major subtask of requirements analysis:
  • Ensure that all major stakeholders have input into the requirements prioritization process.
  • Prioritization of requirements for commercial products can be based on market segmentation, market analysis, and gap analysis.
  • Because prioritization is primarily used to determine when to implement and release the individual requirements, other tasks requiring the limited resources (e.g., defect fixing and implementing non-required change requests become important.
• Requirements may be informal, semiformal, or formal. Requirements analysis is when formal requirements models (if any) would be produced.