Goal-Oriented Requirements Engineering (GORE) “Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring,

Slides:



Advertisements
Similar presentations
1 GRL Introduction Lin Liu University of Toronto April 2001.
Advertisements

Knowledge Engineering for Planning Domain Design Ron Simpson University of Huddersfield.
Design by Contract.
June, 2006 The 11th CAiSE06 International Workshop on Exploring Modeling Methods in Systems Analysis and Design (EMMSAD06), Luxembourg Ontological.
Identifying, Modifying, Creating, and Removing Monitor Rules for SOC Ricardo Contreras Andrea Zisman
1 Lecture 2: Processes, Requirements, and Use Cases.
Alternative Approach to Systems Analysis Structured analysis
Goal and Scenario Validation: a Fluent Combination Chin-Yi Tsai.
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.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Goal-Directed Requirements Acquisition (KAOS) Conceptual Modeling CSC2507  (Organizational) goals lead to requirements.  Goals justify and explain requirements.
Use-case Modeling.
Reza Gorgan Mohammadi AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling.
Simulation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented design 2.
CSCI928 Software Engineering Requirements & Specifications Modeling System Interactions Tri A. Kurniawan, M.Eng. Ph.D Candidate
Modeling challenges: Compliance (1/2) Compliance management has emerged as a major problem following major corporate governance scandals (e.g. Enron, WorldComm)
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Goal.
Requirements artifacts – Goals
Describing Syntax and Semantics
Dealing with NFRs Vahid Jalali Amirkabir university of technology, Department of computer engineering and information technology, Intelligent systems laboratory,
AOSE-2003, Melbourne July 15 th 1 Agent Oriented modeling by interleaving formal and informal analysis Anna Perini 1, Marco Pistore 2,1, Marco Roveri 1,
Recall The Team Skills Analyzing the Problem
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Workflow Description Language and Workflow Patterns Yi Wang.
University of Toronto Department of Computer Science © 2001, Steve Easterbrook CSC444 Lec17 1 Lecture 17: Formal Modeling Methods Formal Modeling Techniques.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
CS3773 Software Engineering
Software Engineering CS B Prof. George Heineman.
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
MOHANA PRIYA TEST SCENARIO  Test scenario represent a powerful tool for test design and are a single event or a sequence of events that happen.
UML Profile to Support Requirements Engineering with KAOS Presented by Chin-Yi Tsai.
Software Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard.
UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
AXEL VAN LAMSWEERDE UNIVERSITY OF LOUVAIN PRESENTED BY AMRITAM SARCAR From System Goals to Software Architecture.
1 Introduction to Software Engineering Lecture 1.
1 Structuring Systems Requirements Use Case Description and Diagrams.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Supporting Scenario-Based Requirements Engineering IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998 A. G. Sutcliffe, N. A. M.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
Deriving Operational Software Specification from System Goals Xin Bai EEL 5881 Course Fall, 2003.
MODES-650 Advanced System Simulation Presented by Olgun Karademirci VERIFICATION AND VALIDATION OF SIMULATION MODELS.
Of 33 lecture 1: introduction. of 33 the semantic web vision today’s web (1) web content – for human consumption (no structural information) people search.
Chapter 17. Assertions State Assertion – predicate intended to express that a descriptive or prescriptive property holds in an arbitrarily chose current.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Business Rules 12 th Meeting Course Name: Business Intelligence Year: 2009.
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.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
Refining the Use Cases 1. How Use Cases Evolve  Early efforts typically define most of the major use cases.  The refining stages complete the process.
Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Method engineering [infome] paper presentation Rodi heijbom
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Lecture 5 Introduction to Use Case Analysis and the Analysis Model Introduction to the UML.
Beyond Scenarios: Generating State Models from Use Cases An approach for the synthesis of State transition graphs from Use Cases Supporting Use Cases Based.
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Analysis Classes Unit 5.
An Overview of Requirements Engineering Tools and Methodologies*
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Business Models Modeling.
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

Goal-Oriented Requirements Engineering (GORE) “Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements.” (van Lamsweerde 2001) Goals can be viewed as the earliest/highest-level requirements artefacts Can form the organizing locus for all subsequent RE activities

GORE: Key issues Goal modeling Obtaining downstream artefacts from goal models Maintaining consistency of goal models Incorporating NFRs into goal models Using goals as requirements rationale

A goal graph

KAOS: Outline KAOS: Knowledge Acquisition in autOmated Specification A comprehensive GORE framework Four models: –Goal model –Object model –Agent model –Operation model Constructs: –Graphical and a textual syntax –Defined using the real-time temporal logic

KAOS Ontology (1/3) Objects: Can be: entity (autonomous object), relationship (subordinate object), event (instantaneous object) Actions/Operations: –Input/output relations over objects –Operation application defines a state transition –Have pre-conditions, post-conditions and trigger conditions –Distinguish between: Domain pre-, post-conditions (domain specific, defined by the domain) Required pre-, post-condition (application-specific, required to achieve goals)

KAOS Ontology (2/3) Agents: Processors of operations –An agent performs an operation allocated to it –Monitors an object whose states can be observed by it –Controls an object whose states can be controlled by it Goals: Related to other goals via AND-refinement or OR-refinement links

KAOS Ontology (3/3) Requisite: A goal that can be formulated in terms of states controllable by an agent –Goals end up via a sequence of AND/OR refinements as requisites assigned to agents –Requisites are AND/OR operationalized by operations and objects (may require strengthening of pre-, post- and trigger conditions) –Alternative means of assignment of requisites to agents captured by responsibility links –Actual assignment of a requisite to an agent captured by performance link Requirement: Requisite assigned to a software agent Assumption: Requisite assigned to an environment agent Scenario: Sequence of operation applications by relevant agent (additional details ommitted)

KAOS: Operation/Agent Model

KAOS: Real-time Temporal Logic Assumes linear time

KAOS: Real-time Temporal Logic As opposed to branching time Now

KAOS: Real-time Temporal Logic (H, i)  |= P denotes that a history H (a linear time structure, assumed to be discrete), satisfies assertion P at time point i

KAOS: Real-time Temporal Logic Temporal operators

KAOS: Real-time Temporal Logic

KAOS: Goal Representation

KAOS: Agent/Relationship Representation