SYSTEMS ANALYSIS project

1

ISMM1-UC 752: SYSTEMS ANALYSIS

Fall 2019 – Week 9 Instructor: Dr. Antonios Saravanos

1

Use Case Diagram Syntax

• Actor – person or system that derives benefit

from and is external to the subject • Use Case

– Represents a major piece of system functionality

• Association Relationship • Include Relationship • Extend Relationship • Generalization Relationship

<<extends>>

<<includes>>

2

2

Use Case Elements: Relationships

• Association documents the communication between the use case and the actors that use the use case

• Extend represents the extension of the functionality of the use case to incorporate optional behavior

• Include shows the mandatory inclusion of another use case

• Generalization allows use cases to support inheritance

3

Modeling • An abstract representation of a system from a specific point of view

– A model expresses the essentials of a situation – A model does not give unnecessary information

• The Unified Modeling Language (UML) is general-purpose modeling language in the field of software engineering a standardized (ISO 19501)

4

4

3

Use-Cases • Schematic diagrams that show how various tasks are completed using

boxes and arrows to show the flow – Often grow out of the needs identified in a user story

• A form of requirements documentation • Allows us to build an abstract model of a system from the perspective of

the user

Source: Usable Usability: Simple Steps for Making Stuff Better 5

5

Use-Case • Graphical

– Easy to read diagrams – Diagrams can help facilitate meetings

• Textual – Scenarios

• Essentially a story that describes an interaction with the system • Conceptual basis for use cases

6

6

4

Representing a Use-Case • An oval with a title that reflects something that a user wants in its centre

Create Report

7

7

Actors • Actors represent roles not individuals that interact with the system

– An actor is an agent that acts upon a use case • Remember it is impractical to represent every individual who may interact

with the system • Actors may represent groups of similar system usage

8

8

5

Representing an Actor

9

9

Representing a Use-Case • An oval with a title that reflects something that a user wants in its centre

Create Report

10

10

6

Multiple Actors

Create Report

11

11

«include» and «extend» Relationships • <<extend>>

– Shows an extension point in use case diagrams • <<include>>

– Shows a dependency in use case diagrams

12

12

7

User Goal Level

• Scenarios have been advocated as an effective means of acquiring and validating requirements as they capture examples and real world experiences that users can understand.

Source: Inquiry-based Requirements Analysis, Potts (1994)

13

Use Case Level

• Cockburn distinguishes three main levels of use cases, being Summary, User Goal and Sub-function. Furthermore he uses a sailboat analogy with corresponding symbols. Summary use cases are at cloud or kite level, User Goal use cases at sea level and Sub-function use cases are under water at a fish or clam level.

14

8

Granularity

Source: Writting Effective Use Cases (2001) Cockburn

• Cloud - Very high level, involve multiple user goals, e.g. "Operate a Bio-specimen Repository"

• Kite - High level, a process that takes place over several hours, days or weeks involving many steps "Find Usable Samples"

• Sea - User Goal, something the actor is trying to get done - "one person, one sitting", involves several underwater or clam level

• Underwater - Needed to accomplish user goals, typically can be used and reused - "Save as a File"

• Clam - Not usually written out in detail as a use case, "insert record into database"

15

User Goal Level

• A User Goal use case addresses the question: “Can the primary actor go away happily after the use case finished?”

• Examples of User Goal use cases might be: “Buy Book” or “Register Customer”.

• In contrast, the use cases: “Complete Online Purchase Order” or “Log On” do not generally count as user goals. The first one does not because it may take days to complete an online purchase order and the second one does not because logging on will not be user goal as such.

16

9

Summary Level

• A Summary use case outlines the context of a set of User Goal use cases.

• The Summary use case may have a step in its scenario for each User Goal use case.

• The time frame of a summary use cases is typically in terms of hours, days, weeks or more.

• Note that identifying Summary use cases can be a valuable aid while determining the high-level requirements, but will not provide the functional requirements.

• The already mentioned “Complete Online Purchase Order” could be a use case at the kite level. “Run Web Book Store” could be a use case at the even higher cloud level.

17

Sub-function Level

• A Sub-function use case is created to move out an isolated part of a scenario to a separate use case.

• In most cases this is done to keep the original use case readable or because that particular part of the scenario can be reused and serve as building blocks for other use cases.

• A common example of a Sub-function use case at the fish level is “Log on”.

• Sub-function use cases at the even lower clam level could be “Record Log On Attempt” and “Revoke Access”.

18

10

Sub-function Level During Scenario Analysis

• Use cases at the Sub-function level are generally too detailed to be created during scenario analysis because they are seldom visible to the actors. But during design clam level use cases may be created to work out some processing algorithm.

19

Scenarios: Flows

• Normal Flows include only those steps that normally are executed in a use case

• Alternate / Sub-Flows the normal flow of events decomposed to keep the normal flow of events as simple as possible

• Exceptional Flows flows that do happen but are not considered to be the norm

20

11

Scenarios in Requirements Discovery

• Robertson presents a simple method using scenarios to discover requirements in her chapter in the book Scenarios, Stories, Use Cases edited by Alexander and Maiden, Wiley, 2004.

• Strong relationship with interviews. • She presents 4 types of scenario:

– Normal Case Scenario – Alternative Case Scenario – Exception Case Scenario – What-If Scenario

21

21

Example: Online Book Store

Create a Use-Case Diagram highlighting the following three levels for use- cases: – Summary Use Cases – User Goal Uses Cases – Sub-function Use Cases

The use cases: – Run Web Store Book – Complete Online

Purchase Order – Invoice Customer – Register – Buy Book – Maintain Profile – Log on

22

12

Solution

Source: Patterns for Effective Use Cases (2002) Adolph et al.

23

How is use case diagramming related to functional modeling?

• The purpose of use-case models is to provide a description of the problem domain.

• The use case descriptions (scenarios) and diagrams provide a formal definition of the external behavior or functionality of the business processes.

• Note that use-cases provide only a logical view of the system. In the design phase a physical view of the internals of the new system are modeled.

Source: Inquiry-based Requirements Analysis, Potts (1994)

24

13

Associations

• Every association must be connected to at least one use case and one actor.

• Note that this is the definition of an association, it shows two-way communication between the use case and the actor.

25

Order

• No order is implied by a use-case(s) diagram, so it is not important to sequence the various use cases.

26

14

Best Practices

• It is usually necessary to redraw the diagram several times to make the diagram easy to read.

• According to the textbook there should be no more than three to nine use cases on the model to keep it simple yet informative.

• Remember to place the use-cases to minimize crossing lines.

27

• There are no absolute criteria we can use to differentiate between good and poor quality use cases. Authors and teachers have always had a difficult time saying why the good ones were good and what was wrong with the bad ones.

• To make matters worse, each development organization has its own culture, its own people, and its own way of doing things. What works for one organization may not work for another. This disparity makes it impossible to define a “one- size-fits-all” process for creating high-quality use cases.

Source: Patterns for Effective Use Cases (2002) Adolph et al.

28

15

Misuse Cases

• Privacy and security requirements are also included as a special kind of use case, the misuse case. – A misuse case is a use case from the point of view of

an actor hostile to the system; – the actor is a hacker deliberately threatening the

security of the system and/or the privacy of the users of the.

• A black ellipse is used to denote a misuse.

29

Misuse Cases

Source: (Williams, 2004)

30

16

Scenarios in Requirements Discovery

• Robertson presents a simple method using scenarios to discover requirements in her chapter in the book Scenarios, Stories, Use Cases edited by Alexander and Maiden, Wiley, 2004.

• Strong relationship with interviews. • She presents 4 types of scenario:

– Normal Case Scenario – Alternative Case Scenario – Exception Case Scenario – What-If Scenario

31

31

Normal Case Scenario

• Robertson presents a simple method using scenarios to discover requirements in her chapter in the book Scenarios, Stories, Use Cases edited by Alexander and Maiden, Wiley, 2004.

• Strong relationship with interviews. • She presents 4 types of scenario:

– Alternative Case Scenario – Exception Case Scenario – What-If Scenario

32

32

17

Alternative Case Scenario

• A legitimate alternative choice that significantly alters the Normal Case

• Question each step of the Normal Case: – Does this step always happen precisely as stated? – Do we know the precise meaning of each noun? – Do we know the precise meaning of each verb? – Is there any missing data? – Are there any subjective judgments? – Am I making any assumptions? – Does this make sense to me?

33

33

Exception Case Scenario

• An error or unwanted processing condition that substantially alters the Normal Case.

• Question each step of the Normal Case: – What data conditions could make the step unable to

proceed? – What historical conditions could make the step unable

to proceed? – What human behavior could make the step unable to

proceed?

34

34

18

What-If Scenario

• Try some creative thinking within the bounds of technical possibility

35

35

What’s Next

• How do we get from Scenarios to Functional Requirements?

36

36

19

Requirements

37

Requirements

38

20

Use Case-based Requirements According to Williams

1. Overview of the System we Wish to Develop 2. Section on Use Cases

1. Use Cases Diagram 2. List of Use Case Scenarios

3. Section on Misuse Cases 4. Section on Nonfunctional Requirements

39