Chapter 7 Goal Orientation in RE

Slides:



Advertisements
Similar presentations
Chapter 7 Goal Orientation in RE
Advertisements

A GUIDE TO CREATING QUALITY ONLINE LEARNING DOING DISTANCE EDUCATION WELL.
Centralize or Decentralize? A Requirements Engineering Perspective on Internet-Scale Architectures Eric Yu University of Toronto July 2000.
User Modeling CIS 376 Bruce R. Maxim UM-Dearborn.
UC San Diego CSE 294 May 7, 2010 Barry Demchak
Building System Models for RE Chapter 12 Modeling System Operations.
Building System Models for RE
lamsweerde Part 2: Building System Models for RE © 2009 John Wiley and Sons 1 Part 2: Building System Models for RE Introduction.
YOU ONLY THINK YOU’RE LIKE GOOGLE : COMPARATIVE USER EXPERIENCE OF DISCOVERY PLATFORMS Rice Majors Faculty Director of Libraries Information Technology.
Building System Models for RE Chapter 11 Modeling System Agents and Responsibilities.
Lesson 1-Introducing Basic Network Concepts
8 September Announcements  GIT Class: Friday 3-5 SN 115 (Peter Parente)  Information for Project Links PageProject Links Page  Hot Topics Teams.
Object-Oriented Thinking Chapter 1, Object-Oriented Programming in Java, Timothy Budd, 1998 ICS102 Semester
lamsweerde Chap.8: Modeling System Objectives © 2009 John Wiley and Sons Building System Models for RE Chapter 8 Modeling.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
lamsweerde Chap.11: Modeling System Agents © 2009 John Wiley and Sons Building System Models for RE Chapter 11 Modeling.
What is it? A mobile robotics system controls a manned or partially manned vehicle-car, submarine, space vehicle | Website for Students.
Chapter 3 Object-Oriented Analysis of Library Management System(LMS)
Supported Education A Promising Practice. 2 What are Evidence-Based Practices? Services that have consistently demonstrated their effectiveness in helping.
Use Cases Why use ‘em? How do they work? UC diagrams Using them later in the software development cycle.
Design Patterns Standardized Recurring model Fits in many location Opposite of customization Fundamental types of pattern Choose and use as desired and.
8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Establishing IV&V Expectations Diagrams for illustrative purposes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
- Readers’ Services is one of the two divisions in any organized library. - The other division is the Technical Services. - Each of the two divisions.
Supplementary Specifications (Chapters 20,22 - Requirements Text) 1.
TF-DI Meeting 13-Aug Agenda Discovery presentation from William Miller Review of discussions at F2F Sunnyvale Interaction patterns of tech landscape.
1 Sobah Abbas Petersen Adjunct Associate Professor TDT4252 Modelling of Information Systems Advanced Course Lecture 5: i*modelling.
Dr. Tom WayCSC Software Requirements CSC 4700 Software Engineering Lecture 2 Based on Sommerville, Chapter 6.
Software Requirements Presented By Dr. Shazzad Hosain.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Software Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard.
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
© Mahindra Satyam 2009 Decision Analysis and Resolution QMS Training.
Objected Oriented Programming & Design JAVA Shishir Gupta (704) (704)
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Roma, Meeting Mindraces 2-3 October 2006 ISTC-CNR Achievements MindRACES: From Reactive to Anticipatory Cognitive Embodied Systems (FP )
Deriving Operational Software Specification from System Goals Xin Bai EEL 5881 Course Fall, 2003.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
TDT 4242 Inah Omoronyia and Tor Stålhane Requirements Specification and Testing An introduction TDT 4242 Institutt for datateknikk og informasjonsvitenskap.
lamsweerde Chap.4: Formal Requirements Specification © 2009 John Wiley and Sons Fundamentals of RE Chapter 4 Requirements.
Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
February 8, 2006copyright Thomas Pole , all rights reserved 1 Lecture 3: Reusable Software Packaging: Source Code and Text Chapter 2: Dealing.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Library Starter Kit Compiled by Helene van der Sandt.
lamsweerde Chap.7: Goal Orientation in RE © 2009 John Wiley and Sons 1 Fundamentals of RE Chapter 7 Goal Orientation in.
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Systems Analysis & Design
Slide 1 2/22/2016 Policy-Based Management With SNMP SNMPCONF Working Group - Interim Meeting May 2000 Jon Saperia.
Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
An Architecture-Centric Approach for Software Engineering with Situated Multiagent Systems PhD Defense Danny Weyns Katholieke Universiteit Leuven October.
Dec 11, Analysis and Design of MLC Services using JADE (1) Oscar Lin.
Requirement Classification Nisa’ul Hafidhoh Teknik Informatika
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
TK2023 Object-Oriented Software Engineering
1 OOA3 Stellman – Preface and Intro u Key Ideas? u Assumptions by Stellman/Greene 540/3 f07 OOA3 aug28.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Modeling data in the Organization
Mobile File Systems.
Presentation on Software Requirements Submitted by
CIS 376 Bruce R. Maxim UM-Dearborn
MPCS – Advanced java Programming
Requirements Specification and Testing
Start at 17th March 2012 end at 31th March 2012
Requirements Specification and Testing
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Behavioral goal specialization
Business Modeling - Domain Analysis
TDT4252 Modelling of Information Systems Advanced Course
Engineering Quality Software
Presentation transcript:

Chapter 7 Goal Orientation in RE Fundamentals of RE Chapter 7 Goal Orientation in RE

What are goals? Goal = prescriptive statement of intent the system should satisfy through cooperation of its agents e.g. “Train doors shall be closed while the train is moving” “Loan periods shall be limited to 2 weeks” ""agent": active system component responsible for goal satisfaction

Goal satisfaction requires agent cooperation Agent = role, rather than individual must restrict its behavior to meet its assigned goals Agent types software (software-to-be, legacy software, foreign software) device (sensor, actuator, ...) human

The granularity of goals Goals can be stated at different levels of abstraction Higher-level goals: strategic, coarse-grained "50% increase of transportation capacity" ”Effective access to state of the art" Lower-level goals: technical, fine-grained ”Acceleration command sent every 3 secs" ”Reminder issued by end of loan period if no return" The finer-grained a goal, the fewer agents required for its satisfaction

Goal types Behavioral goals: prescribe behaviors vs. Soft goals: state preferences among alternative behaviors

Behavior goals prescribe sets of desired behaviors DoorsClosed WhileMoving moving closed stopped closed moving closed stopped closed stopped open

Behavioral goals: subtypes and specification patterns Achieve [TargetCondition]: [if CurrentCondition then] sooner-or-later TargetCondition Achieve [BookRequestSatisfied]: if a book is requested then sooner-or-later a copy of the book is borrowed by the requesting patron Achieve [FastJourney]: if train is at some platform then within 5 minutes it is at next platform

Behavioral goals: subtypes and specification patterns (2) Maintain [GoodCondition]: [if CurrentCondition then] always GoodCondition always (if CurrentCondition then GoodCondition) Maintain [DoorsClosedWhileMoving]: always (if a train is moving then its doors are closed) Maintain [WorstCaseStoppingDistance]: always (if a train follows another then its distance is sufficient to allow the other to stop suddenly)

Behavioral goals: subtypes and specification patterns (3) Accuracy goals are usually of type Maintain Maintain [AccurateBookClassification]: if a book is registered in the library directory then always its keyword-based classification reflects its covered topics Avoid [BadCondition]: dual of Maintain ... [if CurrentCondition then] never BadCondition Avoid [BorrowerLoansDisclosed]: never patron loans disclosed to other patrons Many security goals are Avoid goals

The central role of goals in the RE process Goal refinement/abstraction as structuring mechanism shows contribution links among goals drives elaboration of reqs (subgoals) provides rationale for reqs (parent goals) rich traceability: strategic objectives  technical requirements can be used to structure reqs document (cf. chap. 16)

The central role of goals in the RE process (4) Goal OR-refinement  capture of alternative options