Hệ thống UML potx

Requirements EngineeringFrom System Goals to UML Models to Software Specifications... What is requirements engineering ? Set of activities producing the requirements on a software-in

Requirements Engineering

From System Goals

to UML Models

to Software Specifications

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 assurance is a key concern for software Requirements quality assurance quality assurance

Requirements engineering (RE), roughly

 Identify & analyze problems with an existing system

(system- as-is), as-is

 Identify & evaluate objectives, opportunities, options for

new system (system- to-be), to-be

 Identify & define functionalities of, constraints on,

responsibilities in system-to-be,

 Specify & organize all of these in a requirements document

to be maintained throughout system evolution

System = software + environment

transportation between airport terminals

 Problem (system- as-is) as-is :

– passengers frequently missing flight connections among

different terminals; slow & inconvenient transportation

– number of passengers regularly increasing

 Objectives, options (system- to-be) to-be :

– support high-frequency trains between terminals

– with or 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

R equirements engineering

Software design

Software implementation

Software evolution

Getting

the

right

system

Getting the

software

right

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

– Certification issues

 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-view model: Multi-view

– different system facets for requirements completeness

Why models for RE ?

 Focus on key aspects key aspects (abstraction from multiple details)

 Provides structure for RE activities structure

– target for what must be elicited, evaluated, specified,

consolidated, modified

– interface among RE activities: produce/consume model items

 Facilitates analysis

– 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 sound, sound precise understanding of concepts, principles, precise

processes, and products involved in RE

 Master state-of-the art techniques for requirements techniques

elicitation, evaluation, specification, analysis, evolution

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

 Gain practical experience in applying techniques in concrete, practical 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 model

 Concentrates on solid, replicable RE techniques

– far beyond high-level principles & guidelines

 Emphasizes model 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

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 concepts & principles basic concepts

 Domain understanding & requirements elicitation

 Requirements evaluation

requirements prioritization

 Requirements specification and specification documentation

specification

 Requirements quality assurance

animation, formal verification

 Requirements evolution

 Goal-orientation in RE Goal-orientation

Part 2:

Building system models for RE

 Modeling system objectives with goal diagrams objectives

 Risk analysis on goal models Risk

 Modeling conceptual objects with class diagrams conceptual objects

 Modeling system agents and responsibilities agents

 Modeling system operations

 Modeling system behaviors: scenarios and state machines behaviors

 Integrating multiple system views

 A goal-oriented model building method in action model building method

Part 3 Reasoning 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

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