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

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

Interface Design

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

Use Case Diagram w/o Interfaces

Use Case Diagram w/Interfaces #1

Use Case Diagram w/Interfaces #2

Use Case Diagram w/Interfaces #3

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

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

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

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

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)

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

Organization of a Storyboard Storyboard Sequence

Bad Interface Design:

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

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: http://ergo.human.cornell.edu/ahtutorials/interface.html Virginia Tech: http://www.edtech.vt.edu/edtech/id/interface/ Carnegie Mellon: http://www.usernomics.com/user-interface-design.html

Use Case Scenarios

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

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

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

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

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

Test Cases

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

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

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

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

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

Documentation

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.)

Project Issues

The System Project and the UP

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)

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

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

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.6 + (0.01 * TFactor)

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 = 1.4 + (-0.03 * EFactor) Use Case Points (UCP) = UUCP * TCF * EV

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

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)

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 (0.65 + 0.01 x CF)

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