1. Business Analysis & Data Design ITEC-630 Fall 2008
Interface Design, Use Case Scenarios, Test Cases & Project Issues
Professor J. Alberto Espinosa

2. Objectives Discuss interface design issues Discuss instance scenarios
Discuss test cases
Briefly discuss non-functional requirements
Discuss project issues

3. Interface Design

4. A Definition
Interface: “The place at which independent and often unrelated systems meet and act on or communicate with each other” – Webster dictionary
Network
Hardware
System
User
Software
Software

5. Use Case Diagram w/o Interfaces

6. Use Case Diagram w/Interfaces #1

7. Use Case Diagram w/Interfaces #2

8. Use Case Diagram w/Interfaces #3

9. List of Interfaces Interface Name Actor Funds Withdrawal User
Funds Deposit
Account Management
Customer Activity Inquiry
ATM Status Monitor
Cash Replenishment
Customer Accounts System
System

10. If the actor is a system:
If the actor is a user:
The interface captures how the user interacts with the system
If the actor is a system:
The interface will contain the program commands our system needs to interact with that external system

11. Each Interface Has: A name A set of “operation signatures” indicating:
which data to “get” from the actor with the operation (i.e., Get UserId, Name, etc.)
Which data to “return” to the actor when the operation is complete
A storyboard (for user interface only): visual illustration of the sequence of screen designs to complete these operations

12. Example of Operation Signatures: Funds Withdrawal Interface
Get data from card magnetic tape Get pass code from customer
Get customer transaction selection (user selects withdrawal)
Get account type for withdrawal
Get amount to withdraw
Return cash, or
Return error message to customer
Return thank you message to customer

13. A User Interface Can Be For:
Input into the system by the user for data entry or to query information from the system
A display output (on screen or other output device) by the system to the user
A printed output (on a printer or other output device)

14. Diagramming the Interface: with “Storyboards”
User interfaces can be diagrammed as “storyboards”
A storyboard is a series of drawings that depict how the system looks at the start of the operation and after each significant change to the look of the interface
Is like a sequence of screenshots that follows the use case execution sequence

15. Organization of a Storyboard
Storyboard Sequence

16. Bad Interface Design:

17. What to Include in an Interface Design Specification
A list of all the interfaces between actors and use cases
For each interface (any actor – user or external system):
Indicate whether the actor is a user (human actor) or an external system
Prepare a list of operation signatures detailing all the data that is passed to/from the system before each operation and the data that is returned from/to the system after each operation
For users (human actors only):
Indicate when/if operations are taking place for data input, display outputs or printed outputs
Prepare a storyboard for all screen input/output displays and printouts
Design the visual interface for all screen input/output displays and printouts
For external system actors (only):
Indicate when/if operations are taking place to input or output data from/to the system

18. General Quality Attributes of a User Interface Design
Ease of use
Intuitive use and navigation
Consistency across screens
Simplicity – e.g., no clutter, no information overload, no busy graphics
Exit/cancel options for users
Forgiving
Businesslike appearance
Readable and good color contrast
Reference sites: Cornell Univ: Virginia Tech: Carnegie Mellon:

19. Use Case Scenarios

20. Instance Scenarios
Are examples (i.e., paper prototypes) of how a Use Case will execute in a given situation
Per UML 1.3: “performance of a Use Case, initiated by a message instance by an instance of an actor”
They may represent a path (sunny day or rainy day) in the Use Case Flow of Events
Or specific instance within one of these paths
Experienced analysts prefer to keep Use Cases simple with low level of detail, so that they are easy to understand.
And complement them with instance scenarios that can help explore and gain more detailed insights into the Use Cases
They are particularly useful in modeling exceptions
Best candidates for instances: extreme values, exception conditions, and borderline conditions

21. Instance Scenarios Use Case Instance Scenarios UC 101-Ia
Input Parameters
Output Parameters
Conditions
UC 101
UC 101-Ib
Input Parameters
Use Case
Instance Scenarios
Output Parameters
Conditions
UC 101-Ic
Input Parameters
Output Parameters
Conditions

22. Example: Use Case Use Case ID UC-100 Use Case Withdraw Funds Actors
(P) Customer
Description
Customer logs in, selects withdraw funds, enters amount, gets cash
Pre-conditions
Welcome screen is on
Flow of Events
Customer slides card in and out
Machine prompts customer for password
Customer enters password
System authenticates customer
System presents user with a choice menu
Customer selects Withdraw Funds option
System asks customer to select account
Customer selects account
System asks customer for amount to withdraw
Customer enters amount
System dispenses cash and prints receipt
System logs customer out
Post-conditions
Welcome screen is back on
Alternative Flows
customer may not have sufficient funds; machine may not have enough cash
Etc.
Example: Use Case

23. Example: Instance Scenario
Use Case ID
UC-100-IS1
Use Case
Withdraw Funds
Instance Name
Attempt to withdraw with no funds in the account
Description
Customer logs in, selects withdraw funds, enters amount, but does not get cash due to insufficient funds.
Input Parameters
Withdrawal of $300 requested from checking account; there are only $100 available in the account’s balance
Instance Flow
Customer slides card in and out
ATM prompts customer for password
Customer enters the correct password
The system authenticates the customer and presents menu choice
The customer selects the Withdraw Funds option
System prompt customer to select account
The customer selects checking account
System asks for amount to withdraw
The customer enters $300
Inquire account balance – return $100
Display message about insufficient funds
Print statement of account balances
Prompt customer to (a) withdraw a different amount or (b) exit
If (a), go back to step 6
Output Parameters
A printout with account balances
Environmental Conditions
ATM machine has cash

24. Multiple Use Case Scenarios – e.g., new loan process

25. Test Cases

26. Testing Ensuring that the system performs as required Test types:
UNIT TESTING: Ensure that each part of the system work well individually
SYSTEM TESTING: Ensure that all the parts work well together
REGRESSION TESTING: Ensure that new software work well with the existing software
ACCEPTANCE TESTING: By users and/or clients
Methods:
BLACK BOX TESTING: Testing if the system does what is supposed to, without inspecting the internals of the system
CLEAR BOX TESTING: Inspecting and testing the internals of the system (opening the black box)
Test cases are useful for

27. Test Cases Each Use Case should have a “test suite” associated with it
Each test case in the suite represent a path in the Use Case Flow of Events
Ideally, each path should have a test case (difficult with large complex systems)
Pay attention to borderline conditions (e.g., customer withdraws maximum allowable cash, customer withdraws all funds available), which is usually where software fails

28. Test Suite Example: Withdraw Cash Use Case
Path 4
Path 5 S
Path 1 A
Path 2 E
Path 3 E SE S
Test Suite Example: Withdraw Cash Use Case S SE A E A SE SE S E S SE
A = Input or other action from an Actor
S = An action performed by the system
E = An exception (e.g., conditional flow) S

29. Test Cases Use Case Test Suite UC 101- Path 1 Pre-conditions
Post-conditions
UC 101
UC 101- Path 2
Pre-conditions
Use Case
Test Suite
Post-conditions
UC 101- Path 3
Pre-conditions
Post-conditions

30. Example: Test Case for Path 2
Use Case ID
UC-100-Path 2
Use Case
Withdraw Funds
Actors
(P) Customer
Description
Customer logs in, selects withdraw funds, enters amount, customer has fund, ATM has no cash
Pre-conditions
Welcome screen is on
Flow of Events
A1. Customer slides card in and out
S1. Machine prompts customer for password
A2. Customer enters password
S2. System authenticates customer
S3. System presents user with a choice menu
A3. Customer selects Withdraw Funds option
S4. System asks customer for amount to withdraw
A4. Customer enters amount
S5. System verifies that customer has funds
S6. System checks cash in ATM machine
E1. ATM has no cash
SE1. Notify customer
SE2. Notify ATM service
S7. Logout customer
Post-conditions
Welcome screen is back on
Alternative Flows
Etc.
Example: Test Case for Path 2

31. Documentation

32. Documentation
Use cases map directly to events that users will be engaged in
And to events in which external systems will interact with the system
So Use Cases can be used as the base to provide documentation for users
And for the interface with external systems
These documentation can be written to mirror Use Case, but perhaps with more user-friendly language, or
In the case of external system interfaces, with more technical language that relates to that system (e.g., TCP/IP connection, accounting system, etc.)

33. Project Issues

34. The System Project and the UP

35. The Project Plan It is based on iterations, per the UP
Define the iteration length
Develop a domain model early
Analyze, design, build, integrate, and test often
Estimate how many (fixed-length) iterations you will need for construction
Decide the order in which things will be built based on Use Case priorities
Try to build the core functionality of the product early (or at least prototype it)

36. Estimating Project Effort
Estimate the number of lines of code (LOCs)
Difficult to estimate upfront
Depends on the software language used
Not great for object-oriented systems & CASE tools
Constructive Cost Model (COCOMO)
A popular method
Effort estimation based on LOCs estimated
Same difficulties as with LOCs estimation
Use Case Points (UCP)
Similar to function points, but based on Use Case metrics
Function Points (FP)
Estimating effort based on what the software does, not LOCs
Every software function (e.g., a display, report, a data store) has a function count
Then adjusted to function points based on complexity factors

37. Use Case Points (UCP) (Rational Software – a new way of estimating effort)
Count Actors and multiply by their weight:
1 for a simple actor (an external system with a well defined interface)
2 for an average actor (an external systems with less defined interface or a person using a simple interface)
3 for a complex actor (people using a more complex graphical interface)
Count Use Cases and multiply by their weight
5 for simple Use Cases (3 transactions or less)
10 for average Use Cases (4-7 transactions)
15 for complex (more than 7 transactions)
A transaction is a set of Use Case steps performed entirely or not at all (i.e., number of paths)
Unadjusted Use Case Points (UUCP)
Adjust for complexity and environmental factors

38. Calculate the Technical Complexity Factor (TCF)
Description
Weight
Rating 0: Irrelevant 5: Essential
Weighted Rating T1
Distributed system 2 T2
Response performance objectives 1 T3
End-user efficiency T4
Complex internal processing T5
Code must be reusable T6
Easy to install
0.5 T7
Easy to use T8
Portable T9
Easy to change
T10
Concurrent
T11
Secure
T12
Access to 3rd parties
T13
User training facilities
TFactor = Sum of weighted ratings
TCF = (0.01 * TFactor)

39. Calculate the Environmental Factor for the Team (EV)
Description
Weight
Rating 0: none 3: average 5: expert
Weighted Rating F1
Familiar with Rational UP
1.5 F2
Application experience
0.5 F3
Object-oriented experience 1 F4
Lead analyst capability F5
Motivation
0: none 5: highest F6
Stable requirements 2
0: unstable 5: very stable F7
Part-time workers -1
0: none 5: all F8
Difficult programming language
0: easy 5: hardest
EFactor = Sum of Weighted ratings
EV = (-0.03 * EFactor)
Use Case Points (UCP) = UUCP * TCF * EV

40. FYI Only: Function Points (FP)
The traditional way of estimating effort
Count:
Number of user inputs
Number of user outputs
Number of user inquiries
Number of files
Number of external interfaces
Function Count = weight these counts based on their complexity and add them up
Function Points (FP) = adjust for other complexity factors

41. Function Count (FC) Item Description Count x Weight = Weighted Count
Simple
Avg
Complex
Number of user inputs 3 4 6
Number of user outputs 5 7
Number of user inquiries
Number of files 10 15
Number of external interfaces
Total Weighted Function Count (FC)

42. Complexity Factor (CF) and Function Points (FP)
Description
Rating 0: Irrelevant 5: Essential F1
Reliability and backup recovery F2
Data communications F3
Distributed processing F4
Performance F5
Operate on existing system F6
On-line data entry F7
Data entry over multiple screens F8
Master files updated on-line F9
Complex inputs, outputs, files & inquiries
F10
Complex internal processing
F11
Code needs to be reusable
F12
Need conversion and installation
F13
Multiple installations of the system
T14
Easy to change and use
Complexity Factor (CF) = sum of ratings
Function Points (FP) = FC x ( x CF)

43. Estimate Effort and Cost from Experience
Project
UCP’s
FP’s
LOCs
Effort (Person-Days
Cost per Person-Day
Total Cost
ATM System
60.22
45.22 xx
362
$1,200
$434,400
Loan Processing System
82.34
53.21
443
$531,600
Order Processing System
95.20
65.22
563
$675,600
Point of Sale System
110.65
78.44
615
$738,000
Etc.
………
….. ….
New project (est.)
134.30
108.77