Information Systems RE Business Process and Data Analysis (cont d) + Use Case Analysis

Transcription

1 REQUIREMENTS ENGINEERING LECTURE 2016/2017 Dr. Joerg Doerr Information Systems RE Business Process and Data Analysis (cont d) + Use Case Analysis

2 AGENDA Basics Context Analysis Business Process & Data Modeling EPC BPMN UML Use Case Analysis Specific Challenges & Aspects: Agile RE 2

3 Process Modeling with BPMN 3

4 Diagram elements overview Flow Objects Connectors Artifacts Swimlanes Association 4

5 Activities An activity is work that is performed within a business process. It can be atomic (i.e., a task) or compound (i.e., a sub process) 5

6 Events An Event is something that happens during the course of a business process. These Events affect the flow of the Process and usually have a trigger or a result. They can start, interrupt, or end the flow 6

7 Events 7

8 Gateways Gateways are elements used to control how Sequence Flows interact as they converge and diverge within a Process All types of Gateways are diamond-shaped Different internal markers indicate different types of behavior All Gateways both split and merge the flow A Gateway represents a place where control is needed 8

9 Gateways 9

10 Connectors Sequence Flow Message Flow Association 10

11 Data Objects Data Objects are Artifacts that are used to show how data and documents are used within a Process. Data Objects can be used to define inputs and outputs of activities. Data Objects can be given a state that shows how a document may be changed or updated within the Process 11

12 Swimlanes BPMN uses the concept known as swimlanes to help partition and/organize activities. There are two main types of swimlanes: Pool and Lane Pools represent Participants in an interactive (B2B) Business Process Diagram Lanes represent sub-partitions for the objects within a Pool 12

13 How can Business Processes help to Determine the System Requirements? Your ideas? 13

14 Decision Points at the Business Level How are the business processes and tasks currently performed? What are their strengths and weaknesses? How should the business processes and tasks be performed in the future in order to be able to achieve the project goals? Which parts / steps of the to-be business processes and tasks should be supported or even automated by the system to be developed? Which data and rules are relevant in the considered business processes and tasks? 14

15 System Boundary The system boundary separates the system to be developed from its environment; i.e., it separates the part of the reality that can be modified or altered by the development process from aspects of the environment that cannot be changed or modified by the development process. [IREB] In the information system domain, the system boundary separates the actual software system from its context, i.e., from the business environment / working environment. Hence, the system boundary is defined via system responsibilities, i.e., the parts of the business processes that should be supported or even automated by a software 15

16 Remember the Onion Model System Context Boundary System Boundary System Context Software System 16

17 Defining the System Boundary When defining the system boundary, requirements engineers have to be make the following decisions Which activities within the business processes are automated by the system? system-automated activities Which activities within the business processes are supported by the system? system-supported activities Which (further) interfaces exist between the system and its context? Note: 1. The system boundary is not always stable and may shift during a project, e.g., all functions to be provided by the system may not be clear at the beginning 2. However: A complete and precise definition of the system boundary is required at the end of the RE process! 17

18 Decision Points at the Business Level How are the business processes and tasks currently performed? What are their strengths and weaknesses? How should the business processes and tasks be performed in the future in order to be able to achieve the project goals? Which parts / steps of the to-be business processes and tasks should be supported or even automated by the system to be developed? Which data and rules are relevant in the considered business processes and tasks? 18

19 Business Data Business Data & Rules Describe (data) objects & documents with which the business processes and tasks work Consist of classes (e.g., customer ) and attributes (e.g., name ) Do not contain technical details such as format or data base schema Should be described at a central point in the document 19

20 Examples for Business Data from Exercise Guest Table Reservation Timeslot Meal Waiter 20

21 Business Data Modeling with UML UML Class Diagrams are often used to model business data and their relationships Guest Name * orders 0..1 reserves 1 1 Timeslot Table ID 1..* serves Begin 1..* 1..* Dish Price Waiter Working Hours 21

22 Business Rules Business Data & Rules Express any kind of rules on business data or business processes Types: facts, things that are given restrictions, things that are not allowed conditional actions, things that are done when something has happened conditional facts, things that become true when something has happened conditional calculations, things that are calculated when something has happened 22

23 Examples for Business Rules from Exercise facts, things that are given Each table has four seats. restrictions, things that are not allowed Reservations for tables must be done before 5 p.m. conditional actions, things that are done when something has happened When a guest comes more than 30 minutes later as his / her reservation time, the reservation is automatically deleted. conditional facts, things that become true when something has happened When a guest visits the restaurant for more than 3 times a month, he/she is a gold guest. conditional calculations, things that are calculated when something has happened If more than 10 dishes are ordered, the guest has only to pay 50% of the price. 23

24 Information Systems RE USE CASE ANALYSIS 24

25 Logical Phases in Information Systems RE Step 1: Context Analysis Project Topic Stakeholder Project Goals Addressed Tasks & Processes Step 3: Use Case Analysis As-is (Process) Situation To-be (Process) Situation System Responsibilities Interactions Interaction Data & Rules Business Data & Rules System Functions Step 2: Business Process & Data Analysis Logical GUI Structure 25

26 Decision Points at the Interaction Level How should users or external systems interact with the system to be developed for achieving the results of certain steps in the business processes? Which system functions are needed for realizing the system responsibilities or interactions? Which data are exchanged in these interactions? How should data and system functions be grouped logically within the user interface? How should data be grouped within a document? 26

27 Use Cases Interactions detail the system-supported activities (SSA) in a business process describe the desired interaction steps that users or external systems have to make for performing the SSA act as an anchor for other requirements 27

28 Use Case Template SSA.<Number> Name Goal Role Preconditions & input data Description Incl. called functions and exchanged data Exceptions Alternative descriptions Business rules Quality requirements Business data & documents System functions Interfaces Results (Postcondition) & output data Name of the use case Goal and purpose of the use case (written as an extended user story or goal (state definition)) Reference to the role that enacts the interaction Conditions in the system that need to/must be met for executing the use case and needed input data and input documents Process of the regular interaction 1. The actor 2. The system Behavior in case of exception; per exception one description Alternative processes (alternatives to the previous description) Reference to business rules that are relevant while executing the interaction Quality requirements that affect the whole process or single steps within the process (interaction) Reference to all relevant business data and documents Reference to system functions that represent the steps executed by the system Reference to interfaces, that are accessed while executing the interaction and its steps Status of the system, that is valid after successfully executing the interaction and its steps, as well as output data and documents 28

29 Use Case Example (Part 1) SSA.1 Name Goal Enter exemption from premium payment As a case handler I would like to process an exemption from premium payment in order to relieve a policyholder from paying his/her premiums. The system shall check the feasibility of the desired exemption from premium payment and in case it is feasible process the exemption automatically in order to reduce work effort and sources of error. Role Preconditions & input data Description Incl. called functions and exchanged data Exceptions B3. Case handler Request for exemption from premium payment (S1) 1. The actor enters to the system that s/he wants to conduct a future exemption from premium payment and enters (at the same time) the insurance number of the policy. 2. The system calls the business function for future premium exemption and checks whether any 3 rd party dues are existing on the policy (P1). 3. The actor enters the following data: Request date from the request for exemption from premium payment Date of receipt of the request for exemption from premium payment (from the optical archive) Approval of the exemption from premium payment, if no 3 rd party dues are existing or violated 4. The system selects automatically the next possible date starting the exemption from premium payment period (P2) based on the date of receipt. 5. Case handler aborts the business function --> saves no data 29 Alternative descriptions -

30 Use Case Example (Part 2) Business rules P1: Check for 3rd party dues P2: Term of exemption from premium payment P3: Possibility of exemption from premium payment P4: Minimum amount for exemption from premium payment according to general insurance conditions P5: Letter of insurance intermediary Quality requirements - Business data & documents D1: Data of exemption from premium payment S1: Request for exemption from premium payment S2: Letter of confirmation and copy of the letter S3: Letter of rejection and text module (depending on reason for rejection) and copy of the letter System functions F1. System selection of date starting the exemption from premium payment F2. Check, whether 3 rd party dues are existing F3. Feasibility check of the exemption from premium payment F4. Store the data of the use case F5. Creation of letter and copy Interfaces SST1: Printing Machine() SST2: Optical Archive () Results & output data Exemption from premium payment (has been accepted starting at a start date and for a specific period) or (has been rejected) Letter of (confirmation and copy) or (rejection with text module according to reason for rejection and copy) 30

31 Creation of Use Cases Identification of actors (especially identification of user roles) For every actor: identification of tasks (every task is at least one use case) Creation of a use case diagram contains all actors and use cases Detailed description of every use case Optimization of the use cases to avoid redundancy Priorization of use cases Clustering of use cases 31

32 Actor Is external to the software Interacting with the system (active or passive) An actor represents a human in a certain role or an external system, e.g.: correct: system administrator wrong: John Smith (what s his role?) right: database application 32

33 Use Cases in UML Elements Symbols Registration Booking Case 1 Case 2 33

34 Task Overview: Use Case Diagram Ordering Consulting Dispensing Publisher Counter employee Returning Collecting Registering Librarian Deregistering 34

35 Use Cases in UML Relationships Inheritance Clean room Clean suite Include Provide room <<include>> Clean room Extends Handle Occupied Room <<extends>> Provide room Will be executed under certain conditions (option) 35

36 System Functions System Functions Express any kind of functionality that is provided by the system Are either invoked by users in a step of a use case invoked by a process engine in a business process (as an SAA) by an external system via an interface performed in batch mode Note: System Functions are just one type of functional requirements 36

37 How Everything Fits Together Business Process Event-driven Process Chains To-be (Process) Situation is part of Business Activity works on Business Rule & Data Data & Rule Model is a System-supported System System-automated Activity Responsibilities Activity realizes realizes Tabular Use Case Interactions System Functions Rupp s Sentence Pattern is used in 37

38 Specific Aspect: RE in agile Settings Especially in the Information Systems domain agile methodologies are popular SCRUM is currently the most popular one 38

39 Requirements in Agile Settings (SCRUM) Requirements are organized in Product Backlogs (ordered Featurelists) One item in the product backlog is described by an epic (covering a part of the product (e.g., shopping basket in a webshop), a user story, an example and/or use cases. The higher the priority of the requirement, the more fine grained is the specification detail. Rule of thumb: the upper 20% of the backlog are small user stories (fine grained), the remaining 80% are coarse-grained (i.e., epics) The process of refining a backlog item is called backlog grooming. 39

40 User Stories User Stories are written on sheets of paper (e.g., sticky notes) or electronically in tools. Front side uses a sentence pattern: As a <<role>> I want <<function>> so that I can <<goal/rationale>>. E.g.: As a sales person I want to see the sum of my purchase so that I can pay my bill. The rear side contains the acceptance criteria when a user story can be considered accepted by the stakeholders. 40

41 Identifying Good Quality in User Stories User Stories shall fulfill the INVEST principle: Independent, Negotiable, Valuable, Estimatable, Small and Testable. 41

42 Questions 42