20190104 - information systems re (use cases)agse.informatik.uni-kl.de/teaching/re/ws2018... · ©...
TRANSCRIPT
© Fraunhofer IESE
REQUIREMENTS ENGINEERINGLECTURE 2018/2019
Dr. Joerg Doerr
Information Systems REUse Case Analysis
© Fraunhofer IESE
2
AGENDA
Use Case Analysis
Specific Challenges & Aspects:Agile RE
© Fraunhofer IESE
3
How can Business Processes help to Determine theSystem Requirements?
Your ideas?
© Fraunhofer IESE
4
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?
© Fraunhofer IESE
5
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
© Fraunhofer IESE
6
Remember the Onion Model
System Context
Software System
System Context Boundary
System Boundary
© Fraunhofer IESE
7
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!
© Fraunhofer IESE
8
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?
© Fraunhofer IESE
9
Business Data
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
Business Data & Rules
© Fraunhofer IESE
10
Examples for Business Data from Exercise
Guest
Table
Reservation
Timeslot
Meal
Waiter
© Fraunhofer IESE
11
Table
ID
Business Data Modeling with UML
UML Class Diagrams are often used to model business data and their relationships
Guest
Timeslot
Dish Waiter
orders
reserves
serves
*
1..* 1..*
1..*
0..1 1
1
Working Hours
Begin
Price
Name
© Fraunhofer IESE
12
Business 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
Business Data & Rules
© Fraunhofer IESE
13
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.
© Fraunhofer IESE
14
USE CASE ANALYSISInformation Systems RE
© Fraunhofer IESE
15
Logical Phases in Information Systems RE
Stakeholder Project GoalsAddressed
Tasks & ProcessesProject Topic
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
Business Data & Rules
System Functions
InteractionsInteraction Data
& Rules
Logical GUI Structure
Step 1: Context Analysis
Step 2: Business Process & Data Analysis
Step 3: Use Case Analysis
© Fraunhofer IESE
16
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?
© Fraunhofer IESE
17
Use Cases…
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
Interactions
© Fraunhofer IESE
18
Use Case TemplateSSA.<Number>Name Name of the use case
Goal Goal and purpose of the use case (written as an extended user story or goal (state definition))
Role Reference to the role that enacts the interaction
Preconditions & input data
Conditions in the system that need to/must be met for executing the use case and needed input data and input documents
DescriptionIncl. called functions and exchanged data
Process of the regular interaction
1. The actor …
2. The system …
Exceptions Behavior in case of exception; per exception one description
Alternative descriptions Alternative processes (alternatives to the previous description)
Business rules Reference to business rules that are relevant while executing the interaction
Quality requirements Quality requirements that affect the whole process or single steps within the process (interaction)
Business data & documents
Reference to all relevant business data and documents
System functions Reference to system functions that represent the steps executed by the system
Interfaces Reference to interfaces, that are accessed while executing the interaction and its steps
Results (Postcondition) & output data
Status of the system, that is valid after successfully executing the interaction and its steps, as well as output data and documents
© Fraunhofer IESE
19
Use Case Example (Part 1)SSA.1Name Enter exemption from premium payment
Goal 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 B3. Case handler
Preconditions & input data
Request for exemption from premium payment (S1)
DescriptionIncl. called functions and exchanged data
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 3rd 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 3rd party dues are
existing or violated4. The system selects automatically the next possible date starting the exemption
from premium payment period (P2) based on the date of receipt. 5. …
Exceptions Case handler aborts the business function --> saves no data
Alternative descriptions -
…
© Fraunhofer IESE
20
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 3rd 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)
© Fraunhofer IESE
21
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 diagramcontains 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
© Fraunhofer IESE
22
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
© Fraunhofer IESE
23
Symbols
Use Cases in UML – Elements
RegistrationBooking
Case 1
Case 2
© Fraunhofer IESE
24
Task Overview: Use Case Diagram
Ordering
Consulting
Dispensing
Returning
Collecting
Registering
Deregistering
Counter employee
Publisher
Librarian
© Fraunhofer IESE
25
Use Cases in UML – Relationships
Inheritance
Include
Extends
Will be executed under certain conditions (option)
Clean roomClean suite
Provide room Clean room<<include>>
HandleOccupied Room Provide room<<extends>>
© Fraunhofer IESE
26
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
System Functions
© Fraunhofer IESE
27
System Responsibilities
To-be (Process) Situation
How Everything Fits Together
Business Process
Business Activity
System-supported Activity
System-automatedActivity
Interactions System Functions
is part of
is a
realizes realizes
is used in
Event-drivenProcess Chains
Business Rule & Dataworks on
Data & Rule Model
Rupp‘s Sentence Pattern
Tabular Use Case
© Fraunhofer IESE
28
Specific Aspect: RE in agile Settings
Especially in the Information Systems domain agile methodologies are popular
SCRUM is currently the most popular one
© Fraunhofer IESE
29
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 partof 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 thespecification detail. Rule of thumb: the „upper“ 20% of the backlog aresmall user stories (fine grained), the remaining 80% are coarse-grained(i.e., epics)
The process of refining a backlog item is called backlog grooming.
© Fraunhofer IESE
30
User Stories
User Stories are written on sheets of paper (e.g., sticky notes) orelectronically 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 beconsidered accepted by the stakeholders.
© Fraunhofer IESE
31
Identifying Good Quality in User Stories
User Stories shall fulfill the INVEST principle:Independent, Negotiable, Valuable, Estimatable, Small and Testable.
© Fraunhofer IESE
32
Questions