Requirements-Driven Information System Engineering

1. Requirements-DrivenInformation System Engineering John Mylopoulos University of Toronto Workshop on Agent-Based Information Systems Conference on Advanced Information Systems Engineering (CAiSE’99) Heidelberg, June 14-15 1999

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.

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??

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.

5. Requirements Analysis “...Requirements Engineeringis 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 -- 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 -- what will the system is to do • Non-functional (quality) requirements -- global constraints on how the system is to be constructed and function

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 Organizational model Requirements Contractual requirements System

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. • Structured and object-oriented analyses are OK for late requirements. • Goal-oriented analysis is more appropriate for early requirements analysis because it focuses on the definition and exploration of a space of alternatives

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.

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...

10. The i* Framework Maximize profits Insurance Company Customer Settle claim Car repaired Customer happy Goals are relative, fulfillment is collaborative

11. Means-Ends Analysis Handle claim Verify policy Claims Handling Settle claim Prepare offer Whose fault? Settlement cost? Determine fault Get accident info Actor boundary Determine cost to settle D D Minimal repairs D D Accident info Sufficient treatment D Injury info Police Appraise damage Doctor Appraiser Witness

12. Strategic Dependency Models Claims payout D Car repaired D D D Premium payment D D Pay repairs Insurance Company D D Repairs covered D Body Shop D Owner D Maximize estimate D D D D Customer happy D D Appraise damages D D Minimize repairs Continue business D Fair repair appraisal Secure employment D D Goal Resource Appraiser Task Softgoal

13. Where Are We?? Agent-oriented programming i* KAOS Z UML Detailed design Architectural design Early requirements Late requirements Implementation

14. Where Do We Want To Be?? Agent-oriented programming i* Detailed design Architectural design Late requirements Early requirements Implementation Guiding Principle: Push concepts as far down as possible (…and see what happens!)

15. 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.

16. The System as a Cluster of Actors Troubleshooting done D D Claims manager System Information Insurance company D D Reporting actor Tracking actor D D Information

17. 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 D D Customer Reporting actor Communicate(x)

18. Architectural Design with i* • 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

19. Architectural Design with i* Claims manager D Clerk Information D D Information’ Information D D D Interface manager D D Reporting actor D Transformer Tracking actor D D Information

20. Actor Assignments agent ContributeToMtg assignedTo Sally Initiator role UsefulMtg ScheduledMtg CalendarInfo Scheduler Participant assignedTo assignedTo AttendMtg Michael DeptChair SuitableTime position

21. 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.

22. 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 email, 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

23. 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...

24. 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.

25. 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.

26. So… Agent-Oriented Information Systems is the solution to Requirements-Driven Information Systems Engineering

27. References • [Yu94] Yu, E., Modelling Strategic Relationships for Process Reengineering, PhD thesis, Department of Computer Science, University of Toronto, December 1994.