Software Construction

Lecture 4
Inception Phase
Understanding Requirements
Use Case Modeling

1
 Inception Phase
 Inception is initial short step to establish a common vision
and basic scope for the project
 Don’t try to discover all requirements during Inception
(that’s waterfall mentality)
 Major Inception questions
 Why should we do this?
 Is it feasible?
 Should we buy or build?
 What is the cost?
 Should we proceed or stop?
Inception Phase
 Important artifacts
 Vision & Business case
 Describes the high level goals & constraints
 Use case model
 Functional requirements, during inception the names of all use
cases are identified & 10% use cases are analyzed in detail
 Supplementary specification
 Describe other requirements (mostly non functional)
 Glossary
 Key domain terminology
 Others
 Risk List, Prototypes, Iteration Plan, SW Development Plan
Isn't That a Lot of Documentation?
 The artifacts should be considered optional
 Choose to create only those that really add value to the project

 Since this is evolutionary development, the point is not to create

complete specifications during this phase, but initial, rough
documents, that are refined during the elaboration iterations, in
response to the feedback from early programming and testing.
 Objective of creating artifacts is not the documentation but the
thinking, analysis & understanding - Agile Modeling perspective
 the greatest value of modeling is to improve understanding, rather than
to document reliable specifications
Inception Phase
 Common mistakes

 Devoting too much time to it (more than a few weeks)

 Defining none/all of the requirements

 All use cases in detail

 No use case in detail

 Defining architectural details (should be done iteratively in

elaboration)

 Missing Vision document or Business Case

Understanding
Requirements
Requirements: Definition

“Requirements are the capabilities and

conditions to which the system (the
project) must conform” [JBR99]
Types of Requirements
 In UP requirements are categorized according to FURPS+ model
[grady92]
 Functional
 Features, capabilities, security
 Usability
 Human factors, help, documentation
 Reliability
 Failure, recoverability
 Performance
 Response times, throughput, resource usage
 Supportability
 Adaptability, configurability
Types of Requirements
 Implementation
 Resource limitations, languages and tools
 Interface
 Interfacing with external systems
 Legal
 Licensing etc.
Types of Requirements
 Some of these requirements called “quality requirements”
 Usability, Reliability, Performance and Supportability

 Generally requirements are categorized as

 Functional (behavioral)

 Non-functional (everything else)

Types of Requirements
 Functional Requirements
 Describe the interactions between the system and its
environment independent from the implementation
 Example, “An operator must be able to define a new game. “

 Non-Functional Requirements
 These are the constraints on the services or functions offered by
the system
 Includes timing constraints, constraints on development process,
standards etc.
Use Case Modeling
Case Study: NextGen POS System
 We are asked to create a software system to run POS

(Point Of Sale) Terminal

 A computerized application used to record sales and

handle payments

 Includes H/W components

 bar code scanner, receipt printer etc.
Architectural Layers
 An OO information system is designed in terms of several
architectural layers
 User Interface (Presentation)
 UI layer has very little responsibility

 Thin layer , Graphical User Interface (GUI)

 Application Logic and Problem Domain Objects
 software objects (classes) representing domain concepts (a software
class named Sale) to fulfill application requirements

 Technical Services/ Integration/Database (Application

Logic- Service Objects)
 Non-problem objects that provide supporting services
 E.g. Interfacing with a database
Use-Case Modeling
 A use-case model is the set of all use cases

 It is a model of the system’s functionality and environment

 Customers and end users have goals and want computer

systems to meet them

 Use cases are stories of using a system to meet those goals

 A use-case is a collection of related success and failure

scenarios that describe actors using a system to support

(fulfill) a goal
Use-Case Modeling
 A Scenario is a specific sequence of actions and

interactions between actors and the system

 Example

 The scenario of successfully purchasing an item with cash, OR

 The scenario of failing to purchase an item because of a credit

transactional rejection
Use-Cases and Functional Requirements

 A use-case is a functional requirement – In terms of

FURPS+ model a use-case emphasizes “F”

 Other non-functional requirements can also be included

 A use-case must be written in black-box style, i.e. it

should only describe what the system must do – not how it

is to be done
Use-Case Formats
 A use-case may be written in
 Brief format
 short one-paragraph summary, usually of the main success
scenario. Example

 Casual format
 Informal paragraph format. Multiple paragraphs that cover various
scenarios. Example

 Fully-dressed format
 The most elaborate format. All steps and variations are written in
detail, and there are supporting sections, such as preconditions and
postconditions
How to Find Use Cases?
Step-1: Choosing the System Boundary

Example:
 POS is the System under design (SuD)
 Everything else of it is outside the system boundary, including:
 Cashier, payment authorization services etc.

Step-2 and 3: Finding Primary Actors and Goals

 Actors
 An actor is anything with behavior
 Actors are not only roles played by people, but by
Organizations, software, and other machines
 Three kinds of external Actors
 Primary actor, Supporting actor, Offstage actor
Types of Actors
 Primary actor
 Has user goals fulfilled through using services of SuD.
 Example: Cashier
 Supporting actor
 Provides a service (for example information) to the SuD.
 Example: The automated payment authorization service
 Identified to clarify external interfaces
 Offstage actor
 has an interest in the behavior of the use case, but is not
primary or supporting actor
 Example: A government tax agency
Identifying Primary Actors
 Questions to find actors and goals
 Who start and stops the system?

 Who does user and security management?

 Who does system administration?

 Who evaluates system activity or performance?

 How are software updates handled?

Class Activity
 Identify the use cases for following system
 Flight Information System
 Event Management System
 Identify the Actor and their Goal list for
the above mentioned system
Identifying Primary Actors, Goals and Use-
Cases

 Step-1: Choosing the System Boundary

 Step-2 and 3: Finding Primary Actors and Goals

 Step-4: Define Use Cases

 Define one use case for each user goal

 Name the use case similar to the user goal

 Example
 Goal: Process a sale; Use Case: ProcessSale

 Also name use case in “Verb Noun” format

 E.g. OpenAccount, EnrollStudent

More on Naming the Use Cases
 Use at least Verb + Noun (i.e. ”purchase book” not ”purchase”)
 Use undetermined numbers (i.e. ” purchase book” not ”purchase 1
book”)
 Use active tense (” purchase book” not ”purchase of book”)
 Make the name descriptable (i.e. ”buy book” not ”commit
transaction”)
 Show the value (i.e. ”buy book” not ”commit transaction”)
 Initially it’s better with names that are ”too long”, than too short
(i.e. ”log on to system, buy books and print receipt” is better than
”log on”)
Organizing Actor and Goals: Actor-Goal List
Primary Actors and their goals are recorded in an actor-goal list

Actor Goal Actor Goal

Cashier Process sales System Add users

Handle returns Administrator Modify users
Cash in Delete users
Cash out Manage
security

Manager start up Sales Activity Analyze sales

Shut down System and
performance
data

The Sales Activity System is a remote application that will frequently

request sales data from each POS node in the network
 Primary Actors and User goals
Dependency
 Depend on system boundary of the system under design
 Example
 Why is the cashier and not the customer a primary actor in the use case Process Sale

Enterprise Selling Things

Checkout Service
Sales Tax
Agency
POS System
Goal: Collect
taxes on sales Sales Activity
System Cashier

Customer

Goal: Buy items Goal: Analyze sales Goal: Process sales

and performance data
Use-Case Writing Style
 Essential Style
 keep the user interface out--focus on intent
 Two column format

Actor Action System Responsibility

1. Administrator identifies itself 2. Authenticates identify
3. …….

 One column format

1. Administrator identifies itself
2. System Authenticates identify
3. …….
 Use-Case Writing Style
 Concrete Style
 Text may also show windows screen shots, windows navigation
etc.
 Example

1.Administrator enters ID and Password in dialog box (see picture 2)

2.System authenticates Administrator
3. System displays the “edit users” window (see picture 4)
4. …….
Fully Dressed Use Case
Sections
Scope:
Level:
Primary Actor:
Stakeholders and interests:
Preconditions:
Success Guarantees (Post conditions):
Main Success Scenario ( Basic Flow):
Extensions (Alternate Flows):
Special Requirements:
Technology and data Variations List:
Frequency of Occurrence:
Open Issues:
 Fully Dressed Use Case
 Use Case Name: Start with a verb.
 Scope: The system under design.
 Level: "user-goal" or "subfunction"
 Primary Actor
 The principal actor that calls upon system services to fulfill a goal
 Stakeholders and Interests
 Stakeholders related to that use case and what they are looking for
 Pre Conditions
 What must always be true before beginning a scenario in the use case
 A precondition implies a scenario of another use case that has been
successfully completed
 Example: Log in use case
 In order to login system has power
Fully Dressed Use Case
 Success Guarantees ( Post Conditions)
 What must be true on successful completion of use case
either main scenario or some of the alternatives
 The guarantee should meet the needs of stakeholders
 Main Success Scenario
 Happy path scenario
 Basic Flow
 The path that specifies the interests of stakeholders
 Scenario records three kinds of steps
 An Interaction between Actors
 SuD itself is considered as an Actor when collaborating with other systems
 A validation (usually by the System)
 A state change by system (e.g. modified record)
Fully Dressed Use Case
 Extensions
 Alternate Flows
 Indicate all other scenarios/ branches both success and failure
 Combination of happy path and extension satisfy nearly almost all
interests of stakeholders
 Branches of main success scenario & can be notated with respect
to a use case
 Special Requirements:
 Non Functional requirements, quality attribute or constraints specifically
related to a use case
 Performance, reliability and usability qualities
 Design constraints
Fully Dressed Use Case
 Technology and data Variations List:
 Technical variations in how something must be done
 Example
 Use code scheme UPC etc.
 Credit account information is entered by credit card reader or
using keyboard
 Open Issues:
 Issues
 Policies
 Examples
 Who keeps cash?
 How credit card will be used?
Fully Dressed Use Case
 Example
Guideline: Finding Useful Use cases
 Which of these is a valid use case?
 Negotiate a Supplier Contract
 Handle Returns
 Log In
 Move Piece on Game Board
Guideline: Finding Useful Use cases

 There are several rules for deciding valid use

cases including;
 The Boss Test
 The EBP Test
 The Size Test
The Boss Test
 Your Boss asks, “what have you been doing all day”. You
Reply: “Logging in”

 Is your Boss happy?

 If not, the use case fails the Boss test

 It is not a desirable focus of requirements but a use case at

some low level
EBP Test

 An Elementary Business Process (EBP) is a term from

business process engineering field defined as:

“A task performed by one person in one place at one

time, in response to a business event, which adds
measurable business value and leaves the data in a
consistent state.”
The Size Test
 A use case is not a single action or step, rather it contains
many steps

 A common mistake in use case modeling is to define a

single step within a series of related steps as a use case

 For example, a use case called Enter ItemID, delete

lineitem, print receipt
Examples: Applying the Test
 Negotiate a Supplier Contract
 Much broader and longer than an EBP. Could be modeled as a
business use case rather than a system use case

 Handle Returns
 OK with the Boss. Seems like an EBP. Size is good.

 Log In
 Boss not happy if this is all you do all the day

 Move Piece on Game Board

 Single Step– Fails the size test
Guideline: Use Cases Identification
 Two Approaches

 Identification of Actors Event

 A good source for identifying use cases is external events
(initiated by Actors in the domain)

 Think about all the events from the outside world to which
you want to react

 Identification of Domain Activities

 A use case typically represent a major piece of functionality
that is complete from beginning to end in a domain
Guideline: Use Cases Identification
 Asking following questions may help to identify the use cases
for a system:
 What are the tasks of each actor?
 Will any actor
 create, store, change, remove or read information in the system?
 need to inform the system about sudden, external changes?

 What use cases will

 create, store, change, remove or read this information?
 support and maintain the system?

 Can all functional requirements be performed by the use

cases?
Use Case Diagrams
 A notation to illustrates the names of use cases, the
actors and their relationships
 Shows the boundary of the system
 Serves as communication tool summarizing the behavior
of the system and its actors
 System boundaries
 Hardware/software boundaries
 Departments in organization
 Entire organization
 Use Case Diagram Alternate
notation for a
computer
system actor
POS

Cashier Process Sale Payment

authorization
Service
Handle Returns
Actor <<Actor>>
Tax Calculator
Process Rental

Communication Cash In
<<Actor>>
Accounting System

Manage Security

System
Administrator
Manage users
Use Case

A Partial Use Case Diagram

 Diagramming Suggestions
 Limit the use case to user-goal level use cases
 Show computer system actors with an alternate notation to
human actors
 Show primary actors on left and supporting actors on right
 Actor box with symbol “Actor” called UML Stereotype
 UML Stereotyping is a mechanism to categorize an element in
some way

<< Actor >>

Payment Authorization
System
 Diagramming Suggestions
Show computer system
Limit the use actors with an alternate
case to user-goal notation to human
level use cases actors

POS
<<Actor>>
Process Sale Payment
authorization
Service
Cashier

Supporting actors
Primary actors on
on right
left
Diagramming Suggestions
 Use Case diagrams and relationships are secondary in use
case work

 Use Cases are text documents that means to write text

 Focus should be on writing text rather than creating use case

diagrams and focusing on use case relationships
 Concrete, Abstract, Base, and Addition
Use Cases
 A concrete use case is initiated by an actor and performs the entire behavior
desired by the actor. These are the elementary business process use cases.
 Process Sale is a concrete use case.

 Abstract use case is never instantiated by itself; it is a subfunction use case

that is part of another use case.
 Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story,
such as Process Sale.

 Base use case includes another use case, or that is extended by another use
case.
 Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use
case.

 addition use case is an inclusion or extension.

 Handle Credit Payment is the addition use case in the include relationship to Process Sale.
The include Relationship
 It is common to have some partial behavior that is common
across several use cases.

 For example, the description of paying by credit occurs in

several use cases, including Process Sale, Process Rental.

 Rather than duplicate this text, it is desirable to separate it

into its own subfunction use case, and indicate its inclusion.

 This is simply refactoring and linking text to avoid

duplication
Example
include Relationship in the Use-Case
Model
The extend Relationship
 Extend relationship is used to append to the use
case without modifying its original text by using
an extending or addition use case, and within it
 Describe where and under what condition it
extends the behavior of some base use case.
Example
extend Relationship in the Use-Case
Model
Exercise: Use Case
Consider the following scenario

A Bank Customer owns one or more Accounts in the Bank. In

order to withdraw amount from bank using ATM, The Bank
Customer specifies an Account and provides credentials to the
Bank proving that he/she is authorized to access the Bank
Account. The Bank Customer specifies the amount of money
he/she wishes to withdraw. The Bank checks if the amount is
consistent with the rules of the Bank and the state of the
Bank Customer’s account. If that is the case, the Bank
Customer receives the money in cash.
Use Case Attributes
Identify the following
Use Case Name
WithdrawMoney
Primary Actor
Bank Customer
Preconditions:
 Bank Customer has opened a Bank Account with the
Bank and
 Bank Customer has received an ATM Card and PIN

Postconditions:
 Bank Customer has the requested cash or
 Bank Customer receives an explanation from the ATM
about why the cash could not be dispensed
Identify the Flow of Events
Actor Actions System Response
1.The Bank Customer inputs the
card into the ATM.
2.The ATM requests the input of
a four-digit PIN.
3. The Bank Customer types in
PIN. 4. The ATM offers a choice of the
account numbers for selection by
the Bank Customer

5. The Bank Customer selects an

account. 6. The ATM requests the amount to
be withdrawn.

7. The Bank Customer inputs an

amount. 8.The ATM outputs the card, money
and a receipt and stops the interaction.
Identify Extensions
Actor steps
1. [Invalid card]
1. The Bank Customer inputs 1. The ATM outputs the card
her card into the ATM.
2. ATM stops the interaction.
[Invalid card]
3. The Bank Customer types in
PIN. 3. [Invalid PIN]
[Invalid PIN] 1. The ATM announces the failure
2. ATM offers a 2nd try as well as
5. The Bank Customer selects
canceling the whole use case.
an account .
3. After 3 failures, it announces the
possible retention of the card.
7. The Bank Customer inputs an 4. After the 4th failure it keeps the
amount. card and stops the interaction.

[Amount over limit] 7. [Amount over limit]

1. The ATM announces the failure
about the available limit
2. ATM offers a second try as well as
canceling the whole use case.
Project Activity
 (Must) Bring your deliverable-0 in next
class
Project Activity
1. Identify Actors & their Goals
2. Prepare an Actor-Goal list
3. Swap your list of actors & goals with another
group and Discuss it
4. Define usecase for each goal
5. Swap your list of use cases with another group
and Discuss it
6. Draw usecase diagram
7. Identify Primary usecase
Project Artifact - 1
 Actor-Goal list
 UseCase Model
 Usecase Diagram
 Usecases in fully dressed format