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

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


  • 111 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Methodology for Eliciting Requirements/Re-engineering Processes Using i*' - eyad


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A methodology for eliciting requirements re engineering processes using i

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

Luiz Marcio Cysneiros

Eric Yu

Department of Computer Science – University of Toronto


Motivation
Motivation Processes Using i*

  • 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


What we aim
What we Aim Processes Using i*

  • 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


What is proposed
What is Proposed Processes Using i*

  • 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


A methodology for eliciting requirements re engineering processes using i
How ? Processes Using i*

  • 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


What is the lel
What is the LEL ? Processes Using i*

  • 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


How to build the lel
How to build the LEL Processes Using i*

  • 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


A methodology for eliciting requirements re engineering processes using i

  • 3. Processes Using i* 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?)


A methodology for eliciting requirements re engineering processes using i

  • 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


Build a first approach for the social context
Build a First Approach for the Social Context Reading

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


A methodology for eliciting requirements re engineering processes using i

Patient Reading

IsA

IsA

Elective

Patient

Emergency

Patient


A methodology for eliciting requirements re engineering processes using i

Nurse Reading

Is part of

Plays

Health

Care

Team

Nurse

Manager


Build sd and sr models
Build SD and SR Models Reading

  • 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


Identify main dependencies
Identify Main Dependencies Reading

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


A methodology for eliciting requirements re engineering processes using i

Nurse Reading

Assesses

Patient

Care Leader

Social Worker

Admits

Discharges

Attending Physician

Health Care Team


Identify the main tasks
Identify the Main Tasks Reading

  • 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


Some sr modeling may now take place
Some SR modeling May Now Take Place Reading

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


A methodology for eliciting requirements re engineering processes using i


Modeling intentionalities
Modeling Intentionalities process is now understood and correctly modeled

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


Identify main goals
Identify Main Goals process is now understood and correctly modeled

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


Modeling softgoals
Modeling Softgoals process is now understood and correctly modeled

  • 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


A methodology for eliciting requirements re engineering processes using i

  • 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


Get new solutions
Get New Solutions negative)

  • 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


The case study
The Case Study negative)

  • 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


A methodology for eliciting requirements re engineering processes using i

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

Luiz Marcio Cysneiros

Eric Yu

Department of Computer Science – University of Toronto