Www.wileyeurope.com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models

www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1

Requirements EngineeringFrom System Goals

to UML Models to Software Specifications

2www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons

What is requirements engineering ?

Set of activities producing the requirements on a software-intensive system

– elicitation, evaluation, specification, analysis, evolution management

– system objectives, functionalities, target qualities, constraints, assumptions

Requirements quality assuranceRequirements quality assurance is a key concern for software quality assurance


Requirements engineering (RE), roughly ...

Identify & analyze problems with an existing system

(system-as-isas-is),

Identify & evaluate objectives, opportunities, options for new system (system-to-beto-be),

Identify & define functionalities of, constraints on, responsibilities in system-to-be,

Specify & organize all of these in a requirements requirements

documentdocument to be maintained throughout system evolution

System = software + environment (people, devices, other software)


Example:transportation between airport

terminals Problem (system-as-isas-is):

– passengers frequently missing flight connections among different terminals; slow & inconvenient transportation

– number of passengers regularly increasing

Objectives, options (system-to-beto-be):– support high-frequency trains between terminals

– with oror without train drivers ?

Functionalities, constraints:

– software-based control of train accelerations, doors opening etc. to achieve prompt and safe transportation

RE deliverable: requirements document for system-to-be


Requirements in the software lifecycle

Requirements engineering

Software design

Software implementation

Software evolution

Getting the rightright

systemsystem

Getting the

softwaresoftwarerightright


Why requirements engineering ?

RE is critical

– Major cause of software failure

Requirements-related errors are the most numerous, persistent, expensive, dangerous

– Severe consequences: cost overruns, delivery delays, dissatisfaction, degradations, accidents, ...

– RE has multiple impact: legal, social, economical,

technical

RE is hard


What makes RE hard ?

Broad scope

– multiple system versions: as-is, to-be, to-be-next

– hybrid environment:human organizations,

policies, regulations

devices, physical laws

Multiple concerns

– functional, quality, development concerns

Multiple abstraction levels– strategic objectives, operational details


What makes RE hard ? (2)

Multiple stakeholders

– with different background

– with different interests and conflicting viewpoints

Multiple intertwined tasks during iterative elicitation-evaluation-specification-consolidation

– conflict management

– risk management

– evaluation of alternatives, prioritization

– quality assurance

– change anticipation


Model-based RE

Model:

– abstract representation of system (as-is or to-be)

– highlights, specifies, inter-relates key system features

Multi-viewMulti-view model:

– different system facets for requirements completeness


Why models for RE ?

Focus on key aspectskey aspects (abstraction from multiple details)

Provides structurestructure for RE activities– target for what must be elicited, evaluated, specified,

consolidated, modified

– interface among RE activities: produce/consume model items

Facilitates analysisanalysis– support for early detection and fix of errors

Support for understanding, explanation to stakeholders

Basis for making decisions– multiple options made explicit

Basis for generating the requirements document


Learning RE: objectives

Get a soundsound, precise precise understanding of concepts, principles, processes, and products involved in RE

Master state-of-the art techniquestechniques for requirements elicitation, evaluation, specification, analysis, evolution

Be able to construct, analyze and exploit high-quality models for RE in a systematicsystematic way

Gain practicalpractical experience in applying techniques in concrete, realistic situations


Book support

Requirements Engineering: From System Goals

to UML Models

to Software Specifications

Axel van Lamsweerde

Wiley,

Jan. 2009


Some features, risks & challenges of RE ...

unsuccessful project

unrealizable Achieve goal

Maintain goal

multi-language specsmultiple

stakeholders

model


Concentrates on solid, replicable RE techniques techniques

– far beyond high-level principles & guidelines

Emphasizes model construction construction (beyond mere use of

diagrammatic notations)

– procedures, heuristic rules, tactics, modeling patterns, bad smells

– UML compliance wherever possible

Based on case studies in a variety of domains

Approach taken in the book


Approach taken in the book (2)

Numerous exercises at the end of each chapter

Comprehensive biblio notes at the end of each chapter

– to encourage further study

Multiple tracks & entry points to meet a variety of learning needs

– basic, model-driven, advanced tracks

Most techniques are grounded on a formal framework

kept hidden kept hidden for wider accessibility


The book has three parts

Part 1: Fundamentals of RE

Part 2: Building models for RE

Part 3: Analyzing and exploiting RE models


Part 1: Fundamentals of Requirements Engineering

Setting the scene: basic conceptsbasic concepts & principles Domain understanding & requirements elicitationelicitation Requirements evaluationevaluation

– Conflict management, risk analysis, evaluating alternative options, requirements prioritization

Requirements specificationspecification and documentationdocumentation– Structured natural language, use of diagrammatic notations, formal

specification Requirements quality assurancequality assurance

– Inspections & reviews, requirements database queries, specification animation, formal verification

Requirements evolutionevolution– Change anticipation, traceability management, change control

Goal-orientationGoal-orientation in RE


Part 2: Building system models for RE

Modeling system objectivesobjectives with goal diagrams

RiskRisk analysis on goal models

Modeling conceptual objectsconceptual objects with class diagrams

Modeling system agentsagents and responsibilities

Modeling system operationsoperations

Modeling system behaviorsbehaviors: scenarios and state machines

Integrating multiple system views

A goal-oriented model building methodmodel building method in action


Part 3Reasoning about system models

Semi-formal reasoning for model analysis & exploitation– Query-based analysis of the model database

– Analysis of conflicts, obstacles, and security threats

– Qualitative & quantitative reasoning about alternatives

– Model-driven generation of the requirements document

– From goal-oriented requirements to software architecture

Formal specification of system models– A real-time temporal logic for specifying model annotations

– Specifying goals, domain properties, and operationalizations

Formal reasoning for specification construction & analysis– Checking goal refinements; deriving operationalizations

– Generating obstacles and anti-goals; analyzing conflicts

– Synthesizing behavior models


Additional resources

http://www.wileyeurope.com/college/van lamsweerde

Course slides

More case studies & examples

Requirements document generated from model built in Chap. 15

Instructor’s protocol for obtaining solutions to exercises

Book figures

http://www.objectiver.com Objectiver tool for building & playing with models

– Free limited access for educational use

Documents

Www.wileyeurope.com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models