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
3www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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)
4www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
5www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
Requirements in the software lifecycle
Requirements engineering
Software design
Software implementation
Software evolution
Getting the rightright
systemsystem
Getting the
softwaresoftwarerightright
6www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
7www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
8www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
9www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
10www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
11www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
12www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
Book support
Requirements Engineering: From System Goals
to UML Models
to Software Specifications
Axel van Lamsweerde
Wiley,
Jan. 2009
13www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
Some features, risks & challenges of RE ...
unsuccessful project
unrealizable Achieve goal
Maintain goal
multi-language specsmultiple
stakeholders
model
14www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
15www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
16www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
The book has three parts
Part 1: Fundamentals of RE
Part 2: Building models for RE
Part 3: Analyzing and exploiting RE models
17www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
18www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
19www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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
20www.wileyeurope .com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons
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