Using i* for early requirements of a Using i* for early requirements of a computer system for hospital computer system for hospital

emergency departmentsemergency departmentsMichaël Petit

Albert team (Formal Requirements Engineering)

Anne RousseauCITA team

(Quality management/Organisational theory)

ARTHUR ProjectUniversity of Namur, CS department

Tropos workshopTropos workshop

Trento, November 15-16th, 2001Trento, November 15-16th, 2001

OutlineOutline

• The project

• The process

• Using i*

• Evaluation/Perspectives/Issues

The ARTHUR projectThe ARTHUR project

• ARchitecture for Telecommunication in Hospital Emergency (URgence) departments

• Research and development project• Innovative technologies

– Speach recognition– Cryptography, identification– Wireless networks/handheld

• Prototype IT system for– Supporting inhouse activity– Supporting communication during external

activity (ambulances, inter-hospital,...)– for three partner EDs but generic...

• Our role: write the RD (requirements mostly unknown!)• Collaboration with organisational theory specialists:

– Suitability of the proposed system to the organisations– Observation of the system appropriation after implantation

The processThe process

Preliminary study

Study of existing System (EDs)

Organisational Diagnostic

Detailed study

Needs and opportunities (6 “scenarios”)

Study of existing behaviour and objectives

Observations

Interviews

Description of EDs (text)

Description of generalobjectives of EDs

Observations

Interviews

For each scenario

Existing behaviour (UML)

Detailed objectives

Design and Implementation

Requirements specificationValidation

sessions

System spec (UML)

Requirements Doc (IEEE std 830)

Rationale

Detailed diagnostic

Observations

Interviews

Using i*Using i*

Preliminary study

Study of existing System (EDs)

Organisational Diagnostic

Detailed requirements study

Needs and opportunities (6 “scenarios”)

Study of existing behaviour and objectives

Observations

Interviews

Description of EDs (text)

Description of generalobjectives of EDs

Observations

Interviews

For each scenario

Existing behaviour (UML)

Detailed objectives

Design and Implementation

Requirements specificationValidation

sessions

System spec (UML)

Requirements Doc (IEEE std 830)

Rationale

Detailed diagnostic

Observations

Interviews

Using i* in the preliminary studyUsing i* in the preliminary study

Using i* in the preliminary studyUsing i* in the preliminary study

• Coupled with other documents (textual)• Refining and making more precise the organisational

diagnostic• In progress

– Refine some softgoals, add more– Detect more contributions– Represent existing system elements (procedures, IS, ...) and

label softgoals– Detail individual actors objectives (political and cultural view)!

(Strategic dependency model)

• Importance of a glossary for softgoals (and other elements)

• Diagnostic to be validated– How to validate with stakeholders?

Using i*Using i*

Preliminary study

Study of existing System (EDs)

Organisational Diagnostic

Detailed requirements study

Needs and opportunities (6 “scenarios”)

Study of existing behaviour and objectives

Observations

Interviews

Description of EDs (text)

Description of objectives of EDs

Observations

Interviews

For each scenario

Existing behaviour (UML)

Detailed objectives

Design and Implementation

Requirements specificationValidation

sessions

System spec (UML)

Requirements Doc (IEEE std 830)

Rationale

Detailed diagnostic

Observations

Interviews

Using i* in the detailed requirements Using i* in the detailed requirements study: detailed objectives of lab testsstudy: detailed objectives of lab tests

Using i* in the detailed requirements Using i* in the detailed requirements study: detailed diagnostic of lab testsstudy: detailed diagnostic of lab tests

• Observed scenarios – specified in UML (use cases)– Classified as:

• Allowed/benefical. E.g: urgent patient

• Harmfull/To be avoided. E.g. Multiple blood sample taking

• Current procedures identified in the i* model as tasks having an influence on objectives

• Labeling of the i* model will be used to formalise the diagnostic

• Basis for definition of new objectives and requirements• In progress:

– Strategic dependency model– Detailed diagnostic to be validated!

Using i*Using i*

Preliminary study

Study of existing System (EDs)

Organisational Diagnostic

Detailed requirements study

Needs and opportunities (6 “scenarios”)

Study of existing behaviour and objectives

Observations

Interviews

Description of EDs (text)

Description of objectives of EDs

Observations

Interviews

For each scenario

Existing behaviour (UML)

Detailed objectives

Design and Implementation

Requirements specificationValidation

sessions

System spec (UML)

Requirements Doc (IEEE std 830)

Rationale

Detailed diagnostic

Observations

Interviews

Using i* for system requirements Using i* for system requirements rationalesrationales

Using i* for system requirements Using i* for system requirements rationalesrationales

UML model (use cases,...)

ConclusionConclusion

• Traceability• Main i* advantages

– Make diagnostics more precise– Provide software requirements rationales

• Open issues– Validation of objectives and diagnostics– Validation of justification of software requirements– Presentation/explanation of large models

• Research perspectives– Formalise organisational theory knowledge for EDs– Influence of project members constraints and motivations on the

implemented requirements– Runtime tradeoffs