1 / 47

Advanced Information System Engineering

Advanced Information System Engineering. Lecture 4 SD3043. Outline. Requirements Engineering Different Requirements Elicitation Methods Goal Oriented Requirements Engineering Tropos concepts Tropos methodology Stages OME Tool Case Study step-by-step. Requirements Engineering.

tacy
Download Presentation

Advanced Information System Engineering

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. Advanced Information System Engineering Lecture 4 SD3043

  2. Outline Requirements Engineering Different Requirements Elicitation Methods Goal Oriented Requirements Engineering Tropos concepts Tropos methodology Stages OME Tool Case Study step-by-step

  3. Requirements Engineering • Each software system is built for a purpose • “Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation” (Nuseibeh, 2001) • Requirements should specify ‘what’ but not ‘how’ • ‘What’ refers to a system’s purpose • it is external to the system • it is a property of the application domain • “How’ refers to a system’s structure and behaviour • it is internal to the system • it is a property of the machine domain

  4. Functional vs Non Functional • “Functional Requirements” • fundamental functions of the system • E.g. mapping of inputs to outputs, control sequencing, formats of input and output data. • “Non-Functional Requirements (NFRs)” • constraints • E.g. security, safety, availability, usability, performance, portability,… Source: Adapted from van Vliet 1999, p241-2

  5. RE Elicitation Techniques • Traditional Approaches • Introspection • Interview/survey • Group elicitation • Observational approaches • Protocol analysis • Participant Observation • Model-based approaches • Scenarios: characterizations of the ways in which the system is used • Use Cases: specific instances of interaction with the system • Goal-based: hierarchies of stakeholders’ goals • Exploratory approaches • Prototyping (“plan to throw one away”) • http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf • Source: Adapted from Nuseibeh & Easterbrook, 2000 and van Vliet 1999, section 9.1.1

  6. RE Elicitation Techniques II • Most existing requirements techniques are intended more for the later phase of requirements engineering; • Requirements engineering research has taken as starting point the initial requirements statements, which express customer’s wishes about what the system should do; • Initial requirements are often ambiguous, incomplete, inconsistent, and usually expressed informally; • However, understanding the organizational context and rationales that lead up to systems requirements can be just as important for the ongoing success of the system; • “Early Phase” activities include those that consider • how the intended system would meet organizational goals • why the system is needed • what alternatives might exist • what the implications of the alternatives are for various stakeholders • how the stakeholders’ interests and concerns might be addressed.

  7. Goal Oriented RE Goal-oriented analysis focuses on early requirements, when problems are identified, and alternative solutions are explored and evaluated. During goal-oriented analysis, we start with initial stakeholder goals such “Schedule meeting” and keep refining them until we have reduced them to alternative collections of functional requirements each of which can satisfy the initial goals. Initial goals may be contradictory, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset.

  8. The electronic Single Assessment Process Case Study • Single Assessment Process (SAP), national policy about an integrated assessment of health and social care needs of older people • The purpose of the SAP is • to ensure that older people receive appropriate, effective and timely responses to their health and social care needs, and that professional resources are used effectively. • eSAP- electronic Single Assessment Process: an electronic system to deliver an integrated assessment of health and social care needs of older people. • http://ftp1.de.freebsd.org/Publications/CEUR-WS/Vol-57/id-16.pdf

  9. The eSAP context 9 • In the SAP, different health care professionals, such asgeneral practitioners, nurses and social workers, mustcooperate together in order to provide patients with appropriatecare • professionals work in teams : • Each team consists of many different professionals • Professionals cooperate between them • Professionals share information between them • Each professional has some expertise • Teams will promote person-centred care

  10. The eSAP context II • SAP provides the older person and their carer with a personal copy of their care plan to support person-centred care • The SAP works in three main stages: • contact assessment will provide basic information • overall assessment using a validated assessment instrument, such as Easy-Care, will take place • more care in particular problems and with more detailed assessment if appropriate.

  11. A Use Case Diagram(what important information is missing?)

  12. The Tropos Methodology • The framework was developed for modelling and reasoning about organizational environments and their information systems. • It adds a process to the i* framework modelling language • It consists of two main modelling components: • The ActorDiagram: used to describe the dependency relationships among various actors in an organizational context. • The Goal Diagram: is used to describe stakeholder interests and concerns, and how they might be addressed by various configurations of systems and environments.

  13. The i* language The central concept in i* is that of the intentional actor Organizational actors are viewed as having intentional properties such as goals, plans, beliefs, abilities, and commitments. Actors depend on each other for goals to be achieved, plans to be performed, and resources to be furnished. By depending on others, an actor may be able to achieve goals that are difficult or impossible to achieve on its own. On the other hand, an actor becomes vulnerable if the depended-on actors do not deliver. Actors are strategic in the sense that they are concerned about opportunities and vulnerabilities, and seek rearrangements of their environments that would better serve their interests.

  14. Graphical Representation of Tropos concepts Plan

  15. Actor • An actor represents an entity that has intentionality and strategic goals; • An actor can be a (social) agent, a position, or a role. • Agents can be physical agents, such as a person, or software agents. • Software agent is a software entity that has properties such as autonomy, social ability, reactivity, and proactivity. • A role represents an abstract characterisation of the behaviour of a social actor within some specialised context or domain of endeavour. • A position represents a set of roles, typically played by one agent.

  16. Goal In Tropos, the concept of a hard-goal (simply goal hereafter) is differentiated from the concept of soft-goal. A (hard) goal represents a condition in the world that an actor would like to achieve. In other words, goals represent actor’s strategic interests. A soft-goal is used to capture non-functional requirements of the system, and unlike a (hard) goal, it does not have clear criteria for deciding whether it is satisfied or not and therefore it is subject to interpretation. For instance, an example of a soft-goal is “the system should be scalable”.

  17. Plan A plan/task represents, at an abstract level, a way of doing something. The fulfilment of a task can be a means for satisfying a goal, or for contributing towards the satisficing of a soft-goal. In Tropos different (alternative) tasks, that actors might employ to achieve their goals, are modelled. Therefore developers can reason about the different ways that actors can achieve their goals and decide for the best possible way.

  18. Resource A resource presents a physical or informational entity that one of the actors requires. The main concern when dealing with resources is whether the resource is available and who is responsible for its delivery.

  19. Dependency A dependency between two actors represents that one actor depends on the other to attain some goal, execute a task, or deliver a resource. The depending actor is called the depender and the actor who is depended upon is called the dependee. The type of the dependency describes the nature of an agreement (called dependum) between dependee and depender. Goal dependencies represent delegation of responsibility for fulfilling a goal. Soft-goal dependencies are similar to goal dependencies, but their fulfilment cannot be defined precisely Task dependencies are used in situations where the dependee is required to perform a given activity. Resource dependencies require the dependee to provide a resource to the depender. By depending on the dependee for the dependum, the depender is able to achieve goals that it is otherwise unable to achieve on their own, or not as easily or not as well. On the other hand, the depender becomes vulnerable, since if the dependee fails to deliver the dependum, the depender is affected in their aim to achieve their goals.

  20. Modelling Activities Actor modelling consists of identifying and analysing the system’s domain actors as well as the actors of the system together with their goals. Dependency modelling, which involves the identification of the dependencies between the different actors. Goal modelling involves further analysis of particular actors’ goals, from the viewpoint of the actor. In other words, the internal goals of each actor identified through actor modelling are furthered analysed in order to provide a more precise definition of the actor. Soft-goal and task modelling are considered complimentary to the goal modelling activity and they employ similar reasoning techniques.

  21. Reasoning Techniques • Goal, soft-goal and plan modelling are mainly based on three reasoning techniques • Means-end analysis is employed to identify goals, soft-goals, plans, and/or resources that can provide means for reaching a goal. • Contribution analysis can be thought of as a special case of means-end analysis in which means are goals or soft-goals. Such analysis identifies goals that can contribute either positively or negatively to the achievement of other goals (or soft-goals). • Decomposition refers to the systematic breakdown of a component into simpler more specific components. • AND decomposition means all the sub-goals/sub-plans must be achieved for the root goal/task to be achieved, • OR decomposition means that the achievement of one of the sub-goals/sub-plans leads to the achievement of the root goal/task.

  22. Tropos Links

  23. The eSAP Case Study: Actor Diagram

  24. 24

  25. 25

  26. 26

  27. Tropos Methodology Stages Start Early Requirements Late Requirements Detailed Design Architectural Design End

  28. Early Requirements Stage • Developers are concerned with the understanding of a problem by studying an existing organisational setting. • Identification of the domain stakeholders and their modelling as social actors; • Model the stakeholders as actors, their intentions as goals, and their relationships as dependencies (Actor diagram); • Through a goal-oriented analysis, the actors’ goals are decomposed into more precise goals and sometimes into tasks that if performed by the actor, allow for goal achievement (Goal diagram); • The output of this phase is an organisational model (Actor and respective goal diagrams), which include relevant actors and their respective dependencies.

  29. Late Requirements Stage The system-to-be is specified within its operational environment, together with relevant functions and qualities. This description models the system as an actor, who has a number of dependencies with the actors identified during the previous stage. These dependencies indicate the obligations of the system towards its environment, and therefore define the system’s functional and non-functional requirements. Same models as Early Requirements but with the System!

  30. Stages / Diagrams • Early Requirements (only stakeholders) • Actor Diagram • Goal Diagrams for each actor • Late Requirements (stakeholders and System) • Actor Diagram • Goal Diagrams for each actor

  31. Organisational Modelling Environment (OME) Tool http://www.cs.toronto.edu/km/ome/

  32. Graphical Representation of Tropos concepts Plan

  33. eSAP Brief Description Single Assessment Process (SAP), an integrated assessment of health and social care needs of older people. The Single Assessment Process aims to create closer working for providing primary health and social care for older people and other groups. In the SAP setting, different health care professionals, such as general practitioners, nurses and social workers, must cooperate together in order to provide patients with appropriate care.

  34. Case Study: eSAP Stakeholders • Main Stakeholders: • Older Person (OP) is the patient that wishes to receive appropriate health and social care. • Department of Health (DoH) is the government department that must provide older people with health and social care. • R&D Agencies are agencies that wish to obtain information about older people to help them in their research.

  35. eSAP: Stakeholders’ Goals The Older Person actor has as a main goal to receive appropriate health and social care and as a soft goal to Maintain Good health. The Older Person depends on the DoH to accomplish their goal and soft goal. The DoH has as a main goal to Provide Better Health and Social Care to Elderly. The R&D Agency has a goal to Obtain Patient Information For Research.

  36. Early Requirements: Actor Diagram

  37. eSAP: OP Actor Analysis Older Person actor has as a goal to receive appropriate care and a soft goal to maintain good health. The receive appropriate care goal is fulfilled by the tasks Undertake Assessment, Follow Care Plan, Get Info about Care Plan, Obtain Medical Info, and Have Appointment with Professionals. To perform the last three tasks the Older Person must use the eSAP system, so the last three tasks are decomposed into the goal Use eSAP System.

  38. eSAP: OP extra dependencies In addition, the Maintain Good Health soft goal depends on the Follow Care Plan and Undertake Assessment tasks to be fulfilled. Furthermore, the Older Person depends on the DoH to make the Technology Infrastructure Available, and also to make the eSAP System Available and Easy-to-Use.

  39. Early Requirements: OP Goal Diagram

  40. eSAP: DoH analysis The main goal of the Department of Health is to Provide Better health and Social Care to Elderly. To accomplish this goal, DoH defines a sub goal to Make Care Person-Centred. The later is essential for the DoH to fulfil its main goal since the Older Person is the most important participant of the whole procedure, since they know better than anyone their difficulties and when they need health and social care.

  41. DoH Analysis (2) The Make Care Person-Centred goal is further decomposed into the two sub-goals Promote SAP and Involve Elderly in their Care. The later sub-goal depends on the task Provide Guidelines for the Older People to be fulfilled. The Promote SAP sub-goal is decomposed into the Computerise SAP goal and the Provide Guidelines for the SAP task. The later task is decomposed into two sub-tasks: Provide Guidelines for the Different Health and Social Care Professionals and Provide Guidelines for the Care-Teams.

  42. DoH Analysis (3) The first sub-task is further decomposed into four sub-tasks: Provide Guidelines for GPs, Provide Guidelines for Nurses, Provide Guidelines for Other Professionals and Provide Guidelines for Social Workers. In addition, to fulfil the Provide Guidelines for the Care-Teams goal each locality must comply with the proposed guidelines.

  43. DoH Analysis (4) Provide Efficient Care is another important goal of the DoH. To accomplish this goal the sub goal Computerise SAP has been identified. Computerising the SAP will help health and social care professionals to automate some procedures required while caring of the older person and thus help to Provide Efficient Care. To accomplish the Computerise eSAP sub goal, Technology Infrastructure must be provided and the eSAP System must be available. The goal Build eSAP is motivated by these two goals since it has no sub-goals.

  44. DoH Goal Diagram

  45. Late Requirements: eSAP Goal Diagram

  46. Conclusions 46 • Requirements Engineering • Goal Oriented RE • i* (http://www.cs.toronto.edu/km/istar) • Tropos (www.troposproject.org) • Next week: • Tool support (OME); • Create Actor and Goal Models for a Case Study • Tropos methodology Stages • OME Tool • Case Study step-by-step

  47. References • Requirements Engineering: A Roadmap http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf • Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering http://www.cs.toronto.edu/pub/eric/RE97.pdf • UML for Early Requirements Elicitation: A Regulation based Approach http://infoscience.epfl.ch/record/416/files/TR02_013.pdf • Using Tropos Methodology to Model an Integrated Health Assessment System http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-57/id-16.pdf • Tropos: An Agent-Oriented Software DevelopmentMethodology http://www.troposproject.org/

More Related