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

Slides:



Advertisements
Similar presentations
Software Engineering Key construction decisions Design challenges.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Virtual University - Human Computer Interaction 1 © Imran Hussain | UMT Imran Hussain University of Management and Technology (UMT) Lecture 16 HCI PROCESS.
lamsweerde Part 1: Introduction © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models to.
lamsweerde Part 2: Building System Models for RE © 2009 John Wiley and Sons 1 Part 2: Building System Models for RE Introduction.
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
© 2005 Prentice Hall6-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Karolina Muszyńska Based on
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Requirements.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Requirement Engineering – A Roadmap
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
1 درس مهندسي نيازمندي استاد دكتر عبداله زاده دانشجو خيرالنسا مرچانت RE in The Year 00: A Research Perspective.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Engineering Tools and Methods Presented by: Mohammad Enamur Rashid( ) Mohammad Rashim Uddin( ) Masud Ur Rahman( )
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
The Software Development Life Cycle: An Overview
Chapter 4 Requirements Engineering
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Chapter 4 – Requirements Engineering
Architecture Business Cycle
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
SOFTWARE DESIGN.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
System Context and Domain Analysis Abbas Rasoolzadegan.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Software Safety Case Why, what and how… Jon Arvid Børretzen.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Smart Home Technologies
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Prof. Hany H. Ammar, CSEE, WVU, and
Inferring Declarative Requirements Specification from Operational Scenarios IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998.
Requirements Analysis
Requirements Analysis
Software Engineering Lecture 8: Quality Assurance.
Basic Concepts and Definitions
Software Engineering (CSI 321) Software Process: A Generic View 1.
Chapter 13 설계 개념 Architectural Design 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Software Engineering Lecture 10: System Engineering.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
System Development Life Cycle (SDLC). Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Advanced Software Engineering Dr. Cheng
Chapter 2 Object-Oriented Paradigm Overview
Chapter 4 – Requirements Engineering
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Chapter 6: Architectural Design
Presentation transcript:

lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models to Software Specifications

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

3 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Requirements engineering (RE), roughly...  Identify & analyze problems with an existing system as-is (system-as-is), to-be  Identify & evaluate objectives, opportunities, options for new system (system-to-be),  Identify & define functionalities of, constraints on, responsibilities in system-to-be, requirements document  Specify & organize all of these in a requirements document to be maintained throughout system evolution System = software + environment (people, devices, other software)

4 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Example: transportation between airport terminals as-is  Problem (system-as-is) : –passengers frequently missing flight connections among different terminals; slow & inconvenient transportation –number of passengers regularly increasing to-be  Objectives, options (system-to-be) : –support high-frequency trains between terminals or –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

5 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Requirements in the software lifecycle R equirements engineering Software design Software implementation Software evolution Getting therightsystem Getting thesoftwareright

6 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

7 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

8 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

9 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-view  Multi-view model: –different system facets for requirements completeness

10 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Why models for RE ? key aspects  Focus on key aspects (abstraction from multiple details) structure  Provides structure for RE activities –target for what must be elicited, evaluated, specified, consolidated, modified –interface among RE activities: produce/consume model items analysis  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

11 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Learning RE: objectives sound precise  Get a sound, precise understanding of concepts, principles, processes, and products involved in RE techniques  Master state-of-the art techniques for requirements elicitation, evaluation, specification, analysis, evolution systematic  Be able to construct, analyze and exploit high-quality models for RE in a systematic way practical  Gain practical experience in applying techniques in concrete, realistic situations

12 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

13 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Some features, risks & challenges of RE... unsuccessful project unrealizable Achieve goal Maintain goal multi-language specs multiple stakeholders model

14 lamsweerde Requirements Engineering© 2009 John Wiley and Sons techniques  Concentrates on solid, replicable RE techniques –far beyond high-level principles & guidelines construction  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

15 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 kept hidden  Most techniques are grounded on a formal framework kept hidden for wider accessibility

16 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

17 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Part 1: Fundamentals of Requirements Engineering basic concepts  Setting the scene: basic concepts & principles elicitation  Domain understanding & requirements elicitation evaluation  Requirements evaluation –Conflict management, risk analysis, evaluating alternative options, requirements prioritization specificationdocumentation  Requirements specification and documentation –Structured natural language, use of diagrammatic notations, formal specification quality assurance  Requirements quality assurance –Inspections & reviews, requirements database queries, specification animation, formal verification evolution  Requirements evolution –Change anticipation, traceability management, change control  Goal-orientation  Goal-orientation in RE

18 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Part 2: Building system models for RE objectives  Modeling system objectives with goal diagrams  Risk  Risk analysis on goal models conceptual objects  Modeling conceptual objects with class diagrams agents  Modeling system agents and responsibilities operations  Modeling system operations behaviors  Modeling system behaviors: scenarios and state machines  Integrating multiple system views model building method  A goal-oriented model building method in action

19 lamsweerde Requirements Engineering© 2009 John Wiley and Sons 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 –Synthesizing behavior models

20 lamsweerde Requirements Engineering© 2009 John Wiley and Sons Additional resources 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  Objectiver tool for building & playing with models –Free limited access for educational use