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

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

Embed Size (px)

description

A Methodology for Eliciting Requirements/Re-engineering Processes Using i*. Luiz Marcio Cysneiros Eric Yu Department of Computer Science – University of Toronto. Motivation. We want to be able to use I* in many different projects getting similar results (hopefully good ones) - PowerPoint PPT Presentation

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

  • A Methodology for Eliciting Requirements/Re-engineering Processes Using i* Luiz Marcio CysneirosEric YuDepartment of Computer Science University of Toronto

  • MotivationWe 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

  • What we Aim Define a systematic approach for using I* notationThis 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

  • 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 otherIdentify Main DependenciesIdentify The Main Tasks

    Identify the Main GoalsRefine The ModelsIdentify the Softgoals Look For alternative Ways

    Actual Process (Basically Non-Intentional)System-to-be

  • How ?Try to identify the Main Agents byGoing through all the documents available looking for possible AgentsUsing semi-structured interviews to ask stakeholders who are the main people actors involved with the systemRepresent these agents in the LEL and refine them

  • What is the LEL ?Aims to register the vocabulary used in the UofDIt is based on a system of symbols composed of Notions and Behavioral ResponsesNotions 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

  • How to build the LEL1. 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 used2. Identify information sources from initial contacts, may includepeople (stakeholders, participants) to interview/observe/survey, may be internal or external to the organization or processdocumentsprocedural manuals, guidelinesmission statements, objectivesjob descriptionsdata forms, reportsevaluation/analysis documents, inc. performance criteriaIT system descriptionsLegal DocumentsCarry out a Survey on Documents related to the problem domain

  • 3.Elicit statements of perceived problems from initial contactssponsors of the modelling exercise4.Determine scope and mandate of analysis and redesign (what can/not be changed)constraints economic, schedule, technology, political, legal5.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 roleDefine What is he/she responsible for ?Define What happens because this person existsFor 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?)

  • Basically we use Semi-Structured interviews and Document ReadingValidate 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 dont 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

  • Build a First Approach for the Social ContextCan and Must happen in parallel with the LEL constructionStarting 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:

  • PatientEmergency PatientElective PatientIsAIsA

  • NurseNurse ManagerHealth Care TeamPlaysIs part of

  • Build SD and SR ModelsIdentify 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 laterAlways check to be sure that you are using LEL symbols at least in SD modelsEventually 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 CurrentProcess

  • Identify Main DependenciesWhenever two symbols appear in the same sentence and both are subjects you should be facing a relationship among actorsThis kind of sentences may also hide Tasks, goals and resourcesOther subjects found in the notions may denote compositionFor each actor already found ask :On whom you depend on to do your job ?What other people / devices do you interact with ?

  • PatientNurseSocial WorkerAttending PhysicianHealth Care TeamCare LeaderDischargesAdmits Assesses

  • Identify the Main TasksTasks are frequently easier to elicit then goalsIn 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-versaSymbols classified as verbs are candidates to be tasks in both SD and SR modelsBehavioral Responses in symbols that represent agents frequently hide a goal or a taskTasks can later become goals once one finds out that the depender dos not care on how the dependee will perform this task

  • Some SR modeling May Now Take PlaceCommon Questions :For each agent found :What is this person responsible for ?What are the processes in which this person is involved ?Notice that although Im 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 PatientStart dischargingCoordinate discharging ProcessDescribe the scenarios that are pertinent to the problem , validate them with the stakeholders and model them into SR modelsBe sure that the SD model will reflect everything youre doing here (Using the contract all feature of OME3 tool for example)

  • 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

  • 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 processWhat are the reasons that led the stakeholder to establish it ?Why people do certain tasks ?

  • Identify Main GoalsCheck all the existing tasks to see if they are really tasks instead of goalsTo 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 goalsWhat 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 usefulCheck out for the need of privacy !This is not a top-down activity and neither bottom-up !

  • Modeling SoftgoalsFor 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 FrameworkRefinement can be either top-down or bottom-up, most likely to be a mix of both

  • Evaluate models for interdependencies (both positive and negative)Evaluate different graphs for the same type of NFREvaluate 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

  • Get New SolutionsFind all the goals not yet satisfied (all of them when youre 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 satisfiedEventually, turn the SR models into SD models or even into non-intentional models as WF so stakeholder can better visualize the final solution

  • The Case StudyWe are conducting a case study involving 3 major hospitals in TorontoThe case study tackles part of a larger project that is the non-paper projectSpecifically, we are studying the discharging process and the different ways it can be improvedUp to now we are close to end the non-intentional model, although many goals (hard and Soft) have been already elicitedWe 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

  • A Methodology for Eliciting Requirements/Re-engineering Processes Using i* Luiz Marcio CysneirosEric YuDepartment of Computer Science University of Toronto