CSE4006: Software Engineering

Lab 6: Use Case

Software Engineering Lab

Except where otherwise noted, the contents of this document are Copyright 2017 Gwanggyu Choi, Youn-geun
Ahn and Scott Uk-Jin Lee All rights reserved. Any redistribution, reproduction, transmission, or storage of part
or all of the contents in any form is prohibited without author’s expressed written permission.
Prototype SRS Outline
Use Case
Use Case
• A Use Case defines a set of Use Case instances.
• A Use Case describes a feature(requirement) of the system.

Use Case instance

• Use Case instance is a sequence of actions a system performs
that yields an observable result of value to a particular actor.
• You may think Use Case instance as a small use case.

http://www.upedu.org/process/gdlines/md_uc.htm
Use Case instance
Brief format(Essential Style)
• One-paragraph summary, usually the main success scenario

Casual format
• Multiple-paragraphs summary which describe various scenarios

Fully-dressed format
• The most elaborated, all steps and variations are written in detail,
and there are supporting sections, such as preconditions and
success guarantees.

Applying UML and patterns(2nd) – Craig Larman

Fully Dressed Format
Use Case name Title of the use case. Start with verb.
Use Case ID Identifier of this use case
Goal in Context What is the goal which the primary actor want to achieve
Scope The system under design
Level User goal or sub-function level (See Goal Level Symbols)
Primary Actor Who will use the main functionality of the system?
Secondary Actor Who will maintain/administrate/keep the system?
Stakeholders and Interests List of stakeholders and key interests in the use case
Preconditions What must be true on start?
Success guarantee(post-condition) What must be true on successful completion?
Trigger What action primary actor doing to start the functionality?
Main success scenario(Basic flow) A typical, unconditional happy path scenario of success
Extensions(Alternative flows) All the other scenarios or branches, both success and failure scenarios.
Special requirements Related non-functional requirements
Technology and data variations list Technical constraint imposed by the stakeholder
Frequency of occurrence How many occurrence times of this use case?
Miscellaneous Etc.
Fully Dressed Format
Use Case name / ID
• Use case name should be start with verb (e.g., “Draw a Card”)
• You can write ID together.
• Example:
UC-05: Buy Goods
… …
… …
… …
Fully Dressed Format
Scope / Level
• Scope: What system is being considered?
• Level: How goal level is abstracted?
• Example:
UC-05: Buy Goods
… …

Scope Business; The overall purchasing mechanism as seen by the people

Level + (‘+’ means Summary Level, see here)

… …
Appropriate Goal Level
Think about

* weight: 무게를 재는

• Your use case should be User Goals level

• You may write initial use case to Summary Goals level,
but it should be more specified(Think ‘How’ to achieve the goal).
Fully Dressed Format
Actors / Stakeholders and interests
• Primary Actor should be user, Secondary Actors may be other
systems, files, database, etc.
• You must describe Stakeholders and Interests specifically
to protect stakeholder’s interests.
• Example:
UC-05: Buy Goods
… …

Actors Primary: Requestor Secondary: Vendor

Stakeholders and Interests Requester: wants what he/she ordered, easy way to do that.
Company: wants to control spending but allow needed purchases
Vendor: wants to get paid for any goods delivered
… …
Fully Dressed Format
Preconditions / Triggers
• Preconditions: Conditions must be true on start of the scenario.
• Trigger: Actor’s action which need to do to start the scenario.
• Example:
UC-05: Buy Goods
… …

Preconditions Requester must logged in. Status/Conditions

Trigger Requester decides to buy a goods. Action
… …
* Do not confuse them
Fully Dressed Format
Goal in Context / Success Guarantee(Post-Condition)
• Goal in Context: Primary actor want to achieve
• Success Guarantee:
Conditions must be true on the end of success scenario
• Example:
UC-05: Buy Goods
… …

Goal in Context Buyer issues request directly to our company, Wants

expects goods shipped and to be billed.
Post-Condition Buyer has goods, we have money for the goods. Result
… … * Do not confuse them
Fully Dressed Format
Main Success Scenario(Basic flow)
• Must describe one main scenario.
• Other scenarios are described in Extensions(Alternative flows)
• Example:
UC-05: Buy Goods
… …

Main Scenario 1. Requestor: initiate request

2. Approver: check money in the budget, check price of goods, complete request of submission
3. Buyer: check contents of storage, find best vendor for goods
4. Authorizer: validate Approver’s signature
5. Buyer: complete request for ordering. Initiate PO with Vendor.
6. Vendor: deliver goods to Receiving, get receipt for delivery(out of scope of SuD)
7. Receiver: register delivery, send goods to Requestor
8. Requestor: mark request delivered
… …
 Fully Dressed Format
Extensions(Alternative flows) / Exceptions
• Describe all the other scenarios for this use case.
• Including exceptions and error cases.
(You may extract failure scenarios into Exceptions)
• [Altered step number]. <Condition>: <description of alternative>

Example:

1a. Requestor does not know vendor or price: leave those parts blank and continue.
(Alternative of step 1) (Condition) (Describe action for this condition)
Fully Dressed Format
Example: UC-05: Buy Goods
Extensions 1a. Requestor does not know vendor or price: leave those parts blank and continue.
1b. At any time prior to receiving goods, Requestor can change or cancel the request.
1. Canceling it removes it from any active processing. (delete from system?)
2. Reducing price leaves it intact in process.
3. Raising price sends it back to Approver.
2a. Approver does not know vendor or price: leave blank and let Buyer fill in or call back.
2b. Approver is not Requestor's manager: still ok, as long as approver signs
2c. Approver declines: send back to Requestor for change or deletion
3a. Buyer finds goods in storage: send those up, reduce request by that amount and carry on.
3b. Buyer fills in Vendor and price, which were missing: gets resent to Approver.
4a. Authorizer declines Approver: send back to Requestor and remove from active processing.
(what does this mean exactly?)
5a. Request involves multiple Vendors: Buyer generates multiple POs.
5b. Buyer merges multiple requests: same process, but mark PO with the requests being merged.
6a. Vendor does not deliver on time: System does alert of non-delivery
7a. Partial delivery: Receiver marks partial delivery on PO and continues
7b. Partial delivery of multiple-request PO: Receiver assigns quantities to requests and continues.
8a. Goods are incorrect or improper quality: Requestor does refuse delivered goods.
(what does this mean?)
8b. Requestor has quit the company:
Buyer checks with Requestor's manager, either reassign Requestor, or return goods and cancel request.
Fully Dressed Format
Special Requirements
• Describe related non-functional requirements
• Example:
• UC-01: Process Sale (* Different example with above)
… …

Special Requirements • Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
• Credit authorization response within 30 seconds 90% of the time.
• Somehow, we want robust recovery when access to remote services such the
inventory system is failing.
• Language internationalization on the text displayed.
• Pluggable business rules to be insertable at steps 3 ~ 7
• …
… …
Fully Dressed Format
Technology and data variations list
• Varying I/O methods and data formats
• Example:
UC-01: Process Sale
… …

Technology and data variations list *a. Manager override entered by swiping an override card through a
card reader, or entering an authorization code via the keyboard.
3a. Item identifier entered by bar code laser scanner (if bar code is
present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt.
(But within two years, we predict many customer will want digital
signature capture.)
… …
Fully Dressed Format
Frequency of occurrence
• Influence investigation, testing, and timing of implementation.
• Example:
UC-01: Process Sale
… …

Frequency of occurrence Could be nearly continuous

… …
Fully Dressed Format
Miscellaneous
• Such as open issues.
• Example:
UC-01: Process Sale
… …

Miscellaneous Open Issue:

• What are the tax law variations?
• Explore the remote service recovery issue
• What customization is needed for different businesses?
• Must a cashier take their cash drawer when they log out?
• Can the customer directly use the card reader, or does the
cashier have to do it?
Fully Dressed Examples
You should see these examples
• http://alistair.cockburn.us/get/2465

• http://web.itu.edu.tr/~buzluca/ymt/ornek_uc.pdf

• https://en.wikipedia.org/wiki/Use_case#Examples

• http://pmblog.accompa.com/2009/10/08/use-case-template-example-
requirements-management-basics/

• http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/e
xamples/use_case_spec_CD5DD9B1.html
Use Case Diagram
Actor System
Boundary

Use Case
/Use Case instance

• A Use Case Diagram is a visual representation of the relationships

between actors and use cases together that documents the
system’s intended behavior.
Who is Actors?
• Who used the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
Relationship
Use Case X includes Use Case Y:
• X has a multi-step subtask Y.
• If task X is completed, then Y must be completed.
(Because, Y is subtask of X)
• Notation : X - - - - - <<include>> - - - - - > Y
Relationship
Use Case X extends Use Case Y:
• Y is a alternative options of X
• Notation : X < - - - - - <<extends>> - - - - - Y
(Be careful of direction)
Go to
Start Tile
<<extends>>

<<extends>>
Go to
Free Parking lot
Draw.io
See More
• Monopoly Example(Last page)

• http://blog.daum.net/hankylee/12
Exercise 1. Refine goal levels(TW)
1. List all functional requirements of your team project.

2. Refine(divide or gather) them to User Goals level Use Cases.

3. Select one Use Case, write brief and fully-dressed description.

4. Confirm refined use cases and descriptions to TA.

(You can’t go home before confirming)
Exercise 2. Draw UC Diagram(TW)
1. Think what system boundaries does your project have.
(In small project, it may be only one)

2. Draw Use Case Diagram for each your system boundaries.

3. You may divide use case to user goal level to sub-function level.
(Consider <<extends>>)

4. Confirm Use Case Diagram to TA.

(You can’t go home before confirming)
Exercise 3. Refine F-D Format(TW)
1. Understand Fully-Dressed Format.

2. Modify the format to apply your project.

3. Write specific reason, why each section is contained or not.

4. Upload to team GitHub repository.