2. Open Account
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Open an Account” form
Relationships:
Include: Verify Account Information
Extend:
Normal Flow of Events
- Verify that the open account form is valid and complete
- Execute Verify Account Information Use Case
- Add new account for existing member.
Exceptional Flows:
1. a1. IF any information is missing on the open account form then immediately notify customer via the web page.
2. a1. IF customer enters invalid account information then immediately notify customer via web page.
3. Request Tax Information
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Request Tax Information” form
Relationships:
Include: Verify Account Information
Extend:
Normal Flow of Events
- Verify that the Request Tax Information is valid and complete
- Execute Verify Account Information Use Case
- Retrieve all tax related transactions from all accounts for given year
- Create properly formatted tax form
- Send tax form to printer for mailing
Exceptional Flows:
1. a1. IF any information is missing on the open account form then immediately notify customer via the web page.
2. a1. IF customer enters invalid account information then immediately notify customer via web page.
3. a1. IF given year data is not present since customer was not associated with Texans Credit Union at that time then reject request.
4. Wire Transfer Request
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Wire Transfer Request” form
Relationships:
Include: Verify Account Information, Verify Necessary Funds
Extend:
Normal Flow of Events
- Verify that the Wire Transfer Request form is valid and complete
- Execute Verify Account Information Use Case
- Execute Verify Necessary Funds Use Case
- Verify that destination bank information is valid and complete
- Transfer the funds to the specified destination
- Deduct the funds from the current bank account
Exceptional Flows:
1. a1 IF any information is missing on Wire Transfer Request form then immediately notify customer via the web page.
2. a1. IF customer enters invalid account information then immediately notify customer via web page.
3. a1. IF customer lacks the necessary funds then reject request
4. a1. If the destination is invalid then reject request
Use Case Diagram
Existing System Class Diagram
Object Behavior Model: Sequence Diagram for Major Use CasePurchase a CD Use Case:
Documentation of Use Cases
1. Data Associated with Use Case 1
CD-Purchase-Request = Member name + Member Number + Driver’s License Number + Issuing State + Mother’s Maiden Name + Daytime Phone Number + Account Type + Interest Payment Method + Transfer Amount + Transfer From Account
Account Type = [Term CD + Term CD Term | Jumbo CD + Jumbo CD Term | Bump CD + Bump CD Term]
Term CD Term = [91 Day Term | 182 Day Term | 12 Month Term | 18 Month Term | 24 Month Term | 30 Month Term | 36 Month Term | 42 Month Term | 48 Month Term | 60 Month Term ]
Jumbo CD Term = [ 182 Day Term | 12 Month Term ]
Bump CD Term = [ 24 Month Bump Up | 36 Month Bump Up | 48 Month Bump Up | 60 Month Bump Up ]
Interest Payment Method = [Compound to Certificate | Deposit to Share Account]
Transfer from Account = [Savings | Checking | Checking II | Money Market | Performance Money Market ]
2. Data Associated with Use Case 2
Open-an-account = Member Name + Member Number + Driver’s License Number + Issuing State + Mother’s Maiden Name + Daytime Phone Number + Account Type + Overdraft Protection + Travel Share +Send Temporary Checks + Transfer Amount + Transfer From Account
Account Type = [ Checking Account + Checking Account Type | Money Market + Money Market Type | Savings Account ]
Checking Account Type = [Free Checking | Rewards Checking | Checking II | Interest Checking | Future Students Checking]
Money Market Type = [ Money Market | Performance Money Market]
Transfer from Account = [Savings | Checking | Checking II | Money Market | Performance Money Market ]
3. Data Associated with Use Case 3
Request-tax-information = Member Name + Member Number + Daytime Phone Number + Tax Form + Tax Year
Tax Form = [1099-Int | 1099-R | 1098 | 5498 | FMV ]
Tax Year = [ 1997 | 1998 | 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 ]
4. Data Associated with Use Case 4
Wire-transfer-request = Member Name + Member Number + Mother’s Maiden Name + Transfer Amount + Account Number + Account Type + Wires To + (Credit To) + Final Credit To + Printed Name + Printed Address + Printed City + Printed State + Printed Zip + Country Code + Phone Number + Agreement and Authorization
Account Type = [ Checking Account + Checking Account Type | Money Market + Money Market Type | Savings Account ]
Wires To = [ Name of Bank + (Street Address) + City + State + Country + Swift code ]
Credit To = [ Name of Branch Bank/Account + Location of Branch Bank/Account + Bank/Account number ]
Final Credit To = [ Name on Account + Account Number + 1{Recipient Address}2 + Swift Code + Additional Instructions]
Section 2: System Upgrade
Context Diagram:
Since none of the problems and ideas for this project affect the actual interaction of the user with the texanscu.org website, the context diagram remains largely unchanged from the original version. The most significant change is the addition of “logon to system” task that is added to indicate the significance of the login process in setting up the required credentials that are used in the other tasks; for example to retrieve the amounts available to transfer into the CD in the “Purchase a CD” task.
Use Case Descriptions:
1. Process CD Purchase Request:
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a new CD Purchase Request
Relationships:
Include: Login to System, get Member Accounts and Balances, get Current CD Rates for User
Extend:
Normal Flow of Events
- Display amount available for investment into the CD from the different accounts that belong to the logged in member.
- Display CD rates customized for customer.
- Verify that the amount selected by customer does not exceed his available balance.
- Add CD to customer account.
- Transfer funds from customer selected account into newly created CD.
- Log transaction in the transaction table
Exceptional Flows:
2. a1. IF the customer lacks the necessary funds then immediately reject the CD creation request.
2. Open Account
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Open an Account” form
Relationships:
Include: Login to System, get Member Accounts and Balances
Extend:
Normal Flow of Events
- Let customer select the type of account to open from standard account types
- Add new account for existing member.
Exceptional Flows:
1. a1. IF any information is missing on the open account form then immediately notify customer via the web page.
3. Request Tax Information
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Request Tax Information” form
Relationships:
Include: Login to System, get account tax transactions
Extend:
Normal Flow of Events
- Display valid years that the user has tax records for.
- Retrieve all tax related transactions from all accounts for given year
- Create properly formatted tax form
- Send tax form to printer for mailing
Exceptional Flows:
4.a1. If the user has selected to receive the tax document electronically then display it in PDF format in the current browser window.
4. Wire Transfer Request
Primary Actor: Customer
Stakeholders: Bank teller
Trigger: Submission of a “Wire Transfer Request” form
Relationships:
Include: Login to System, get Member Accounts and Balances
Extend:
Normal Flow of Events
- Display all valid accounts for this member and the amounts available to transfer in each account.
- Let the user select the account and the amount to transfer
- Display a list of valid destination banks to wire funds to
- Once the customer selects a bank, the user can optionally select another bank in the credit to section, from the list of valid banks.
- The user can then enter the final credit information of the wire transfer
- Transfer the funds to the specified destination
- Deduct the funds from the current bank account
Exceptional Flows:
3.
a1 IF the bank that the user wants to transfer funds to is not in the list of valid banks:
a2.Let the user enter bank information by hand.
a3. Upon form submission send this request to a human bank teller to process the request.
a4. If the destination is invalid then reject request.
4.
a. Perform the same exceptional flow as step 3 a1-a4 for the credit to bank.
5. If the final credit information is invalid then halt the wire transfer process and notify the customer immediately.
5. get Member Accounts and Balances
Primary Actor: Internal to the system
Stakeholders: Customer
Trigger: process CD purchase request
Relationships:
Include: Login to system
Extend:
Normal Flow of Events
- Get the list of accounts for the currently logged in member
- For each account get the current balance
Exceptional Flows:
5. get Current CD Rates for Member
Primary Actor: Internal to the system
Stakeholders: Customer
Trigger: process CD purchase request
Relationships:
Include: Login to system
Extend:
Normal Flow of Events
- Get the list of currently offered CD types from the system
- For each CD
- If Member has a special CD rate offer for that CD return that
- Else return the default CD rate
Exceptional Flows:
6. Get Account Tax Transactions
Primary Actor: Internal to the system
Stakeholders: Customer
Trigger: process tax info request
Relationships:
Include: Login to system
Extend:
Normal Flow of Events
- For each account for currently logged in member
- get the Account tax related transactions
- Summarize transactions as complies with current tax code
Exceptional Flows:
6. Login to System
Primary Actor: Customer
Stakeholders: Customer
Trigger: process tax info request
Relationships:
Include:
Extend:
Normal Flow of Events
- Valid submitted user name and password
- Establish and track session for further interactions with the system by the member.
- Expire the session after 90 seconds of inactivity.
Exceptional Flows:
1.a1. If the user name and password do not authenticate correctly return an error
2. a1. If session tracking cannot be established notify user and give instructions for how to enable traceability for the most popular browser options.
Use Case Diagram
Notice that the new Use Case Diagram still includes the same 4 main use cases, but there is no longer a need for a separate use case to verify that the user information is valid, that is replaced by the login to system use case which quite simply validates the user credentials once at the beginning of the session and constantly associates any submitted form or request with the login account. This is also the reason why there is no specific need to verify that there are sufficient funds, since the user will be able to select only amounts that are valid and the transaction is considered to be atomic and synchronized such that while the process CD purchase request is in process the account balances cannot change.
Documentation of Use Cases
1. Data Associated with Use Case 1
CD-Purchase-Request = Account Type + Interest Payment Method + Transfer Amount + Transfer From Account
Account Type = [Term CD + Term CD Term | Jumbo CD + Jumbo CD Term | Bump CD + Bump CD Term]
Term CD Term = [91 Day Term | 182 Day Term | 12 Month Term | 18 Month Term | 24 Month Term | 30 Month Term | 36 Month Term | 42 Month Term | 48 Month Term | 60 Month Term ]
Jumbo CD Term = [ 182 Day Term | 12 Month Term ]
Bump CD Term = [ 24 Month Bump Up | 36 Month Bump Up | 48 Month Bump Up | 60 Month Bump Up ]
Interest Payment Method = [Compound to Certificate | Deposit to Share Account]
Transfer from Account = [Savings | Checking | Checking II | Money Market | Performance Money Market ]
2. Data Associated with Use Case 2
Open-an-account = Account Type + Overdraft Protection + Travel Share +Send Temporary Checks + Transfer Amount + Transfer From Account
Account Type = [ Checking Account + Checking Account Type | Money Market + Money Market Type | Savings Account ]
Checking Account Type = [Free Checking | Rewards Checking | Checking II | Interest Checking | Future Students Checking]
Money Market Type = [ Money Market | Performance Money Market]
Transfer from Account = [Savings | Checking | Checking II | Money Market | Performance Money Market ]
3. Data Associated with Use Case 3
Request-tax-information = Tax Form + Tax Year
Tax Form = [1099-Int | 1099-R | 1098 | 5498 | FMV ]
Tax Year = [ 1997 | 1998 | 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 ]
4. Data Associated with Use Case 4
Wire-transfer-request = Transfer Amount + Account Number + Account Type + Wires To + (Credit To) + Final Credit To + Printed Name + Printed Address + Printed City + Printed State + Printed Zip + Country Code + Phone Number + Agreement and Authorization
Account Type = [ Checking Account + Checking Account Type | Money Market + Money Market Type | Savings Account ]
Wires To = [ Name of Bank + (Street Address) + City + State + Country + Swift code ]
Credit To = [ Name of Branch Bank/Account + Location of Branch Bank/Account + Bank/Account number ]
Final Credit To = [ Name on Account + Account Number + 1{Recipient Address}2 + Swift Code + Additional Instructions]
Major Use Case Sequence Diagram:
This is the use case diagram for the purchase a CD use case.
New Form Design reflecting new process:
Note the following points:
- The current rates are clearly displayed to the user for the different CD amounts.
- Only the valid accounts available to the current user are displayed in the “Transfer from account” area.
- Because the user entered an amount of 2000.00, AJAX (Asynchronous Java with XML) or a similar technology is used to mark the savings account red and disable its radio select button because savings only has $121.11 which is insufficient to cover the $2000 CD.
- The user is not asked for information like driver’s license number or issuing state, instead the current logged in user name is clearly displayed in the upper right hand corner and the user is instructed to select a particular link if that is not his or her name.
Data Model: Class Diagram
Database Design:
Object Design
Method Specifications
Method: verifySufficientFunds
Method Name: verifySufficientFunds() Class Name: Account
Clients (Consumers):
Associated Use Cases: Open Account, Process CD Purchase Request, Wire Transfer Request
Description of Responsibilities: Check if the passed in amount is available in the account
Arguments Received: checkAmount
Type of Value Returned: boolean
Pre-Conditions: Synchronized access to account object, i.e. no other process can modify class while this transaction is ongoing.
Post-Conditions: The account is not changed the amount is simply validated.
Pseudocode:
Get a lock on the account
Get the current account balance
If current account balance is greater than checkAmount then
return true
else
return false
Method: addAccountToMember
Method Name: addAccountToMember() Class Name: Member
Clients (Consumers):
Associated Use Cases: Open Account
Description of Responsibilities: This method adds a new account to an existing Member
Arguments Received: anAccount, fundingAccount
Type of Value Returned: void
Pre-Conditions: Member already exists, session is established
Post-Conditions: Either a new account is added or an exception is raised. Initial balance for “anAccount” is subtracted from “fundingAccount”
Pseudocode:
Get balance from anAccount
Call fundingAccount.verifySufficientFunds passing in anAccount balance
If insufficient funds in fundingAccount throw exception
else subtract balance from fundingAccount
Method: verifyAccountInformation
Method Name: verifyAccountInformation() Class Name: Member
Clients (Consumers):
Associated Use Cases: Login
Description of Responsibilities: This method validates the member number and password against the Member table.
Arguments Received: memberNumber, memberPassword
Type of Value Returned: boolean
Pre-Conditions: An existing member account, a running system
Post-Conditions: None
Pseudocode:
Query the database for user memberNumber given
If the memberNumber exists then
validate the memberPassword against the stored password for the given member
if the password is invalid
return false
else
return true
else
return false
Method: generateTaxForm
Method Name: generateTaxForm() Class Name: Member
Clients (Consumers): Customer
Associated Use Cases: Request Tax Information
Description of Responsibilities: This method creates the tax form for the customer
Arguments Received: year
Type of Value Returned: TaxForm
Pre-Conditions: An existing member account, a running system
Post-Conditions: None
Pseudocode:
For each account in Member
Call getTaxRecords passing in the given year
Append tax transaction to tax form
Store tax form in PDF format in temporary storage
IF customer requested mailed form THEN
Forward PDF file to mail center
ELSE
Display PDF in browser screen
Method: getTaxRecords
Method Name: getTaxRecords() Class Name: Account
Clients (Consumers): Member class
Associated Use Cases: Request Tax Information
Description of Responsibilities: This method returns the relevant tax records for a given account
Arguments Received: year
Type of Value Returned: Array of Strings
Pre-Conditions: An existing account, a running system
Post-Conditions: None
Pseudocode:
For each transaction in account
IF transaction is in given year THEN
IF transaction is a taxable transaction THEN
add transaction to taxRecordsArray
return taxRecordsArray
Controls
- On the request tax information form a drop down list of only valid years when the user had a member account with the credit union.
- In the Open an Account screen, the user should not be able to transfer money greater than from the selected source account.
- A list of valid banks should be displayed in the Wire Transfer Request screen.
- Whenever radio buttons are displayed to let the user select an account to transfer funds from (e.g. Wire Transfer Request screen, or Open an Account screen) the accounts listed should only be the accounts owned by the current member.
- In the Wire Transfer Request screen the dollar amount to transfer cannot be negative.
- Common aspects of all forms such as the “Transfer from Account” section should be based on the same code and shouldn’t vary from form to form. This will guarantee that there is no variation from one form to the next.
- When opening a CD display only the accounts that have the valid minimum balances to support the selected account type, also don’t display any accounts that don’t have enough balance to cover the requested CD amount. This will avoid user entry error and help the users get the CD creation process right on the first try.
