A Requirement-Driven Development Methodology Jaelson Castro

A Requirement-Driven Development Methodology Jaelson Castro † † Manuel Kolp ‡ Centro de Informática Universidade Federal de Pernambuco Recife 50732 -970, Brazil ‡ John Mylopoulos ‡ Department of Computer Science University of Toronto M 5 S 3 G 4, Canada CAi. SE’ 01 - June 6 2001, Interlaken, Switzerland

Requirements-Driven Development Information Systems should be designed to match their Social Operational Environment l Operational environment : stakeholders, qualities, responsibilities, objectives, and resources, roles, needs. . . l Versus information systems : a collection of (software) modules, data structures and interfaces. l Impedance Mismatch Poor quality, Failure Why not requirements-driven to avoid that mismatch? Social and Intentional concepts not only for Early Requirements but the Entire Development Life Cycle TROPOS (http: //www. cs. toronto. edu/km/tropos) Manuel Kolp, University of Toronto, Department of Computer Science 2

Where Do We Want to Go? i* Agent-oriented programming TROPOS GAIA KAOS Z AUML !! The GAP !! UML, Catalysis & Co. l te ra rly s u La ts Ea nt ct ign te e en hi des m m c ire Ar u u eq eq r r Manuel Kolp, University of Toronto, Department of Computer Science led i ta ign De es d n io t ta en lem p Im 3

1. Early Requirements Analysis with TROPOS l Understanding the problem by studying an organizational setting; l Organizational model with relevant actors and respective goals. l i* [Yu 95] l Running Example: A Business to Consumer System Goals are relative, fulfillment is collaborative !! Manuel Kolp, University of Toronto, Department of Computer Science 4

Rationale Analysis Manuel Kolp, University of Toronto, Department of Computer Science 5

2. Late Requirements (Strategic Relationships) ”Organizational Map” Functions and qualities for the system within its environment Manuel Kolp, University of Toronto, Department of Computer Science 6

A Formal Framework Precise Semantics Entity Order Has order. Id: Number, cust: Customer, date: Date, tems: Set. Of [Media. Item] Entity Media. Item Has item. Id: Number, item. Title: String, description: Text, editor: String … Goal. Dependency Buy. Media. Items Mode Fulfil Has order: Order Defined Items. Received. OK(order) Depender Customer Dependee Media. Shop Necessary Fulfil( Place. Order(order)) Soft. Goal. Dependency Increase. Market. Share Actor Customer Has customer. Id: Number, name: Name, address: Address, tel: Phone. Number, … Capable of Make. Order, Pay, Browse, … Goal "order: Order $buy: Buy. Media. Items[order] (order. cust=self Ù Fulfil(buy)) Mode Maintain Depender Media. Shop Dependee Customer Necessary "cust: Customer $place: Place. Order[order] (order. cust=cust ) Ù Fulfil(place)) Action Make. Order Actor Media. Shop Has name: {Media. Live}, address: {“ 735 Yonge Street”}, phone#: 0461 -762 -883 Capable of Sell, Ship, Send. Invoice, … Goal $ ms: Increase. Market. Share(Fulfil(ms)) Manuel Kolp, University of Toronto, Department of Computer Science Performed By Customer Refines Place. Order Input cust : Customer, date : Date, items : Set. Of [Media. Item] Output order : Order Post order. cust = cust Ù order. date = date Ù order. items 7

Late Requirements - System Rationale Model ”Rationale Map” Medi@ Manuel Kolp, University of Toronto, Department of Computer Science 8

Minimal effort Collection effort Rapidity of Order Minimal Interaction Minimal conflicts Matching effort - - Availability + + - - + … Goal Analysis ++ Order Item Collect orders ++ By person Select Item By system Manually Automatically By phone By Fax Have updated invoices With Shopping Cart Manuel Kolp, University of Toronto, Department of Computer Science 9

Leaving Goals Dependencies is a Novelty l Goals and Softgoals generally operationalized/metricized during Late Requirements (e. g. KAOS – van Lamsweerde 93) l Ex. : Security operationalized by interfaces which minimize input/output or access restriction to sensitive information. l Steps through which goals are to be fulfilled are frozen in the requirements l Systems fragile and less reusable. l Whenever there is a need for flexibility, reusability, modularity Manuel Kolp, University of Toronto, Department of Computer Science 10

3. Architectural Design l Architecture in terms of interconnected social components. l 3 levels – 1 Macro level : Organizational Styles (Organization Theory) • Vertical Integration, Pyramid, Joint Venture, Structure in 5, Bidding, Hierarchical Contracting, Co-optation, Takeover – 2 Micro level : Patterns (Agent, COOPIS Community) • Broker, Matchmaker, Contract-Net, Mediator, Monitor, Embassy, Wrapper, Master-Slave, . . . – 3 Atomic : Social and intentional concepts – i* Manuel Kolp, University of Toronto, Department of Computer Science 11

Organizational Styles and Social Patterns Joint Venture Matchmaker Manuel Kolp, University of Toronto, Department of Computer Science 12

Software Quality Attributes l Predictability, Security, Adaptability, Cooperativity, Competitivity, Adaptability Availability, Failability, Modularity, Aggregability, … Availability Manuel Kolp, University of Toronto, Department of Computer Science 13

Selecting System Architecture [Chung 00] Manuel Kolp, University of Toronto, Department of Computer Science 14

A Joint-Venture E-commerce Architecture ”E-Business Organizational Map” Manuel Kolp, University of Toronto, Department of Computer Science 15

Assigning Agent Roles to Actors Manuel Kolp, University of Toronto, Department of Computer Science 16

4. Detailed Design l Architectural Agent components defined in details in terms of inputs, Check Out Plan Manuel Kolp, University of Toronto, Department of Computer Science 17

Agent Interaction Protocol with AUML Customer Shopping Cart Manuel Kolp, University of Toronto, Department of Computer Science The Checkout Dialogue 18

From i* to Agent Concepts Manuel Kolp, University of Toronto, Department of Computer Science 19

Partial JACK Implementation for checking out Manuel Kolp, University of Toronto, Department of Computer Science 20

Conclusion l Software Engineering in 2025 = Requirements Engineering + Software Geriatry + ? [van Lamsweerde ICSE’ 00 Keynote] l Narrowing the gap between requirements and architectures . . . we don’t want to freeze any more solutions to a given requirement in the software designs we produce!! IS (ERP, KM, e-business, e-marketplace, groupware, CRM, . . . ) in terms of the same social and intentional modeling concepts – i* from early requirements to detailed design. + formal Tropos language (inspired by KAOS) + formal analysis techniques: temporal (model checking), goal, and social structures, . . . Manuel Kolp, University of Toronto, Department of Computer Science 21