A Methodology for Eliciting Requirements/Re-engineering Processes Using i*

1. A Methodology for Eliciting Requirements/Re-engineering Processes Using i* Luiz Marcio Cysneiros Eric Yu Department of Computer Science – University of Toronto

2. Motivation • We want to be able to use I* in many different projects getting similar results (hopefully good ones) • Lack of a systematic approach on how to use I* in software development / BRP

3. What we Aim • Define a systematic approach for using I* notation • This methodology should : • Provide ways of specifying a current process/system and the many possible ways of getting to a new desirable process (system-to-be) • Focus on How to get the correct information and how to model it using I* • Be well defined so it can be repeatedly used in a consistent manner

4. What is Proposed • Identify the common terms used in the domain (Using the Language Extended Lexicon) • Identify the main Agents involved in the process and how they relate to each other • Identify Main Dependencies • Identify The Main Tasks • Identify the Main Goals • Refine The Models • Identify the Softgoals • Look For alternative Ways Actual Process (Basically Non-Intentional) System-to-be

5. How ? • Try to identify the Main Agents by • Going through all the documents available looking for possible Agents • Using semi-structured interviews to ask stakeholders who are the main people “actors” involved with the system • Represent these agents in the LEL and refine them

6. What is the LEL ? • Aims to register the vocabulary used in the UofD • It is based on a system of symbols composed of Notions and Behavioral Responses • Notions specify the meaning of the symbol (denotation) • Behavioral Responses register the results driven from the symbol utilization (connotation) • Its construction is based on the minimum vocabulary and circularity principles

8. How to build the LEL • 1. Perform a brainstorm meeting with some or all (depending on either availability and political aspects) of the stakeholders. Try to get a general idea of the problem and to identify possible documents to be used • 2. Identify information sources from initial contacts, may include • people (stakeholders, participants) to interview/observe/survey, may be internal or external to the organization or process • documents • procedural manuals, guidelines • mission statements, objectives • job descriptions • data forms, reports • evaluation/analysis documents, inc. performance criteria • IT system descriptions • Legal Documents • Carry out a Survey on Documents related to the problem domain

9. 3. Elicit statements of perceived problems from • initial contacts • sponsors of the modelling exercise • 4. Determine scope and mandate of analysis and redesign (what can/not be changed) • constraints – economic, schedule, technology, political, legal… • 5. Important Question : Why do you need this system ? • 6. Common questions to be used : • What are the people (agents) involved in the process ? • For each of the people involved • Define What is his/her role • Define What is he/she responsible for ? • Define What happens because this person exists • For each of the people involved, What are, if any, the other people(agents) that this one interacts with? (Who do you depend on to get your work done?)

10. Basically we use Semi-Structured interviews and Document Reading • Validate the Lexicon use the Stakeholders !! • Do it frequently ! • All tasks, goals, resources and actors have to be a symbol of the LEL (at least in SD models). • If you don’t find a symbol to represent one of the above elements, either there is a symbol with a synonym not yet identified or a symbol is missing in the lexicon and therefore must be added

11. Build a First Approach for the Social Context • Can and Must happen in parallel with the LEL construction • Starting Picking up all the Symbols of the LEL classified as subject. They are all strong candidates to be agents • For each one of the symbols that you picked up to be an agent, look if any other agent is present in the notions of this symbol • Symbols Classified as verbs can be either a task/goal or a role. Be careful. • Ex:

12. Patient IsA IsA Elective Patient Emergency Patient

13. Nurse Is part of Plays Health Care Team Nurse Manager

15. Build SD and SR Models • Identify Main Dependencies • Identify The Main Tasks • Do it using a mix of semi-structured interviews, document reading, observation and protocol analysis. • Start refining Actors into Agent, Roles and Position. IF the model starts to get confusing STOP. Come back to it later • Always check to be sure that you are using LEL symbols at least in SD models • Eventually use non-intentional process models as Workflow, DFD or UML diagrams • Some Hard and Soft goal may eventually be elicited during this process but we will not be targeting it Current Process

16. Identify Main Dependencies • Whenever two symbols appear in the same sentence and both are subjects you should be facing a relationship among actors • This kind of sentences may also hide Tasks, goals and resources • Other subjects found in the notions may denote composition • For each actor already found ask : On whom you depend on to do your job ? What other people / devices do you interact with ?

17. Nurse Assesses Patient Care Leader Social Worker Admits Discharges Attending Physician Health Care Team

18. Identify the Main Tasks • Tasks are frequently easier to elicit then goals • In many of the projects where KAOS was used the goals underlying the process were implicit and not really visible in the first place [Van Lamsweerde 98] • Findings in the SD model can help building SR model and vice-versa • Symbols classified as verbs are candidates to be tasks in both SD and SR models • Behavioral Responses in symbols that represent agents frequently hide a goal or a task • Tasks can later become goals once one finds out that the depender dos not care on how the dependee will perform this task

19. Some SR modeling May Now Take Place • Common Questions : • For each agent found : • What is this person responsible for ? • What are the processes in which this person is involved ? • Notice that although I’m focused on getting the current process and not the reasons behind it, sometimes these reason will become quite clear and hence should be modeled. • Use scenarios to refine tasks and to expand an actor. For example : • In What possible scenarios could Nurse be involved ? • Assess Patient • Start discharging • Coordinate discharging Process • Describe the scenarios that are pertinent to the problem , validate them with the stakeholders and model them into SR models • Be sure that the SD model will reflect everything you’re doing here (Using the contract all feature of OME3 tool for example)

22. Keep this process until getting an agreement that the actual process is now understood and correctly modeled • Add new symbols to the LEL whenever you find it necessary. LEL construction can be seen as a continuos process

23. Modeling Intentionalities • Once I have modeled the current process it is time to find out why the process is that way. • Try to determine not only agents goals but most of all organizational goals. What underlies the current process • What are the reasons that led the stakeholder to establish it ? • Why people do certain tasks ?

24. Identify Main Goals • Check all the existing tasks to see if they are really tasks instead of goals • To each activity or cluster of activities : • Why this agent need to perform this task ? • Why it has to be performed this way ? • Are there alternative ways of doing that ? • Keep asking why so you can get to high-level goals • What is wrong with the process ? • What should be changed ? • What could be better ? • Which goals are not satisfied ? Why ? • Introducing new actors can improve the process ? • Relocating responsibilities can improve the process ? • Use mainly semi-structured interviews and document readings. Eventually, protocol analysis can be useful • Check out for the need of privacy ! • This is not a top-down activity and neither bottom-up !

25. Modeling Softgoals • For each goal try to ask yourself and the stakeholder what NFR would be desirable. • Do we need Safety ? • Do we need Accuracy ? • Do we need Performance ? …… • Whenever the answer is yes, represent it in the model and refine it as in NFR Framework • Refinement can be either top-down or bottom-up, most likely to be a mix of both

26. Evaluate models for interdependencies (both positive and negative) • Evaluate different graphs for the same type of NFR • Evaluate graphs for NFR graphs that are frequently conflicting (e.g. Usability and Security) • If the number of graphs is not too large pair wise different graphs (excluding those previously compared) • Negotiate with the stakeholders the different designs that could result from different ways of satisfying these NFR

27. Get New Solutions • Find all the goals not yet satisfied (all of them when you’re doing the first pass) and decide how this goal will be achieved (choose among different ways) • At the end, all top goals (hard and soft) must be satisfied • Eventually, turn the SR models into SD models or even into non-intentional models as WF so stakeholder can better visualize the final solution

28. The Case Study • We are conducting a case study involving 3 major hospitals in Toronto • The case study tackles part of a larger project that is the non-paper project • Specifically, we are studying the discharging process and the different ways it can be improved • Up to now we are close to end the non-intentional model, although many goals (hard and Soft) have been already elicited • We are also getting note of how much time we are spending in each kind of task so we can have an idea of what are the critical task (regarding time) of the methodology

29. A Methodology for Eliciting Requirements/Re-engineering Processes Using i* Luiz Marcio Cysneiros Eric Yu Department of Computer Science – University of Toronto