Iswe 9

TRODUCTION TO SOFTWARE ENGINEERING
REQUIREMENT ANALYSIS
REQUIREMENT ANALYSIS Bottom-up Approach
DFD 1. Objects and classes
EXAMPLE 2. The whole complex system
ERD Object Oriented Analysis and Design  A software development approach

that emphasizes a logical solution based on objects.
EXAMPLE
OBJECT ORIENTED CONCEPTS

OOA OOD
Identify Objects and Classes Define object life cycle

Identify the relations
Define class relationships
Identify the attributes
Describe the behavior Complete the definitions

May not be replicated without permission
UML:
• Unified Modeling Language
DFD • A set of modeling notations to specify or describe a software system in terms of
objects
EXAMPLE
• ”a graphical language for visualizing, specifying, constructing, and documenting
ERD the artifacts of a software-intensive system”
EXAMPLE • Class Diagram • UseCase Diagram

• Object Diagram • Activity Diagram
• Package Diagram • State Machine Diagram
OBJECT ORIENTED CONCEPTS • Component Diagram • Interaction Diagram
• Composite Structure Diagram • Sequence Diagram
UML • Deployment Diagram • Communication Diagram
• Profile Diagram • Interaction Overview Diagram
• Timing Diagram
Structure Diagram Behavior Diagram

REQUIREMENT ANALYSIS Use case  Written story

Play a Dice Game:
DFD
Player requests to roll the dice. System presents results: If the dice face value totals
EXAMPLE seven, player wins; otherwise, player loses.
ERD Domain Model  Visualization of the Concept (Conceptual Object Model)
EXAMPLE
Player 1 Rolls 2 Die
Name FaceValue
UML
1 2
EXAMPLE
Plays
1 DiceGame 1 Includes

REQUIREMENT ANALYSIS Interaction Diagram (Sequence Diagram)

Flow of messages between software objects
DFD
EXAMPLE
ERD
EXAMPLE
UML
EXAMPLE

REQUIREMENT ANALYSIS Class Diagrams 

Shows the attributes and methods of the software classes
DFD
EXAMPLE
ERD
EXAMPLE
UML
EXAMPLE

REQUIREMENT ANALYSIS Class Diagrams 

Shows the attributes and methods of the software classes
DFD
EXAMPLE public class Circle

{
ERD private double radius;
private double area;
EXAMPLE
protected double getArea();
UML public void setCenter(Point);

public Point center;
EXAMPLE }

Class Diagrams 
REQUIREMENT ANALYSIS Shows the attributes and methods of the software classes
DFD public class Shape

{
public void draw(Circle c);
EXAMPLE
private Point var1;
// Some other variables and methods …
ERD }
EXAMPLE
public class Circle
OBJECT ORIENTED CONCEPTS {
private double radius;
UML private double area;
protected double getArea();

EXAMPLE
public void setCenter(Point);
public Point center;
}
Class Diagrams 
REQUIREMENT ANALYSIS Shows the attributes and methods of the software classes
DFD public class Child extends Parent

{
EXAMPLE public void method2();
}
ERD
EXAMPLE

public class Parent
{
UML
public void method1();
EXAMPLE }

USE CASE
Registration System
• USE CASE
Student
Registration
System
Login
Student Administrator
Manage
Classes
Reports

USE CASE
Use Case
• USE CASE
• Model the user’s view of the functionality of a system
• A set of related success and failure scenarios
• describe an actor using a system to support a goal
• Used to identify requirements
Advantages
Tool for communication
Easy to read
Easy to track
Show functional requirements
Emphasis on user goals and perspective

USE CASE
• USE CASE
• Context Diagram of a system
Use case diagram
• Quick way to list the use cases
• A specific sequence of interactions between

actors and the system
Set of scenarios
• A particular story of using the system
• Use case instance
Set of uses case descriptions Describe the complete functionality of the

system.
Actors and their descriptions All external entities that interact with a
system

USE CASE
• USE CASE Actor

• Anything with behavior, e.g. a person, organization, software
• It can be the system under discussion (SuD)
• call the service of other systems
• External entity interacting with the Sud
Has a goal within the Sud

Primary
actor Importance: Find user goals
Has an interest in the functionality of the Sud

Importance: to ensure all necessary interests Provides a service to the Sud
are captured Importance: Clarify external
Actor
protocol and interfaces
Offstage Supporting
actor actor

USE CASE
• USE CASE
One paragraph
Brief summary
Main success scenarios
Informal
Multiple paragraphs Casual
Various scenarios
Fully
In detail scenarios
dressed

USE CASE
• USE CASE

USE CASE
• System use case : describe use of a software system

• USE CASE Scope:
Bounds the SuD. • Business use case : describe behavior of a business
(enterprise-level)
• User-goal : Describe the scenarios based on the primary

Level actor’s goals
• Subfunction : describe sub steps required to support the
goals
Stakeholders and Interests List

What should be in the use case?  satisfies all the stakeholders’ interests.
Preconditions & Post conditions

What must be true before starting the scenario
What must be true after successful completion of the scenario

USE CASE
• USE CASE Main success scenario: Describes a typical success path to achieve the goal
Happy path/ Typical Flow
Interaction between
Validation State Change
actors
Example:
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
Alternate Flows Describes all the other scenarios both success and
failure.
Example:
1 - Invalid item ID (not found in system):
1. System signals error and rejects entry.
2. Cashier responds to the error:
May not be replicated without permission In a case of performing another use case, indicate it by an underlining.
USE CASE
Brief use case
• USE CASE
Process Sale:
• EXAMPLE A customer arrives at a checkout with items to purchase. The cashier uses the POS
system to record each purchased item. The system presents a running total and line-
item details. The customer enters payment information, which the system validates and
records. The system updates inventory. The customer receives a receipt from the
system and leaves with the items.

USE CASE
UC1: Process Sale Fully
• USE CASE d
re s s
Scope: NextGen POS application ed u
Level: user goal s e ca
se
• EXAMPLE Primary Actor: Cashier
Stakeholders and Interests:
• Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are
deducted from his/her salary.
• Salesperson: Wants sales commissions updated.
• Customer: Wants purchase and fast service with minimal effort. Wants easily visible
display of entered items and prices. Wants proof of purchase to support returns.
• Company: Wants to accurately record transactions and satisfy customer interests. Wants
to ensure that Payment Authorization Service payment receivables are recorded. Wants
some fault tolerance to allow sales capture even if server components (e.g., remote credit
validation) are unavailable. Wants automatic and fast update of accounting and inventory.
• Manager: Wants to be able to quickly perform override operations, and easily debug
Cashier problems.
• Government Tax Agencies: Want to collect tax from every sale. May be multiple
agencies, such as national, state, and county.
• Payment Authorization Service: Wants to receive digital authorization requests in
the correct format and protocol. Wants to accurately account for their payables to the
store.May not be replicated without permission
USE CASE
UC1: Process Sale (Cont.)
• USE CASE
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting
• EXAMPLE and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization
approvals are recorded.
Main Success Scenario (or Basic Flow):
Customer arrives at POS checkout with goods and/or services to purchase.
Cashier starts a new sale.
Cashier enters item identifier.
System records sale line item and presents item description, price, and running total. Price calculated
from a set of price rules.
Cashier repeats steps 3-4 until indicates done.
System presents total with taxes calculated.
Cashier tells Customer the total, and asks for payment.
Customer pays and System handles payment.
System logs completed sale and sends sale and payment information to the external Accounting
system (for accounting and commissions) and Inventory system (to update inventory).
System presents receipt.
Customer leaves with receipt and goods (if any).

USE CASE
• USE CASE
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
• EXAMPLE 1. System enters Manager-authorized mode.
2. Manager or Cashier performs one Manager-mode operation. e.g., cash balance change, resume a
suspended sale on another register, void a sale, etc.
3. System reverts to Cashier-authorized mode.
*b. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and events can be
recovered from any step of the scenario.
4. Cashier restarts System, logs in, and requests recovery of prior state.
5. System reconstructs prior state.
1. System detects anomalies preventing recovery:
2. System signals error to the Cashier, records the error, and enters a clean state.
3. Cashier starts a new sale.
1a. Customer or Manager indicate to resume a suspended sale.
4. Cashier performs resume operation, and enters the ID to retrieve the sale.
5. System displays the state of the resumed sale, with subtotal.
1. Sale not found.
1. System signals error to the Cashier.
2. Cashier probably starts new sale and re-enters all items.
6. Cashier continues with sale (probably entering more items or handling payment).
2-4a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples)
7. Cashier verifies, and then enters tax-exempt status code.
May not be replicated without permission 8. System records status (which it will use during tax calculations)
USE CASE
• USE CASE
3a. Invalid item ID (not found in system):
1. System signals error and rejects entry.
• EXAMPLE 2. Cashier responds to the error:
1. There is a human-readable item ID (e.g., a numeric UPC):
1. Cashier manually enters the item ID.
2. System displays description and price.
1. Invalid item ID: System signals error. Cashier tries alternate method.
2. There is no item ID, but there is a price on the tag:
1. Cashier asks Manager to perform an override operation.
2. Managers performs override.
3. Cashier indicates manual price entry, enters price, and requests standard taxation for
this amount (because there is no product information, the tax engine can't otherwise
deduce how to tax it)
…
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 and 7.
-…

USE CASE
• USE CASE
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or
• EXAMPLE 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 scheme.
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 customers will want digital signature capture.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
- 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?

USE CASE
Guideline
• USE CASE
Keep the user interface out
Focus on actor intent
Write terse use case
• The system records the sale

Write black-box use case
• The system writes the sale to
• Do not describe the internal details (e.g. design, components) a database
• State what the system must do
• The system generates a SQL
INSERT statement for the
Actor-Goal Perspective
sale
• Focus on actor’s goal and situation

USE CASE
How to define
• USE CASE
Identify the
Define use cases
system
for the goals
boundary
Identify
Identify
the
the actors’
primary
goals
actors

USE CASE
• USE CASE
Draw the results in a use case diagram
• naming the goals as use cases
How to organize
1. Write an actor-goal list

2. Review and refine it
3. Draw the use case diagram
Actor Goal Actor Goal

Cashier Process Sales System Add users
Process Rentals Administrator Modify users
Handle Returns Delete users
Cash in Manage Security
Cash out Manage system tables

USE CASE
Name of use case
• USE CASE
NextGen
“actor”
Process Payment
Sale Authorization
Service
Cashier …
Supporting actors
Primary actors (right)
May not be replicated without permission (Left)
USE CASE
• USE CASE

USE CASE
Use Case UC1: Play Monopoly Game
• USE CASE Scope: Monopoly application
Level: user goal
Primary Actor: Observer
Stakeholders and Interests:
- Observer: Wants to easily observe the output of the game simulation.
Main Success Scenario:
1. Observer requests new game initialization, enters number of players.
2. Observer starts play.
3. System displays game trace for next player move (see domain rules, and
"game trace" in glossary for trace details).
Repeat step 3 until a winner or Observer cancels.
Extensions:
*a. At any time, System fails:
(To support recovery, System logs after each completed move)
4. Observer restarts System.
5. System detects prior failure, reconstructs state, and prompts to continue.
6. Observer chooses to continue (from last completed player turn).
Special Requirements:
- Provide both graphical and text trace modes.
USE CASE
• USE CASE

USE CASE
• USE CASE
• TIMING
Use-Case Model is started in About 10% of the use case

Inception written in any detail
Incrementally written over the Detailed use cases are written

iterations of the elaboration by the end of elaboration

USE CASE
• USE CASE Inception phase:
• Not all use cases are written in their fully dressed format.
• TIMING
• The team starts to form a high-level picture of the system's functionality.
• Most of the interesting, complex, or risky use cases are written in brief format.
• Fully dressed format: 10% to 20% of the use cases that
• represent core complex functions,
• require building the core architecture, or
• that are especially risky in some dimension.
Fully Dressed Casual Brief
Process Sale Process Rental Cash In
Handle Returns Analyze Sales Activity Cash Out
Manage Security Manage Users
… Start Up
Shut Down
Manage System Tables
May not be replicated without permission …
OTHER REQUIREMENTS
OTHER REQUIREMENTS Supplementary Specification
• Identifies reports,
• Documentation,
• Packaging,
• Licensing,
• etc
Glossary
• Terms and definitions

• Dictionary
Vision
• The vision of the project
Business Rules
• Long-living rules, e.g. tax law

OTHER REQUIREMENTS
OTHER REQUIREMENTS
S: start
R: refine

OTHER REQUIREMENTS
The requirements for the 1st iteration of the NextGen POS application:
OTHER REQUIREMENTS
 Implement a basic, key scenario of the Process Sale use case:
EXAMPLE
– Entering items and receiving a cash payment.
 Implement a Start Up use case as necessary to support the initialization needs of the
iteration.
 Nothing fancy or complex is handled,
– just a simple happy path scenario, and
– the design and implementation to support it.
 There is no collaboration with external services,
– such as a tax calculator or product database.
 No complex pricing rules are applied.

OTHER REQUIREMENTS
OTHER REQUIREMENTS
EXAMPLE
In Iterative Development Requirements for 1st iteration is a
We Don't Implement All subset of the complete

the Requirements at Once. requirements or use cases.

Iswe 9

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iswe 9

Uploaded by

Copyright:

Available Formats

TRODUCTION TO SOFTWARE ENGINEERING

REQUIREMENT ANALYSIS Bottom-up Approach

DFD 1. Objects and classes

EXAMPLE 2. The whole complex system

ERD Object Oriented Analysis and Design  A software development approach

OBJECT ORIENTED CONCEPTS

Identify Objects and Classes Define object life cycle

Describe the behavior Complete the definitions

EXAMPLE • Class Diagram • UseCase Diagram

Structure Diagram Behavior Diagram

May not be replicated without permission

REQUIREMENT ANALYSIS Use case  Written story

EXAMPLE seven, player wins; otherwise, player loses.

ERD Domain Model  Visualization of the Concept (Conceptual Object Model)

May not be replicated without permission

REQUIREMENT ANALYSIS Interaction Diagram (Sequence Diagram)

OBJECT ORIENTED CONCEPTS

May not be replicated without permission

REQUIREMENT ANALYSIS Class Diagrams 

OBJECT ORIENTED CONCEPTS

May not be replicated without permission

REQUIREMENT ANALYSIS Class Diagrams 

EXAMPLE public class Circle

UML public void setCenter(Point);

May not be replicated without permission

DFD public class Shape

protected double getArea();

DFD public class Child extends Parent

OBJECT ORIENTED CONCEPTS

May not be replicated without permission

May not be replicated without permission

Tool for communication

Show functional requirements

Emphasis on user goals and perspective

• A specific sequence of interactions between

Set of uses case descriptions Describe the complete functionality of the

May not be replicated without permission

• USE CASE Actor

Has a goal within the Sud

Has an interest in the functionality of the Sud

May not be replicated without permission

May not be replicated without permission

May not be replicated without permission

• System use case : describe use of a software system

• User-goal : Describe the scenarios based on the primary

Stakeholders and Interests List

Preconditions & Post conditions

May not be replicated without permission

May not be replicated without permission

• Salesperson: Wants sales commissions updated.

May not be replicated without permission

May not be replicated without permission

May not be replicated without permission

Keep the user interface out

Focus on actor intent

Write terse use case

• The system records the sale

May not be replicated without permission

May not be replicated without permission

1. Write an actor-goal list

Actor Goal Actor Goal

May not be replicated without permission