 1999 John Mylopoulos Requirements-Driven IS Engineering -- 1 Requirements-Driven Information System Engineering John Mylopoulos University of Toronto Workshop on Agent-Based Information Systems Conference on Advanced Information Systems Engineering (CAiSE’99) Heidelberg, June

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 2 Abstract Information Systems Engineering has traditionally been implementation-driven in the sense that the programming paradigm of the day (structured programming, object-oriented programming) dictated the design and requirements analysis techniques widely used (structured analysis and design, object-oriented analysis and design). We speculate on what an information systems engineering methodology might look like if it was founded on early requirements analysis techniques. For our purposes, we adopt i* as modeling framework. i* supports concepts such as those of actor, agent, position and role, also resource, task and goal dependencies among actors. The presentation suggests elements of late requirements analysis, architectural and detailed design through examples, and notes a number of areas where such a methodology might break new ground with respect to traditional information systems engineering, as well as agent-oriented programming.

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 3 Information System Engineering Information System (hereafter IS) Engineering is concerned with concepts, tools and methods for building information systems. Traditionally, IS Engineering has been implementation-driven. This means that the programming paradigm of the day dictated the design and requirements paradigms. So, structured programming led to structured design and (requirements) analysis, while object-oriented programming led to object-oriented design and analysis. Aligning the paradigms used for requirements, design and implementation makes perfect sense. But why start with implementation? What would requirements-driven IS Engineering look like??

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 4 Why Requirements-Driven? Requirements analysis is arguably the most important phase of information system development; that’s where the most and the costliest errors are introduced in software systems. The importance of detailed design and implementation will wear off over time, thanks to software reuse, COTS and the like; requirements analysis will always be there and will always be important. Requirements analysis is the phase where technology meets the real world, where technical considerations have to be balanced against personal, organizational and social ones; this calls for special skills on the part of the requirements engineer, and makes the phase particularly challenging.

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 5 Requirements Analysis Requirements Engineering “...Requirements Engineering is the branch of systems engineering concerned with real-world goals for, services provided by, and constraints on software systems. Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behaviour and to their evolution over time and across system families...” [Zave94] This activity traditionally boils down to three tasks: Context analysis whyContext analysis -- the reasons why the system is to be created and why certain technical operational and economic feasibilities are the criteria that form boundary conditions for the system Functional requirements whatFunctional requirements -- what will the system is to do Non-functional (quality) requirements howNon-functional (quality) requirements -- global constraints on how the system is to be constructed and function

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 6 Early vs Late Requirements We need to distinguish between early phases of requirements analysis, when the analyst is trying to understand an organizational setting, from late phases when the analyst formulates a solution Organization System Organizational model Contractual requirements Requirements

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 7 Early vs Late Requirements Early requirements amount to the definition of a search space (“scoping”) and a search among alternatives within that space. Late requirements amount to refining, disambiguating and completing the description of the chosen alternative. Structuredobject-oriented analyses Structured and object-oriented analyses are OK for late requirements. Goal-oriented analysis Goal-oriented analysis is more appropriate for early requirements analysis because it focuses on the definition and exploration of a space of alternatives

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 8 Goal-Oriented Analysis Goal-oriented analysis focuses on early requirements phases, when alternatives are being explored and evaluated. During goal-oriented analysis, we start with initial goals such as “Higher profits”, “Faster time-to-market”, “Schedule meeting”, “Easily maintainable system”, “Good performance” etc. and keep decomposing them until we have reduced them to alternative collections of design decisions each of which can satisfy the initial goals. Initial goals may be organization- or system-oriented; they may also be contradictory, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset.

 1999 John Mylopoulos Requirements-Driven IS Engineering -- 9 Goal-Oriented Analysis is not New! Specification of composite systems -- [Feather87] Goal-oriented elaboration of requirements -- ALBERT [Dubois94] Goal-oriented requirements acquisition -- KAOS [Dardenne93] Knowledge representation and reasoning in the design of composite systems -- Critter [Fickas92] Goal-oriented requirements analysis -- Potts, Anton I* and Non-Functional Requirements framework -- Yu, Chung NATURE -- [Jarke93] F3 -- [Bubenko93]...and many others...

 1999 John Mylopoulos Requirements-Driven IS Engineering The i* Framework Customer Insurance Company Car repaired Customer happy Settle claim Maximize profits Goals are relative, fulfillment is collaborative

 1999 John Mylopoulos Requirements-Driven IS Engineering Means-Ends Analysis Settle claim Verify policy ClaimsHandlingClaimsHandling Handle claim Settlement cost? Prepare offer Whose fault? Get accident info Determine fault Police Witness Doctor Appraiser Determine cost to settle Accident info Sufficient treatment Injury info Appraise damage Minimal repairs D D D D D Actorboundary

 1999 John Mylopoulos Requirements-Driven IS Engineering Strategic Dependency Models Body Shop Owner Appraiser Insurance Company Car repaired Pay repairs Maximize estimate Continue business D D DD DD D D D D D D D D D D D D Claims payout Premium payment D D Customer happy Repairs covered D D Appraise damages Minimize repairs Secure employment Fair repair appraisal Goal Task Resource Softgoal

 1999 John Mylopoulos Requirements-Driven IS Engineering Where Are We?? Earlyrequirements Laterequirements Architecturaldesign Detaileddesign Implementation i* KAOS Z UML Agent-orientedprogramming

 1999 John Mylopoulos Requirements-Driven IS Engineering Where Do We Want To Be?? Earlyrequirements Laterequirements Architecturaldesign Detaileddesign Implementation i* Agent-orientedprogramming Guiding Principle: Push concepts as far down as possible (…and see what happens!)

 1999 John Mylopoulos Requirements-Driven IS Engineering Late Requirements with i* The system is now represented as one or more actors which participate in a strategic dependency model. Resource, task and softgoal dependencies correspond naturally to functional and non-functional requirements. Leaving (some) goal dependencies between software system actors and other actors is a novelty. Traditionally, functional goals are “operationalized” during late requirements, and quality softgoals are either operationalized or “metricized”. Leaving goal dependencies with system actors as dependees makes sense whenever there is a foreseeable need for flexibility in the performance of a task on the part of the system.

 1999 John Mylopoulos Requirements-Driven IS Engineering Insurance company Tracking actor Claims manager Reporting actor System D D D Information D The System as a Cluster of Actors Troubleshooting done D D

 1999 John Mylopoulos Requirements-Driven IS Engineering Goals Mean Flexibility Consider a goal laid out during early requirements “communicate(x,y)”. Conventionally, such goals are “operationalized” during late requirements into “constraints” for the system-to-be, such as having a user interface, also supporting a dialogue during which information x is communicated to person y. Such “operationalizations” lead to fragile systems; …what if y doesn’t engage in dialogue with the system?… y doesn’t understand the message?… the system crashes during the dialogue?… etc. Leaving the communication goal as part of the late requirements spec, or even the design means that the system-to-be will be designed with several alternative strategies for satisfying the goal, including getting help from outside Reporting actor D D Customer Communicate(x)

 1999 John Mylopoulos Requirements-Driven IS Engineering Now we focus on actors that are part of the system. Add actors, in addition to those inherited from requirements to meet the obligations of existing (system) actors. Decide whether actors will be agents, positions, or roles. Actor agent if the fulfillment of its obligations requires unique skills (e.g., troubleshooting). Actor position if there are generic agents which have suitable skills; for example, information management might use a DBMS agent, tracking might employ (…) a workflow agent. Actor role if another actor (agent, position) within the system has the skills to meet assigned obligation; for example, a DBMS agent holding an information management position can play the role of information provider for a particular project Architectural Design with i*

 1999 John Mylopoulos Requirements-Driven IS Engineering Architectural Design with i* Tracking actor Claims manager Reporting actor D D D Information D Interface manager D Clerk D D Transformer D Information D D Information’ D

 1999 John Mylopoulos Requirements-Driven IS Engineering Participant Initiator ContributeToMtg AttendMtg UsefulMtg Scheduler CalendarInfo ScheduledMtg SuitableTime Sally Michael DeptChair assignedTo role position agent Actor Assignments

 1999 John Mylopoulos Requirements-Driven IS Engineering Detailed Design The skills of all actors and their input/output data are refined using some specification technique. Agent infrastructure is defined, including communication and collaboration protocols. Infrastructure actors are introduced, such as Hiring actors, i.e., ones for filling positions; Headhunters, i.e., actors who look for agents to fill positions at run time; Dependency managers who supervise dependencies and determine whether they remain viable.

 1999 John Mylopoulos Requirements-Driven IS Engineering Implementation with i* Agents are implemented. Implement positions and roles, given assigned agents. If there are dangling goal dependencies, build into the responsible agent skills for meeting these goals. E.g., a communication goal might be met through repeated , asking a third party to communicate etc. If there are dangling softgoal dependencies, build into the responsible agent skills for addressing such softgoals. E.g., a security agent would have a number of ways of meeting security goals

 1999 John Mylopoulos Requirements-Driven IS Engineering Forms of Analysis Each IS development paradigm encourages different types of analysis. Structured techniques focused on information transformations, OO ones on types of information and the behaviours of each type. Actor-oriented techniques encourage answers to the following questions: Who are the relevant actors and what are their goals? Who can satisfy/satisfice a goal/softgoal? How do we establish an obligation for an actor to deliver on a dependence? Does this process have the right effects? …more...

 1999 John Mylopoulos Requirements-Driven IS Engineering Remarks There are three mechanisms that are interesting here from a Information Systems perspective: Goals stay around until after early requirements and as long as run-time; Position and role filling may take place somewhere between architectural design and run-time; Dependencies may be created during requirements analysis and design time, or at run-time, and they need to be managed. None of these is novel to agent programming; what is novel from that perspective is the idea that these mechanisms may be exploited during early phases of software development to offer a whole new dimension to agent-based system design.

 1999 John Mylopoulos Requirements-Driven IS Engineering Conclusions From an Information Systems perspective, this proposal, however speculative, has advantages: Leads to more flexible, robust and open architectures; Offers a coherent framework which encompasses all phases of software development, from early requirements to implementation Is consistent with the next generation programming paradigm. As well, from an Agent-Based Systems perspective the proposal Suggests a comprehensive methodology for building software; Offers a new dimension along which one decides flexibility+robustness vs performance tradeoffs. …BUT,…all this is just a proposal, which needs to be validated and elaborated by research.

 1999 John Mylopoulos Requirements-Driven IS Engineering So… Agent-Oriented Information Systems is the solution to Requirements-Driven Information Systems Engineering

 1999 John Mylopoulos Requirements-Driven IS Engineering References [Yu94] Yu, E., Modelling Strategic Relationships for Process Reengineering, PhD thesis, Department of Computer Science, University of Toronto, December 1994.