1 / 14

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

Tropos workshop Trento, November 15-16th, 2001. Using i* for early requirements of a computer system for hospital emergency departments. Michaël Petit Albert team (Formal Requirements Engineering) Anne Rousseau CITA team (Quality management/Organisational theory) ARTHUR Project

chelsea-roth
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tropos workshop Trento, November 15-16th, 2001 Using i* for early requirements of a computer system for hospital emergency departments Michaël Petit Albert team (Formal Requirements Engineering) Anne Rousseau CITA team (Quality management/Organisational theory) ARTHUR Project University of Namur, CS department

  2. Outline • The project • The process • Using i* • Evaluation/Perspectives/Issues

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

  4. The process Preliminary study Description of EDs (text) Observations Study of existing System (EDs) Description of general objectives of EDs Interviews Observations Organisational Diagnostic Needs and opportunities (6 “scenarios”) Interviews For each scenario Existing behaviour (UML) Detailed study Detailed objectives Observations Study of existing behaviour and objectives Detailed diagnostic Interviews System spec (UML) Requirements specification Validation sessions Requirements Doc (IEEE std 830) Design and Implementation Rationale

  5. Using i* Preliminary study Description of EDs (text) Observations Study of existing System (EDs) Description of general objectives of EDs Interviews Observations Organisational Diagnostic Needs and opportunities (6 “scenarios”) Interviews For each scenario Existing behaviour (UML) Detailed requirements study Detailed objectives Observations Study of existing behaviour and objectives Detailed diagnostic Interviews System spec (UML) Requirements specification Validation sessions Requirements Doc (IEEE std 830) Design and Implementation Rationale

  6. Using i* in the preliminary study

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

  8. Using i* Preliminary study Description of EDs (text) Observations Study of existing System (EDs) Description of objectives of EDs Interviews Observations Organisational Diagnostic Needs and opportunities (6 “scenarios”) Interviews For each scenario Existing behaviour (UML) Detailed requirements study Detailed objectives Observations Study of existing behaviour and objectives Detailed diagnostic Interviews System spec (UML) Requirements specification Validation sessions Requirements Doc (IEEE std 830) Design and Implementation Rationale

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

  10. Using i* in the detailed requirements study: 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!

  11. Using i* Preliminary study Description of EDs (text) Observations Study of existing System (EDs) Description of objectives of EDs Interviews Observations Organisational Diagnostic Needs and opportunities (6 “scenarios”) Interviews For each scenario Existing behaviour (UML) Detailed requirements study Detailed objectives Observations Study of existing behaviour and objectives Detailed diagnostic Interviews System spec (UML) Requirements specification Validation sessions Requirements Doc (IEEE std 830) Design and Implementation Rationale

  12. Using i* for system requirements rationales

  13. Using i* for system requirements rationales UML model (use cases,...)

  14. Conclusion • 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

More Related