Requirements Engineering Ch. 1

Requirements Engineering

The systematic process of identifying, analyzing, documenting, validating, and managing the needs and expectations of stakeholders to ensure a system or product meets its intended goals

System

Set of interacting components structuring the problem world

System-as-is

System as it exists before the machine is built into it

System-to-be

System as it should be when the machine will operate into it

Software-to-be

Software to be developed - part of the machine, component of the system-to-be

Environment

All other components of the system-to-be, including people, devices, pre-existing software, etc.

System Requirements

What the system-to-be should meet; formulated in terms of phenomena in the environment

Software Requirements

What the software-to-be should meet on its own; formulated in terms of phenomena shared by the software and the environment

Scope of Requirements Engineering

Contains three dimensions: Why (A new system?), What (Services?), Who (Will be responsible for what?)

Why Dimension

Identify, analyze, refine the system-to-be’s objectives:

• To address analyzed deficiencies of the system-as-is

• In alignment with business objectives

• Taking advantage of technology opportunities

What Dimension

Identify and define the system-to-be’s functional services:

• To satisfy the identified objectives

• According to quality constraints; security, performance, …

• Based on realistic assumptions about the environment

Who Dimension

Assign responsibilities for the objectives, services, constraints among system-to-be components:

• Based on their capabilities and on the system’s objectives

• Yielding the software-environment boundary

Descriptive statements

State system properties holding regardless of how the system should behave (indicative mood)

Prescriptive statements

State desirable properties holding or not depending on how the system behaves (optative mood)

Domain property

Descriptive statement about problem world phenomena (holds regardless of any software-to-be)

Assumption

Statement to be satisfied by the environment of the software-to-be:

• Formulated in terms of environment phenomena

• Generally prescriptive (e.g. on sensors or actuators)

Functional requirements

Prescribe what services the software-to-be should provide:

• Capture intended software effects on environment, applicability conditions

• Units of functionality resulting from software operations

Non-functional requirements

Constrain how such services should be provided:

• Quality requirements: safety, security, accuracy, time/space performance, usability…

• Others: compliance, architectural, development requirements

• To be made precise in system-specific terms

Requirements Engineering Process

An iterative process containing four phases that spiral outwards:

• Domain understanding and elicitation (Alternative proposals)

• Evaluation and agreement (Agreed requirements)

• Specification and documentation (Documented requirements)

• Validation and verification (Consolidated requirements)

Target qualities for Requirements Engineering process

• Completeness

• Consistency

• Adequacy

• Unambiguity

• Measurability

• Pertinence

• Feasibility

• Comprehensibility

• Good structuring

• Modifiability

• Traceability

Types of Requirements Engineering errors

• Omission

• Contradiction

• Inadequacy

• Ambiguity

• Non-measurability

• Noise, over-specification

• Unfeasibility

• Unintelligibility

• Poor structuring

• Opacity

Omission

Problem world feature not stated by any requirements document item

Contradiction

Requirements document items stating a problem world feature in an incompatible way

Inadequacy

Requirements document item not adequately stating a problem world feature

Ambiguity

Requirements document item allowing a problem world feature to be interpreted in different ways

Non-measurability

Requirements document item stating a problem world feature in a way precluding option comparison or solution testing

Noise

Requirements document item yielding no information on any problem world feature

Over-specification

Requirements document item stating a feature not in the problem world, but in the machine solution

Unfeasibility

Requirements document item not implementable within budget/schedule

Unintelligibility

Requirements document item incomprehensible to those needing to use it

Poor structuring

Requirements document item not organized according to any sensible and visible structuring rule

Forward reference

Requirements document item making use of problem world features not defined yet

Remorse

Requirements document item stating a problem world feature lately or incidentally

Poor modifiability

Requirements document items whose changes must be propagated throughout the requirements document

Opacity

Requirements document item whose rationale, authoring or dependencies are invisible

Technical impact

On many software-related artifacts (as seen before)

Managerial impact

Basis for communication among parties and for project management

Legal impact

Contractual commitment client-provider-subcontractors

Impact on certification

Mastered Requirements engineering process required by many quality standards and certification authorities

Impact on economy, security, and safety

Cost and consequences of errors in requirements on the software-to-be, assumptions about its environment

Social impact

From user satisfaction to degradation of working conditions to system rejection