The i* conceptual model for requirements analysis



Similar documents
Using i* Meta Modeling for Verifying i* Models

Deriving Use Cases from Organizational Modeling

Business modeling with the support of multiple notations in requirements engineering

Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering

Evolving System Architecture to Meet Changing Business Goals. The Problem

Modeling Mental States in Requirements Engineering An Agent-Oriented Framework Based on i* and CASL

How To Develop Use Cases In Uml From Organizational Modeling

Understanding Software Ecosystems: A Strategic Modeling Approach

Goal-Oriented Requirements Engineering: An Overview of the Current Research. by Alexei Lapouchnian

Modelling Organizational Issues for Enterprise Integration

Bachelor of Science in Information Technology Program Outcome Assessment

Using i for Transformational Creativity in Requirements Engineering

A Vulnerability-Centric Requirements Engineering Framework: Analyzing Security Attacks, Countermeasures, and Requirements Based on Vulnerabilities

Towards a CMMI-compliant Goal-Oriented Software Process through Model-Driven Development

Enterprise Architecture Review

Requirements Traceability. Mirka Palo

Towards an Agent Oriented approach to Software Engineering

The Role of the Software Architect

Enterprise Architecture Assessment Guide

Tropos: An Agent-Oriented Software Development Methodology

Goals and Scenarios to Software Product Lines: the GS2SPL Approach

Answers to Review Questions

How To Develop A Multi Agent System (Mma)

Software Engineering UNIT -1 OVERVIEW

On the Adequacy of i* Models for Representing and Analyzing Software Architectures

11 Tips to make the requirements definition process more effective and results more usable

Elicitation and Modeling Non-Functional Requirements A POS Case Study

Requirements Engineering Process

Six Ways to be SMART in Setting Performance Goals

Preface. PART I Background, Principles, Overview 1

INFORMATION INTEGRATION ARCHITECTURE DEVELOPMENT: A MULTI-AGENT APPROACH

Facility Maintenance Management Competency 4.9

The development of Shinawatra University s international graduate program in joint public and business administration (PBA)

Goal-Based Self-Contextualization

Talend Metadata Manager. Reduce Risk and Friction in your Information Supply Chain

An example ITIL -based model for effective Service Integration and Management. Kevin Holland. AXELOS.com

Section C. Requirements Elicitation

Airline Flight and Reservation System. Software Design Document. Name:

Accenture Management Consulting. Open Roles

Development, Acquisition, Implementation, and Maintenance of Application Systems

Software Risk Factors in Developing E-Governance Projects

Contributions To Ontology-Driven Requirements Engineering

What is Automotive Software Engineering? What is Automotive Software Engineering? What is Automotive Software Engineering?

Requirements Analysis that Works!

Ubiquitous, Pervasive and Mobile Computing: A Reusable-Models-based Non-Functional Catalogue

Quality Ensuring Development of Software Processes

Data Analysis 1. SET08104 Database Systems. Napier University

Key performance indicators

SD Elements: A Tool for Secure Application Development Management

Data Migration Tool Requirements and Related Procedures

W E B B A S E D M E E T I N G S C H E D U L E R S Y S T E M

Verification of Good Design Style of UML Models

Unit 2.1. Data Analysis 1 - V Data Analysis 1. Dr Gordon Russell, Napier University

feature requirements engineering

Under moderate supervision, tests and troubleshoots hardware and/or software problems, makes repairs. May supervise or provide leadership to staff.

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

Surveying and evaluating tools for managing processes for software intensive systems

Aligning Data Warehouse Requirements with Business Goals

Revision History Revision Date Changes Initial version published to

Best Practices in Recruitment Assessment

Agent-Oriented Software Engineering PORTO Methodology AIAD 2013/2014. António Castro and Eugénio Oliveira

Agile Model-Based Systems Engineering (ambse)

The Use of UML Activity Diagrams and the i* Language in the Modeling of the Balanced Scorecard Implantation Process

Complex Information Management Using a Framework Supported by ECA Rules in XML

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.

Network Mission Assurance

Simmons College Graduate School of Library and Information Science. Managerial Leadership in the Information Professions

Software Development in the Large!

Chap 1. Introduction to Software Architecture

Transcription:

Information Systems Analysis and Design The i* conceptual model for requirements analysis Background and Motivations Basic concepts The Strategic Dependency Model Example + Exercise i* modeling framework -- 1 Requirements Engineering (RE) RE is crucial to the successful development and subsequent development and ongoing evolution of the system Initial requirements statements express customer s wishes about what the system should do. Often they are: Ambiguous Incomplete Inconsistent Usually expressed informally Problems -- 2 1

Requirements Languages Many requirements languages and frameworks help to make requirements precise, complete, and consistent Modeling techniques, from boxes-and-arrows diagrams to logical formalisms, assist engineers in these tasks The objective, in these late-phase requirements engineering tasks, is to produce a requirements document to pass on ( downstream ) to the developers, so that the resulting system would be adequately specified and constrained Problems -- 3 Early-phase of RE activities Usually, less attention is given to supporting the activities that precede the formulation of the initial requirements. These early-phase RE activities include: how the intended system would meet organizational goals why the system is needed what alternatives might exist what the implications of the alternatives are for various stakeholders, and how the stakeholders interests and concerns might be addressed. Problems -- 4 2

Early-phase The emphasis is on understanding the whys that underlie system requirements [Yu94], rather than on the precise and detailed specification of what the system should do Some of the reasons of an early-phase: poor understanding of the domain (interests, priorities and abilities of various actors and players) is a primary cause of project failure Need of systematic framework to help developers understand what users want and to help users understand what technical systems can do Problems -- 5 Early-phase need to relate systems to business and organizational objectives need to deal with change. A representation of organizational issues and rationales in requirements models would allow software changes to be traced all the organizational changes that leads to requirements changes need to understand how systems cooperate (with each other and with human agents) to contribute to organizational goals Problems -- 6 3

Early-phase Early-phase RE activities have traditionally been done informally, and without much tool support. A considerable body of knowledge would be built up during early-phase RE. This knowledge would be used to supporting reasoning about organizational objectives system-and-environment alternatives implications for stakeholders, etc. this body of knowledge guides system development, and help to deal with change throughout the system s life time. Problems -- 7 The i* modelling framework The i* framework has been developed by Eric Yu in his PhD thesis (1994) at University of Toronto Basically, i* is used for modelling and reasoning about organizational environments and their information systems i* consists of two main modelling components: the Strategic Dependency (SD) model to describe the dependency relationships among various actors the Strategic Rationale (SR) model to describe stakeholders interests and concerns, and how they might be addressed by various configurations of systems Problems -- 8 4

Strategic-intentional Actors Actors are viewed as having intentional proprerties, such as: goals, beliefs, abilities, and commitments Actors depend on each other for: goals to be achieved tasks to be performed resources to be furnished Actors are strategic in the sense that they are concerned about opportunities and vulnerabilities, and seek rearrangements of their environments that would better serve their interests. Problems -- 9 Strategic Dependency Relationship I want I can Actor A D Car Be Repaired D Actor B Problems -- 10 5

Dependency Types: Goal dependency Depender Dependee Dependum Doesn t care how achieved Problems -- 11 Dependency Types: Task dependency An activity Stipulates what to do Problems -- 12 6

Dependency Types: Resource dependency An entity Uses the resource Problems -- 13 Dependency Types: SofGoal dependency Not sharply pre-defined Choose good-enough method Problems -- 14 7

Dependency Strengths: Open Dependency Nice to have Problems -- 15 Dependency Strengths: Committed Dependency Some course of action would fail Problems -- 16 8

Dependency Strengths: Critical Dependency All known courses of action will fail Problems -- 17 An example: the meeting scheduler The meeting scheduler should try to determine a meeting date and location so that most of the intended participants will participate effectively. The system would find dates and locations that are as convenient as possible. The meeting initiator would ask all potential participants for information about their availability to meet during a date range. The meeting scheduler comes up with a proposed date. Participants would agree to a meeting date once an acceptable date has been found. Problems -- 18 9

Early-requirements analysis Why is it necessary to schedule meetings ahead of time? Why does the meeting initiator need to ask participants for exclusion dates and preferred dates? Why is a computer-based meeting scheduler desired? And whose interests does it serve? Is confirmation via the computer-based scheduler sufficient? If not, why not? Are important participants treated differently? If so, why? Problems -- 19 Early-requirements analysis Having answers to these why questions are important not only to help develop successful systems in the first instance, but also to facilitate the development of cooperation with other systems (e.g., project management systems and other team coordination group-ware for which meeting information may be relevant) the ongoing evolution of these systems. Problems -- 20 10

Strategic Dependency Model Problems -- 21 SD with computer-based scheduler Problems -- 22 11

Problems -- 23 Problems -- 24 12

Exercise Let s try to model the 3 actors Customer, Bank and House-vendor when the customer want to buy a new house from the House-vendor and has to ask money to the Bank. Problems -- 25 Problems -- 26 13

Problems -- 27 The Strategic Rationale (SR) model SD shows external relationships among actors, while hides the intentional constructs within each actor SR models internal intentional relationships inside each actor Intentional elements (goals, tasks, resources, and softgoals) appear in the SR model not only as external dependencies, but also as internal elements linked by means-ends ends relationships and task-decompositions Problems -- 28 14

SR without the Meet. Sched. Problems -- 29 Task-decomposition Problems -- 30 15

Means-end links Problems -- 31 Contribution to GostGoals - - (- -)) (-)( ) (+) (++) Problems -- 32 16

SR with the Meet. Sched. Problems -- 33 17