The document discusses elements of an analysis model for software engineering requirements, including use case diagrams. It provides information on use cases, actors, relationships between use cases and actors, and how to describe use cases using user stories, diagrams, and textual descriptions. An example use case diagram is also included to illustrate these concepts.

1. Software Engineering
Requirement Engineering -II
Taila Jabeen

2. Building the Analysis Model
• Elements of the analysis model
 Scenario-based elements
 Use-case—descriptions of the interaction between an “actor”
and the system
• Class-based elements
 Implied by scenarios
• Behavioral elements
 State diagram
• Flow-oriented elements
 Data flow diagram
4

3. Use Case Diagram
5

4. Use Case Diagram
 A use case
diagram at its
simplest is a
representation of a
user's interaction with
the system that shows
the relationship
between the user and
the different use case
in which the user is
involved.
6

5. Use Case Diagram (Cont.)
• A requirements analysis concept
• A case of a use of the system/product
• Describes the system's actions from a the point of view of
a user
• Interactions of a user with the system
• Specifies one aspect of the behavior of a system, without
specifying the structure of the system
• They provide the simplified and graphical
representation of what the system must actually do
7

6. How do we describe use cases?
• User stories
• Diagram
• Textual or tabular descriptions
8

7. User Stories
• User stories are documented descriptions of
software features from the end-user
perspective. The document describes scenarios
of how the user engages with the solution.
• Example:
• “As a Customer, I want to select a car from the
menu so that I can complete the order. ”.
9

8. Scenario
• A Scenario is a sequence of events which happen when a user
interacts with the system
• Use case diagrams are closely connected to scenarios. A scenario is
an example of what happens when someone interacts with the
system.
• Here is a scenario for a medical clinic.
• A patient calls the clinic to make an appointment for a yearly
checkup. The receptionist finds the nearest empty time slot in the
appointment book and schedules the appointment for that time slot.
"
• We want to write a use case for this scenario.
• Remember: A use case is a summary of scenarios for a single task
or goal. 10

9. Use Case Diagram Overview
11

10. Use Case Diagram objects
Use case diagrams consist of the following objects.
• Actor
• Use case
• System boundary
• System name
• Relations
12

11. Actor
• Someone interacts with use case (system function).
• Named by noun.
• Actor plays a role in the business
• Similar to the concept of user, but a user can play
different roles
• For example:
• A prof. can be instructor and also researcher
• plays 2 roles with two systems
• Actor triggers use case(s).
• Actor has responsibility toward the system (inputs), and
Actor have expectations from the system (outputs).
13

12. Actor
• Actor in a use case diagram is any entity that
performs a role in one given system. This could
be a person, organization or an external system
and usually drawn like skeleton shown below.
• For example, a timer that triggers sending of an
e-mail reminder
14

13. Finding Actors
Ask the following questions:
• Who are the system’s primary users?
• Who requires system support for daily tasks?
• Who are the system’s secondary users?
• What hardware does the system handle?
• Which other (if any) systems interact with the system in
question?
• Do any entities interacting with the system perform
multiple roles as actors?
• Which other entities (human or otherwise) might have an
interest in the system's output? 15

14. Use Case
• System function
• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each Actor must be linked to a use case, while some use
cases may not be linked to actors.
• A use case represents a function or an action within the
system. It’s drawn as an oval and named with the function.
16

15. System boundary
• The system is used to define the scope of the use
case and drawn as a rectangle. This an optional
element but useful when you’re visualizing large
systems.
• For example, you can create all the use cases and
then use the system object to define the scope
covered by your project. Or you can even use it to
show the different areas covered in different
releases.
17

16. Relationship
• The relationships between and among the actors and the use
cases.
• Communication Link
• The participation of an actor in a use case is shown by
connecting a actor to a use case by a solid link.
• Actors may be connected to use cases by associations, indicating
that the actor and the use case communicate with one another
using messages.
18

17. Relationship
• Association Between Actor and Use Case
• This one is straightforward and present in every use case diagram.
Few things to note.
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.
• An association is a connection between an actor and a use case. An
association indicates that an actor can carry out a use case. Several
actors at one use case mean that each actor can carry out the use case
on his or her own and not that the actors carry out the use case
together:
19

18. 20

19. Linking Use Cases
• Association relationships
• Generalization relationships
• One element (child) "is based on" another element
(parent)
• Include relationships • One use case (base)
includes the functionality of another (inclusion
case) • Supports re-use of functionality
• Extend relationships • One use case
(extension) extends the behavior of another
(base)
21

20. Generalization
• The use case generalization refers to the relationship
which can exist between two use cases and which shows
that one use case (child) inherits the structure,
behavior, and relationships of another actor (parent).
• You can use the generalization relationship when you find
two or more use cases which have common behavior/logic.
• For example, there might be a use case called “Pay Bills”.
This can be generalized to “Pay by Credit Card”, “Pay by
Bank Balance” etc.
22
Pay bill
Pay by
credit
card
Pay by
bank
balance

21. Generalization Example
23

22. Include Example
24

23. Difference b/w Generalization,
Extend and Include
25

24. System Boundary (Example)
26

25. Use Case Diagram - 1
• Following are some of the information provided related to “MUS”
software.
• Download an MP3 music fi le and store it in the application’s library.
• Capture streaming music and store it in the application’s library.
• Manage the application’s library (e.g., delete songs or organize them in
• playlists).
• Burn a list of the songs in the library onto a CD.
• Load a list of the songs in the library onto an iPod or MP3 player.
• Convert a song from MP3 format to AAC format and vice versa.
27

26. Use Case Diagram - 1
• “MUS” software.
28

27. Use Case Diagram - 2
• Any Customer can look for Car Models in the catalog, either by browsing
the Car Model index or by searching. In the latter case, the Customer
specifies the Categories, Makes and engine sizes that they’re interested
in. Either way, after each retrieval, the Customer is shown the results
as a collection of matching Car Models , along with basic information
such as Car Model name. The Customer can then choose to view extra
information about particular Car Models such as a description and an
advert. Customers who have become Members can log on and gain
access to extra services. The extra services are: making a Reservation,
canceling a Reservation, checking membership details, viewing
outstanding Reservations, changing their log-on password, viewing their
outstanding Rentals and logging off. Assistants are involved in the life
cycle of Reservations, moving Cars to and from the reserved area, for
example.
29

28. Use Case Diagram - 2
• Any Customer can look for CarModels in the catalog, either by browsing
the CarModel index (U1) or by searching (U4). In the latter case, the
Customer specifies the Categories, Makes and engine sizes that they’re
interested in. Either way, after each retrieval, the Customer is shown
the results as a collection of matching CarModels (U2), along with basic
information such as CarModel name. The Customer can then choose to
view extra information about particular CarModels such as a description
and an advert (U3). Customers who have become Members can log on
(U5) and gain access to extra services. The extra services are: making a
Reservation (U7), canceling a Reservation (U11), checking membership
details (U6), viewing outstanding Reservations (U10), changing their
log-on password (U9), viewing their outstanding Rentals (U8) and
logging off (U12). Assistants are involved in the life cycle of
Reservations, moving Cars to and from the reserved area, for example.
30

29. 31

30. 32

31. Scenario-1
• Suppose we want to develop software for an alarm
clock. The clock shows the time of day. Using
buttons, the user can set the hours and minutes
fields individually, and choose between 12 and 24-
hour display. It is possible to set one or two alarms.
When an alarm fires, it will sound some noise. The
user can turn it off, or choose to ’snooze’. If the user
does not respond at all, the alarm will turn off
itself after 2 minutes. ’Snoozing’ means to turn off
the sound, but the alarm will fire again after some
minutes of delay. This ’snoozing time’ is pre-
adjustable.
33

32. Solution
34

33. Scenario-2
• Let’s imagine we will develop a browser-based training
system to help people prepare for a certification exam. E.g
digiskills
• A user can request a quiz for the system. The system picks
a set of questions from its database, and compose them
together to make a quiz. It rates the user’s answers, and
gives hints if the user requests it. In addition to users, we
also have tutors who provide questions for the quiz. And also
examinators who must certify questions to make sure the
complexity of the questions.
• Make a use case diagram to model this system.
35

34. Solution
36

35. Scenario
41
• Many important administrative activities of a university are processed
by the student office. Students can register for studies (matriculation),
enroll, and withdraw from studies here. Matriculation involves enrolling,
that is, registering for studies.
• Students receive their certificates from the student office. The
certificates are printed out by an employee. Lecturers send grading
information to the student office. The notification system then informs
the students automatically that a certificate has been issued.
• There is a differentiation between two types of employees in the student
office: a) those that are exclusively occupied with the administration of
student data (service employee, or ServEmp), and b) those that fulfill the
remaining tasks (administration employee, or AdminEmp), whereas all
employees (ServEmp and AdminEmp) can issue information.
• Administration employees issue certificates when the students come to
collect them. Administration employees also create courses. When
creating courses, they can reserve lecture halls.

36. 42

37. Use case description for “Print certificate”
43