Scribd
Upload
22 views

8.b Structuring System Process Requirements

The document discusses structuring system process requirements using use case modeling. It defines functional and non-functional requirements, and what a use case is - a sequence of user interactions with a system. Use cases can be described textually or diagrammatically. A use case diagram shows relationships between actors and use cases, and can be used to provide an overview of system requirements. The document outlines how to identify actors, use cases, and relationships between them using include and extend notations. It provides examples and rules for effectively modeling system requirements through use case diagrams.

Uploaded by

mleighraven
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
22 views

8.b Structuring System Process Requirements

The document discusses structuring system process requirements using use case modeling. It defines functional and non-functional requirements, and what a use case is - a sequence of user interactions with a system. Use cases can be described textually or diagrammatically. A use case diagram shows relationships between actors and use cases, and can be used to provide an overview of system requirements. The document outlines how to identify actors, use cases, and relationships between them using include and extend notations. It provides examples and rules for effectively modeling system requirements through use case diagrams.

Uploaded by

mleighraven
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

STRUCTURING

SYSTEM PROCESS
REQUIREMENTS

Use Case
Modeling
COMSCI 2201
Functional vs. Non-functional
Functional

Requirements
Non-Functional

• Functional requirement are user ‘visible’ features and are


typically initiated by stakeholders of the system – generate
report, login, etc.
• Non-functional requirements are ‘non-visible’ features, but
required for effective running of an application – security,
backup, etc.
What is a Use Case?

• A requirements analysis concept.


• A case of a use of the system/product.
• Tells a story:
– A sequence of events involving interactions of
user with the system
• Specifies one aspect of the behavior of a system,
without specifying the structure of the system.
Ways of Describing Use Cases
1. Text Description 2. Diagram Description
Use Case Diagram
• It is a simple way of presenting an overview of a system’s
requirements.
• A diagram that shows the relationships among actors and
use cases within a system.
• It is often used to:
– Provide an overview of all part of the usage requirements for
a system or organization in the form of an essential model or a
business model.
– Communicate the scope of a development project.
– Model your analysis of your usage requirements in the form of
a system use case model.
Use Case Model
• It is comprised of one or more use case diagrams
and any supporting documentation such as use
case specifications and actor definitions.
• It should be developed from the point of view of
your project stakeholders and not from the (often
technical) point of view of developers.
NOTATIONS
A description of a set of sequences of actions,
use case
including variants, that system performs that
yields an observable value to an actor.

The people or systems that provide or receive


actor
information from the system; they are among
the stakeholders of a system.

connection Connection between actor and use case

Specifies that the source use case explicitly


include <<include>>
incorporates the behavior of another use case
at a location specified by the source

extend Specifies that the target use case extends the <<extend>>
behavior of the source.
Actors

• A person, organization, or external system that plays


a role in one or more interactions with your system.
• Actor must be a beneficiary of the use case.
• Typically drawn as stick figures.
• In naming actors, choose names that describe the
role, not generic names, such as "user" or "client".
Actors (cont…)
Divided into two groups:

• Primary actors:
– Supply data or receive information from the system.
– Provide details on what the use case should do.
• Supporting actors:
– Help to keep the system running or provide help.
– The people who run the help desk, the analysts,
programmers, and so on.
Actors (cont…)

• Could be human beings, other systems,


timers and clocks or hardware devices.

• Actors that stimulate the system and are the


initiators of events are called primary actors
(active)
• Actors that only receive stimuli from the system
are called secondary/supporting actors (passive)
Actors (cont…)

Who/what will be interested in the


system?
Who/what will want to change the
Actors data in the system?
Who/what will want to interact with the
system?
Who/what will want the information
from the system?
Rules for Actors
1. Place your Primary Actor(s) in the top-left corner of the
diagram
2. Draw Actors to the outside of a use case diagram
3. Name Actors with singular, business-relevant nouns
4. Associate each Actor with one or more use cases
5. Actors model roles, not positions
6. Use <<system>> to indicate System Actors
7. Actors don’t interact with one another.
Use Case
Do
something

• It describes a sequence of actions that provide a


measurable value to an actor.
• System function (process – automated or manual).
• Each actor must be linked to a use case, while some
use cases may not be linked to actors.
• It is drawn as a horizontal ellipse.
For identifying use cases, Jacobson et al.
(1992) recommend that you ask the
following questions:
• What are the main tasks performed by each actor?
• Will the actor read or update any information in the
system?
• Will the actor have to inform the system about
changes outside the system?
• Does the actor have to be informed of unexpected
changes?
Use Case (Examples)
USER/ACTOR USER GOAL = USE CASE

• Look up item availability


Order Clerk • Create new order
• Update order
• Record order fulfillment
Shipping Clerk • Record back order

Merchandising • Create special promotion


Manager • Produce catalog activity report
Rules for Use Cases
1. Use Case names begin with a strong Verb
2. Name Use Cases using domain terminology
3. Place your Primary Use Cases in the top-left corner
of the diagram
4. Imply timing considerations by stacking Use Cases.
Use Case (Examples)
<<extend>> vs. <<include>>

• Extend relationship
– Used to indicate that a use case can be extended by another
use case under certain conditions.
– It is used when a use case adds some optional or alternative
behavior to another use case.
– It is shown as a dotted-line arrow pointing toward the use case
that has been extended and labeled with the <<extend>>
symbol.
<<extend>> example
Browse items

Add to cart

Checkout

CUSTOMER Apply
discount
<<extend>> vs. <<include>>
• Include relationship
– Used to indicate that a use case includes the functionality of
another use case.
– The included use case cannot stand alone and the original
use case is not complete without the included one.
– It is denoted by a solid arrow with a closed arrowhead
pointing from the including use case to the included use
case.
– The included use case represents a common set of actions
or sub-processes that are required by multiple use cases.
<<include>> example
Deposit

<<include>>
Withdraw Authenticate

Transfer

CUSTOMER
Rules for Relationships
1. Indicate an association between an actor and a use case if
the actor appears within the use case logic;
2. Avoid arrowheads on actor-use case relationships (if
necessary);
3. Apply <<include>> when you know exactly when to invoke
the use case;
4. Apply <<extend>> when a use case may be invoked across
several use case steps;
5. Generalize use cases when a single condition results in
significantly new business logic;
6. Avoid more than two levels of use case associations.
System Boundaries Boxes
• Used to define the scope of the system being modeled.
• The box represents the boundary between the system and its
external environment, which can include users, other
systems, or physical devices.
• It indicates the scope of your system – the use cases inside
the rectangle represent the functionality that you intend to
implement.
Use Case Diagram
– Guidelines & Caution
1. Use cases should ideally begin with a verb – i.e Generate
report.
2. Use cases should NOT be open ended – i.e Register (instead
should be named as Register New User)
3. Avoid showing communication between actors.
4. Actors should be named as singular. i.e Student and NOT
Students. NO names should be used – i.e John, Sam, etc.
5. Do NOT show behavior in a use case diagram; instead,
depict only system functionality.
6. Use case diagram does not show sequence – unlike DFDs.
More example…

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.

Identify the top-level functional requirement for the clock, and model it
with a use case diagram.
Solution
End.

You might also like