1 @NGUYỄN Thị Thu Trang, [email protected].

vn 2

No Single Model Is Sufficient

• No single model is sufficient. Every non-trivial system
is best approached through a small set of nearly
ITSS SOFTWARE DEVELOPMENT independent models.
• Create models that can be built and studied separately, but are
2. REQUIREMENT MODELING WITH UC still interrelated.

Nguyen Thi Thu Trang

Logical View Implementation View
[email protected] Analysts/Designers Programmers
Structure Software management
Use-Case View
End-user
Functionality

Process View Deployment View

System engineering
System integrators System topology, delivery,
Performance, scalability, throughput installation, communication
Some slides extracted from IBM coursewares

1 2

Content Review: Software Requirements Analysis process

• Purpose: “to establish the requirements of the software

1. Requirements elements of the system”
2. Use case diagram • Main items written on the brief requirement description
• System environmental conditions under which the software is to
3. Use case specification/scenario perform.
• The functional requirements and the interface requirements.
4. Glossary • Data definition and database requirements.
• Some non-functional requirement items such as reliability,
5. Supplementary Specification usability, time efficiency
• Qualification requirements: The requirements are used as criteria
or conditions to qualify a software product as complying with its
specifications.

3 4

1
5 6

Purpose of Requirement Relevant Requirements Artifacts

• Establish and maintain agreement with the customers and Use-Case Model
other stakeholders on what the system should do.
• Give system developers a better understanding of the
requirements of the system.
Glossary
• Delimit the system.
Actors
• Provide a basis for planning the technical contents of the Use Cases
iterations.
• Provide a basis for estimating cost and time to develop
the system.
• Define a user interface of the system. ...
Supplementary
Specification
Use-Case Specifications

5 6

Content 2.1. Overview of Use-Case Diagram

• A diagram modeling the dynamic aspects of
1. Requirements systems that describes a software’s functional
2. Use case diagram requirements in terms of use cases.
• A model of the software’s intended functions
3. Use case specification/scenario (use cases) and its environment (actors)
4. Glossary View Report Card

5. Supplementary Specification
Register for Courses

Student
Login
7

7 8

2
9 10

Benefits of a Use-Case Model Major Concepts in Use-Case Modeling

• Communication • An actor represents anything that
Use Case
• Identification interacts with the software.
• Verification

Identification
Communication Verification
Actor
• A use case describes a sequence
of events, performed by the
software, that yields an observable
result of value to a particular actor. Use Case
End User Domain Expert Users

9 10

11

2.2. Actors Actors and Roles

• Actors represent roles a user of the system
can play
• They can represent a human, a machine, or
another system Charlie: Is employed as a math professor Jodie: Is a science
• They can be a peripheral device or even and is an economics undergraduate. undergraduate.
database
• They can actively interchange information
with the system Charlie and Jodie both act as Register for
• They can be a giver of information a Student. courses
• They can be a passive recipient of information Actor Student
• Actors are not part of the system
• Actors are EXTERNAL Charlie also acts as a Submit grades
Professor. Professor

11 12

3
13 14

Some guideline to extract actors Put some questions to find actors

• Pay attention to a noun in the problem • Who or what uses the system?
description, and then extract a subject of action • Who or what gets information from this system?
as a Actor. • Who or what provides information to the system?
• Ensure that there are no any excesses and
• Where in the company is the system used?
deficiencies between the problem description and
• Who or what supports and maintains the system?
Actors extracted.
• What other systems use this system?
• Actor names
• should clearly convey the actor’s role
• good actor names describe their responsibilities

13 14

@Nguyễn Thị Thu Trang, [email protected] 15 16

Internet banking system Find actors in the Internet banking system

• The internet banking system, allowing interbank network,
Internet Banking System
communicates with bank customers via a web application. To
perform transactions, customers have to log in the software.
Customers may change password or view personal
information.
• Customers can select any of transaction types: transfer
(internal and in interbank network), balance inquiries,
transaction history inquiries, electric receipt payment (via EVN
software), online saving.
• In the transfer transaction, after receiving enough information
from the customer, the software asks the bank consortium to
process the request. The bank consortium forwards the request
to the appropriate bank. The bank then processes and
responses to the bank consortium which in turn notifies the
result to the software.
• The bank officers may create new account for a customer,
reset password, view transaction history of a customer.

15 16

4
17 18

Some guidelines to extract use cases

2.3. Use Cases
• Pay attention to a verb in the problem description,
• Define a set of use-case instances, where each and then extract a series of Actions as a UC.
instance is a sequence of actions a system • Ensure that there are no any excesses and
performs that yields an observable result of value deficiencies between the problem description and
to a particular actor. Use cases extracted.
• A use case models a dialogue between one or more
• Check the consistency between Use Cases and
actors and the system
• A use case describes the actions the system takes to
related Actors.
deliver something of value to the actor • Conduct a survey to learn whether customers,
business representatives, analysts, and
Use Case developers all understand the names and
descriptions of the use cases

17 18

19 20

Use case name Put some questions to find use cases

• Be unique, intuitive, and self-explanatory • What are the goals of each actor?
• Define clearly and unambiguously the observable • Why does the actor want to use the system?
result of value gained from the use case • Will the actor create, store, change, remove, or
• Be from the perspective of the actor that triggers read data in the system? If so, why?
the use case • Will the actor need to inform the system about
• Describe the behavior that the use case supports external events or changes?
• Start with a verb and use a simple verb-noun • Will the actor need to be informed about certain
combination occurrences in the system?

19 20

5
21 22

Find use cases in the Internet Banking

system 2.4. Relationships
Internet Banking System • Not recommended to use many times
• Three kinds
• Between actors: generalization, association
• Between actor and use cases: association
• Between use cases: generalization, include, extend

21 22

23 24

2.4.1. Between actors 2.4.1. Between actors (2)

• Generalization • Association
• The child actor inherits • Consider the difference between two diagrams
parent’s characteristics and
behaviors. Customer

Register for Courses

Student

Commercial Register for Courses

Customer
Student Registrar

23 24

6
25

Communicates-Association
2.4.2. Between actor and use case
• Establish the actors that interact with related use cases à Use • A channel of communication between an
actor and a use case.
associations
• Associations clarify the communication between the actor and use case. Actor 1 • A line is used to represent a
• Association indicate that the actor and the use case instance of the communicates-association.
system communicate with one another, each one able to send and • An arrowhead indicates who initiates each
receive messages. Use Case interaction.
• The arrow head is optional but it’s commonly used to denote • No arrowhead indicates either end can initiate
each interaction.
the initiator.

Use Case Actor 2 Actor 3

Association

Actor

25 26

27

Arrowhead Conventions
2.4.3. Between use cases
Passive sensor • Generalization <<extend>>

Monitor Place order Place rush order

• parent use case
for alarms
Supervisor Active sensor • <<include>> <<include>>

• always use
Hybrid sensor Pay order
• <<extend>>
• sometimes use Check password

Passive sensor
Validate user
Monitor
for alarms
Supervisor Active sensor
Retinal scan

Hybrid sensor 28

27 28

7
29 30

Between use cases - Generalization Between use cases - Include

• The child use case inherits the behavior and • The base use case Place order
meaning of the parent use case; explicitly incorporates
• the child may add to or override the behavior of its the behavior of another
<<include>>
parent; use case at a location
• the child may be substituted any place the parent specified in the base.
appears (both the parent and the child may have
• The included use case Pay order
concrete instances)
Check password
never stands alone, but
is only instantiated as
Validate user part of some larger base
that includes it
Retinal scan

29 30

31 32

Between use cases - Extend 2.5. Use case diagram

• The base use case implicitly incorporates the • The Use case diagram shows a set of use cases and
behavior of another use case at a location actors and their relationships.
specified indirectly by the extending use case. • The Use case diagram serves as a contract between the
customer and the developers.
• The base use case may stand alone, but under
• Because it is a very powerful planning instrument, the Use
certain conditions its behavior may be extended case diagram is generally used in all phases of the
by the behavior of another use case. development cycle

<<extend>>
Place order Place rush order

31 32

8
33

Notes Content
• Should notuse two many relationships between 1. Requirements
use case in the Use case diagram
• Tangle and make the diagram difficult to observe 2. Use case diagram
• Only use the relationship if necessary 3. Use case specification/scenario
• In the Use case diagram, the sequence do use cases
are not specified 4. Glossary
5. Supplementary Specification

34

33 34

35 36

Use-Case Specification
The System Use-Case Specification
Use-Case Model
Use case 1 • Code
Use-Case-Model Survey Actor 1
- survey description • Name
Actor 2
- list of all actors Use case 2
• Brief description
- list of all use cases Actors
• Flow of Events
Use case 3
• Relationships Use Cases

Actor 3
• Activity diagrams
• Use-Case diagrams
• Special requirements
...
Use-Case 1 Spec • Pre-conditions
Use-Case 2 Spec Use-Case 3 Spec
- brief description - brief description - brief description • Post-conditions Use-Case Specifications
- flow of events - flow of events - flow of events • Other diagrams

35 36

9
37 38

Some guidelines to make UC specification Brief description of UC

• UC Scenario description for each UC: • Describe briefly the purpose of UC
• External Interface
• Permanent data • Example: Use case “Log in” in the ATM system:
• Excess and deficiency check between between
the problem description and Requirements “This use case describes the interaction between bank
customers and the ATM machine when the customer
• Consistency in the Requirements
wishes to log in to the system to perform transactions”
• Feasibility of later phase

37 38

39 40

Use-Case Flow of Events

What Is a Scenario?
w Has one normal, basic flow
• A scenario is an instance of a use case.
w Several alternative flows
§ Regular variants
§ Odd cases
§ Exceptional flows for handling error situations

39 40

10
41 42

Flow of events
UC Login in the ATM system Success / Main flow of event
# Doer Action
• Main flows of events: The use case starts when system 1 Customer requests to log in
prompts the Customer for a PIN Number. The Customer can 2 software prompts a Log in screen
now enter a PIN number. The Customer commits the entry. The 3 Customer enters a PIN number
system then checks this PIN number to see if it is valid. If valid, 4 Customer submit to login
the system acknowledges the entry, thus ending the use case 5 software checks if the PIN number is valid
• Regular variants: The Customer cancel a transaction at any 6 software displays the main menu if the PIN number is valid
time, thus restart the UC. No changes are made to the
Customer’s account. Alternative flow of event
• Odd case: The Customer clear a PIN number anytime before # Doer Action
committing it and re-enter a new PIN number Customer cancels a transation at any time
• Exceptional flow of events: If the Customer enter an invalid PIN 4a Customer clears PIN number before submitting
number, the UC restarts. If this happens 3 times in a row, the 6a software notifies Invalid PIN number, goes to Step 2 if the PIN
system cancel the entire transaction, and keep the ATM card. number is not valid less than 3 times
6b software notifies invalid PIN number 3 times, keep the ATM card if the
PIN number is not valid 3 times

41 42

@Nguyễn Thị Thu Trang, [email protected] 43 @Nguyễn Thị Thu Trang, [email protected] 44

Detail of Alternative Flows

Alternative Flows Describe what
How to do use case specification for:
happens
2.8 Unidentified Student. • Included use cases
In the Log On step of the Basic Flow, if the system
determines that the student identification information is
Location • Explicitly call the included use case in a step
not valid, an error message is displayed, and the use (i.e. the inclusion point) in the basic flow of
case ends. Condition the base use case
2.9 Quit and Save.
At any time, the system will allow the Student to quit. The • Extended use cases
student chooses to quit and save a partial schedule • Insert extension use case’s behavior into base
before quitting. The system saves the schedule, and the Actions
use case ends.
use case at the extension point if the
2.10 Waiting List extending condition is true
In the Select Courses step of the Basic Flow, if a course Resume location • Generalized use cases
the Student wants to take is full, the systems allows the
student to be added to a waiting list for the course. The • Use placeholders in parent use cases
use case resumes at the Select Courses step in the Basic
Flow.

43 44

11
@Nguyễn Thị Thu Trang, [email protected] 45 @Nguyễn Thị Thu Trang, [email protected] 46

E.g. Include use case in specification E.g. Extend use case in specification
Base
Use-Case Base
• Use case “Place order” Use Case
Instance Use Case
Basic flow Use-Case • Use case “Place order”
1. … Instance Extension
Basic flow Point
2. … 1.… Extension
3. Passenger confirm to buy tickets 2.Customer enters and submits shipping info Use Case
4. Software calls the use case “Pay receipt” 3.Software displays receipt
Included 4.…
5. Software calls the use case “Print receipt” Use Case
Alternative flow
6. …
A1. In the step 2, if customer chooses to place a rush
• Use case “Pay receipt” order, insert use case “Place rush order”, then resume at
the step 3.
Basic flow
…
1. Software asks passenger to insert a credit card
• Use case “Place rush order”
2. Passenger inserts a credit card to the credit card slot 1. Software displays rush order form
3. … 2. Customer
3. …

45 46

@Nguyễn Thị Thu Trang, [email protected] 47 @Nguyễn Thị Thu Trang, [email protected] 48

How do you handle repetitive behavior? How do you handle repetitive behavior? (cont.)
Basic Flow
1. Log On. Register for Courses
…
Register for Courses 2. Create Schedule.
1.2. The system displays the functions available to the student. These
functions are Create A Schedule, Modify a Schedule and Delete a Schedule.
The student selects ‘Create a Schedule’.
3. Perform Subflow Select Courses
Repetitive flow of 4. Submit Schedule
Simple, repetitive events can be …
Alternative Flows
behavior can be captured using a 1. Modify Schedule.
captured within subflow. 1.1 In the Create Schedule step of the Basic Flow, if the student already has a
schedule that has been saved; the system retrieves and displays the Student’s
the basic flow. current schedule (e.g., the schedule for the current semester) and allows
him/her to use it as a starting point.
1.2 Perform Subflow Select Courses.
1.3 The use case resumes at the Submit Schedule step of the Basic Flow.
…
Subflows
1. Select Courses.
1.1 The system retrieves a list of available course offerings from the Course
Catalog System and displays the list to the student.
1.2 The Student selects up to 4 primary course offerings and 2 alternative
course offerings from the list of available offerings.
1.3 The student can add and delete courses as desired until choosing to submit
the schedule.

47 48

12
@Nguyễn Thị Thu Trang, [email protected] 49 @Nguyễn Thị Thu Trang, [email protected] 50

Example subflow Visualize behavior

• Visual modeling tools
• Activity diagrams or flow charts
• Business process models
• Should you illustrate behavior?
• Pro
• Great tool to identify alternative flows, especially for
visually oriented people
• Succinctly conveys information about use case flows
• Con
• Costly to keep diagrams and use-case specifications
synchronized

49 50

52

What Is an Activity Diagram?

Example: Activity Diagram
uAn activity diagram in the Use-Case Model can be used to
capture the activities in a use case.
Decision
uIt is essentially a flow chart, showing flow of control from Select Course Activity/Action
Concurrent
one activity or action to another. Threads [ delete course ]
Delete Course
[ add course ]
Flow of Events
Synchronization
This use case starts when the Registrar requests that the Bar (Fork)
system close registration. Check Check
Guard Schedule Pre-requisites
1. The system checks to see if registration is in progress. Activity2 Condition
If it is, then a message is displayed to the Registrar and
Synchronization
the use case terminates. The Close Registration
processing cannot be performed if registration is in [ checks completed ] [ checks failed ] Bar (Join)
progress. Activity1 Activity3
2. For each course offering, the system checks if a Assign to Resolve
Course Conflicts Transition
professor has signed up to teach the course offering and
at least three students have registered. If so, the system
commits the course offering for each schedule that Update
contains it. Schedule

51 52

13
53 @Nguyễn Thị Thu Trang, [email protected] 54

Partitions Preconditions
u Each partition should Sales Fulfillment • Describe the state that the system must be in before the use case can
start
represent a responsibility • Simple statements that define the state of the system, expressed as
Determine
for part of the overall Need conditions that must be true
• Should never refer to other use cases that need to be performed prior to
workflow, carried by a part this use case
of the organization.
Take Order
• Should be stated clearly and should be easily verifiable
• Optional: Use only if needed for clarification
u A partition may eventually • Example
be implemented by an Setup Payment
Fill Order Register for Courses use case

organization unit or a set of Precondition:

• The list of course offerings for the semester
classes in the business has been created and is available to the
object model. Deliver Order
Course Registration System
• The registration is open for student
• Student has logged into the Course Registration System

53 54

@Nguyễn Thị Thu Trang, [email protected] 55 @Nguyễn Thị Thu Trang, [email protected] 56

Sequence use cases with pre- and

Postconditions postconditions
• Describe the state of the system at the end of the use
case Use case 1 Use case 2
• Use when the system state is a precondition to another use case,
or when the possible use case outcomes are not obvious to use
case readers
• Should never refer to other, subsequent use cases
• Should be stated clearly and should be easily verifiable
• Optional: Use only if needed for clarification
• Example:
Register for Courses use case
Postcondition: At the end of this
use case either the student has been Use cases do not interact with each other.
enrolled in courses, or registering was However, a postcondition for one use case
unsuccessful and no changes have been made to the student can be the same as the precondition for another.
schedules or course enrollments

55 56

14
@Nguyễn Thị Thu Trang, [email protected] 57

Other use case properties Content

• Special requirements
• Related to this use case, not covered in flow of events
1. Requirements
• Usually nonfunctional requirements, data, and business rules

• Extension points
2. Use case diagram
• Name a set of places in the flow of events where extending behavior 3. Use case specification/scenario
can be inserted
• Additional information 4. Glossary
• Any additional information required to clarify the use case
5. Supplementary Specification

58

57 58

59 60

4. Glossary 4. Glossary (2)

• The Glossary defines important terms used in • Introduction: Provides a brief description of the
the project for all models. Glossary and its purpose.
• There is only one Glossary for the system. • Terms: Define the term in as much detail as
• This document is important to many developers, necessary to completely and unambiguously
especially when they need to understand and use characterize it.
the terms that are specific to the project.
• The Glossary is used to facilitate
communications between domain experts and
developers

59 60

15
61 62

4. Glossary (3) Case Study: Glossary

Course Registration System Glossary
1. Introduction • Make the Glossary of the Course
This document is used to define terminology specific to the problem domain,
explaining terms, which may be unfamiliar to the reader of the use-case
Registration System
descriptions or other project documents. Often, this document can be used as
an informal data dictionary, capturing data definitions so that use-case
descriptions and other project documents can focus on what the system must do
with the information.

2. Definitions
The glossary contains the working definitions for the key concepts in the
Course Registration System.
Glossary
Glossary 2.1 Course: A class offered by the university.
2.2 Course Offering: A specific delivery of the course for a specific
semester – you could run the same course in parallel sessions in the semester.
Includes the days of the week and times it is offered.
2.3 Course Catalog: The unabridged catalog of all courses offered by the
university.

61 62

63 64

Content 5. Supplementary Specification

• Includes the nonfunctional requirements and
1. Requirements functional requirements not captured by the
2. Use case diagram use cases
• Contains those requirements that do not map
3. Use case specification/scenario to a specific use case: Functionality, Usability,
Reliability, Performance, Supportability
4. Glossary
Supplementary
5. Supplementary Specification Specification

63 64

16
65 66

5. Supplementary Specification (2) 5. Supplementary Specification (3)

• Functionality: List of the functional requirements that • Reliability: Any requirements concerning the
are general to many use cases. reliability of the system. Quantitative measures such
• Usability: Requirements that relate to, or affect, the as mean time between failure or defects per thousand
usability of the system. Examples include ease-of-use lines of code should be stated.
requirements or training requirements that specify • Performance: The performance characteristics of the
how readily the system can be used by its actors. system. Include specific response times. Reference
related use cases by name.
• Supportability: Any requirements that will enhance
the supportability or maintainability of the system
being built.

65 66

67

Checkpoints: Actors
Case study: Supplementary Specification
• Have all the actors been identified?
• Make the Supplementary Course
Registration • Is each actor involved with at least
Specification for the Course
Registration System
Requirements one use case?
Document
• Is each actor really a role? Should
any be merged or split?
• Do two actors play the same role in
relation to a use case?
• Do the actors have intuitive and
descriptive names? Can both users
and customers understand the
names?
Supplementary
Specification

67 68

17
Checkpoints: Use-Cases Checkpoints: Use-Case Model
• Is the Use-Case Model
• Is each use case involved with at least understandable?
one actor? • By studying the Use-Case Model,
• Is each use case independent of the can you form a clear idea of the ...

others? system's functions and how they are

• Do any use cases have very similar related?
behaviors or flows of events? • Have all functional requirements
• Do the use cases have unique, intuitive, been met?
and explanatory names so that they • Does the Use-Case Model contain
cannot be mixed up at a later stage? any superfluous behavior?
• Do customers and users alike understand • Is the division of the model into use-
the names and descriptions of the use case packages appropriate?
cases?

69 70

72

Checkpoints: Use-Case Specifications

Checkpoints: Glossary
• Is it clear who wants to perform a use case?
• Is the purpose of the use case also clear? • Does each term have a clear and
• Does the brief description give a true picture concise definition?
of the use case? • Is each glossary term included
• Is it clear how and when the use case's flow somewhere in the use-case
of events starts and ends? descriptions?
• Are the actor interactions and exchanged
• Are terms used consistently in
information clear?
the brief descriptions of actors
• Are any use cases overly complex?
and use cases?

71 72

18
73 74

Review Question?
• What are the main artifacts of Requirements?
• What are the Requirements artifacts used for?
• What is a Use-Case Model?
• What is an actor?
• What is a use case? List examples of use case properties.
• What is the difference between a use case and a scenario?
• What is a Supplementary Specification
and what does it include?
• What is a Glossary and what does
it include?

73 74

19