Omni Application - Vision Document

Georgia State University
Group Information
Member name Percent contribution Activities completed by the member
Alisha Davis 25% Positioning, Goal Model; Use Case Model: Use-Case 1-6, Goal Use-
Case Traceability, Use Case Diagram; Object Model
Rony Garcia 25% Stakeholder Summary and User Summar; Use Case Model: Use-
Case 7-12;
Francis Ikome 25% Introduction; Stakeholder and User Descriptions; Use Case Model:
Storyboard;
Aash Modi 25% Introduction; Positioning, Stakeholder and User Descriptions; Goal
Model; Use Case Model: Use Case Diagram; App concept creation
Total 100

Georgia State University
Omni App
Vision
Version 2.0

Omni App Version: 2.0
Vision Date: 30/Oct/18
Group 6
Confidential Georgia State University, 2018 Page 3
Revision History
Date Version Description Author
25.Sept.2018 1.0 First draft of the vision document for the
Omni app. This version is limited to:
Introduction, Positioning, Stakeholders and
User Descriptions, Product Overview, and
Goal Model.
Aash,Alisha, Francis,
Rony
30.Oct.2018 2.0 Second draft of the vision document for the
Omni app. This version has added: Use
Case Model. Updates have been made to
Problem Statement under Positioning and
the Stakeholder Model.
Alisha, Francis, Rony,
Aash

Group 6
Table of Contents
Introduction 6
1.1 Purpose 6
1.2 Scope 6
1.3 Definitions, Acronyms, and Abbreviations 6
1.4 References 6
1.5 Analyst Certifications 6
1.6 Overview 6
2. Positioning 7
2.1 Business Opportunity 7
2.2 Problem Statement 7
2.3 Product Position Statement 7
3. Stakeholder and User Descriptions 8
3.1 Stakeholder Summary 8
3.2 User Summary 8
3.3 User Environment 9
3.4 Key Stakeholder or User Needs 9
4. Product Overview 10
4.1 Context Diagram 10
4.2 Assumptions and Dependencies 10
4.3 Licensing and Installation 10
5. Goal Model 10
5.1 Provide effective transfers between multiple digital wallets 10
5.1.1. Allow users to send currency fromone platform to others using the same or varying platforms. 10
5.1.1.1. WHEN a userwants to complete a transfer using,Cash app, PayPal, Google Wallet or Venmo,
THEN the systemallows payment. 10
5.1.1.2. WHEN a user submits recipient information, THEN allow transfer/request 10
5.1.1.3. WHEN a payment method is not saved, THEN close session to input payment information 10
5.1.1.4. WHEN the transfer is complete, THEN display confirmation 10
5.1.1.5. WHEN a userwants to submit a transfer/request,THEN the systemrequests which digital
wallet to use 10
5.2 Require logins to maintain security measures 11
5.2.1. A password is required to login to the application 11
5.2.1.1. WHEN an account is not set up, THEN prompt to create an account 11
5.2.1.2. WHILE an account is set up, THEN always display login page 11
5.2.1.3. WHILE password is incorrect, THEN DO NOT authenticate user 11
5.2.1.4. WHILE password is correct, THEN always allow display account page 11
5.3 Develop retaliatory model for errors 11
5.3.1. After spending limit is reached, incur percentage costs for amount exceeding limit (e.g. 540/500,
percentage of the 40) 11
5.3.1.1. WHEN the spending limit has been achieved, THEN avoid percentage costs 11
5.3.1.2. WHEN limit is reached, THEN systemwill request surcharge fromuser 11
5.3.1.3. WHEN user refuses to pay surcharge, CANCEL or DECLINE the user’s payment 11
5.4 Implement new model for business system 11
5.4.1. Allow an option to send a personalized debit card, similar to those that Cash App issues,where the
card will be able to utilize all of the platforms that Omni offers 11

Group 6
5.4.1.1. WHILE systemis in use, THEN display card option as recommended 11
5.4.1.2. WHILE offer is rejected, THEN DO NOT send personalized debit card 11
5.4.1.3. WHEN user requests card, THEN systemwill generate and mail card 11
5.5 Explore account data and permit amends 11
5.5.1. Allow a view of account and authorize account changes within application 11
6. Constraints 11
6.1. Design Constraints 11
6.1.1. System-Supported Platforms 11
6.1.2. Expose Features as Services 11
6.1.3. Use Existing Services and Data 11
6.1.4. Browser Compatibility 12
7. Precedence and Priority 12
8. Use-Case Model 12
8.1. Goal Use-Case Traceability 12
8.2. Use-Case Diagram 13
8.3. Business Process Model 14
8.4. Use-Case 1: Make Account 14
8.5. Use-Case 2: Transfer Funds 14
8.6. Use-Case 3: Request Funds 15
8.7. Use-Case 4: Add Payment Method 15
8.8. Use-Case 5: Remove Payment Method 15
8.9. Use-Case 6: Add Existing Digital Wallet(s) 16
8.10. Use-Case 7: View Account Details 16
8.11. Use-Case 8: Update Account Details 16
8.12. Use-Case 9: Manage Requests 17
8.13. Use-Case 10: View Transactions 17
8.14. Use-Case 11: Request Cash Card 17
8.15. Use-Case 12: Delete Account 18
8.16. Object Model 19
9. Design Model 19
10. Stakeholder Requests 19

Group 6
Vision
Introduction
1.1 Purpose
The purpose of this document is to collect, analyze, and define high-level needs and features of the Omni app. It
focuses on the capabilities needed by the stakeholders and the target users,and why these needs exist. The details of
how Omni fulfills these needs are detailed in the use-case and supplementary specifications.
The purpose of this vision document is to provide insight on the scope of Omni, its affected stakeholders and users,
and the overall goals the application strives to achieve.
1.2 Scope
Omni allows you to pay and request money from your friends and family. At its core, Omni provides a social way to
pay yourfriends when you owe them money and don't want to deal with cash. For example:
 Splitting a lunch bill
 Paying your friend half of a cab fare
 Sending your roommate your half of the rent
 Using Omni as a payment method in authorized partner apps.
You can now get paid for a service or shared product with another consumer without being limited to one digital
wallet. With Omni, consumers are now able to send or transfer money to others without needing to download
multiple person-to-person (P2P) digital wallet apps and making a separate account to accommodate for only a single
transaction.
1.3 Definitions, Acronyms, and Abbreviations
Digital Wallet: Systemthat securely stores users'payment information for numerous payment methods .
Spending Limit: A useris allowed to transfer or withdraw a maximum amount of $500 per day.
P2P: peer-to-peer or person-to-person
1.4 References
--
1.5 Analyst Certifications
We, Alisha Davis, Rony Garcia, Francis Ikome, and Aash Modi, have analyzed these documents and believe that
they:
 Comply with current UML syntax and best practices.
 Are internally consistent
 Meet the stakeholder needs,as we understand them
1.6 Overview
This Vision document includes positioning,stakeholder and userdescriptions, product overview, goal model,
constraints,precedence and priority, use-case model, and stakeholder requests.

Group 6
2. Positioning
2.1 Business Opportunity
Omni, a P2P service,is an intermediary: P2P services help people transfer funds from their financial
institution to a peers’ or a peer’s debit card using software applications. P2P apps are especially popular
with younger users who are more tech-savvy and less worried about potential danger of sharing their
financial information through a third-party software. There are multiple mobile applications that people
use when they want to send money to each other outside of the established business context – for
example, paying back a friend who lent you money for a movie ticket, or splitting the bill at a restaurant
among severalpeople. P2P application market is still not mature, with multiple services competing for the
same segment of the market.
Omni would be a conglomerate of the many different P2P platforms. Because Omniis not a separate
service company, we don’t have to worry about directly competing with financial giants. Omni is strictly
a storehouse of many P2P applications that allow users to transfer to separate entities while only using
one application instead of two or more. The system can be installed on Android, iOS, and Windows
devices. Hence,Omni forms an excellent platform for hosting an application that addresses the problems
for many users inconvenienced with conflicting P2P applications.
2.2 Problem Statement
The problem of Having to download multiple payment apps that only
allow a user to send money to another person if they
have the same app
affects Partnering P2P platforms
the impact of which is Needing a separate account for each transfer P2P platforms
and download each app
a successfulsolution would be A centralized hub application to consolidate related P2P
applications to provide convenience amongst end users with
conflicting apps
2.3 Product Position Statement
For All individuals with bank accounts who wish to use digital
currency as a means of payment
Who Want to transfer currency to friends and family who use
different P2P platforms that do not interchange
The (product name) Omni, mobile payment app
That Serves as an intermediary amongst P2P currency transfer
applications with little to no fees (dependent on usage)
Unlike Cash App, Venmo, or PayPal, Google Wallet
Our product Allows consumers to transfer digital currency to friends and
family using multiple P2P digital wallets all within one, single
app

Group 6
3. Stakeholder and User Descriptions
3.1 Stakeholder Summary
Name Description Responsibilities
Financial Institutions Commercial banks,
investment banks, and
Cryptocurrency
Approval of user transactions
Transfer of users’financial information to
Omni
Refund of transactions,if needed
Partners Other applications that
transfer money
Responsible for keeping account information
for their users.
Responsible for maintaining Users with access
to their information from our app
Support Provides technical support
for users
Provide users with safe, secure and seamless
transaction issues
Normal User Users who can use the app’s
basic features
Uses the app to send,receive and request
money
Prime User Users with premium
accounts
Uses the app for basic features and additional
perks such as setting up autopay,receiving a
physical card, and being able to make more
transactions a day than a normal user
Hacker A person who illegally gains
access to the app
Uses technical skills to steal money
3.2 User Summary
Name Description Responsibilities Stakeholder
Omni Users End users of
application
- Accessing account information
- Transferring funds to other
users
- Receiving funds from other
users
- Confirming total amount
received or transferred
Self -represented
Application
Partners
Banks
Credit Cards
- Being connected to our
app when users request
access
- Receive or send funds to
and from Omni users
Self-Represented
Hackers Threats to
application and
user
Try finding flaws and vulnerabilities
within the app to exploit them.
Self-Represented

Group 6
3.3 User Environment
A. Omni application will be used by people (mostly young generation) with current access to any of P2P
platform incurring issues with the following:
 Transferring over platforms (e.g. Cash app to Venmo)
 Not having multiple accounts on otherplatforms
B. The systemshall allow for communication with users.
 Alert of payment method is required
 Confirmation of transfer
 Allow transfer over multiple platforms
C. The systemshould be easy to use by user
 by providing a good search interface through which that person needs.
 by having clear and precise headings for different options
 By providing a “help/ how to use” tab for the user
3.4 Key Stakeholder or User Needs
What are the reasons for this problem?
It is difficult to transfer money to each other due to having different applications that are incompatible with
one another.The applications are rivals which usually requires two users to share a common application
before the currency transfer can begin.
• How is it solved now?
To bring all platforms together,Omni will be created and will allow the transfer of currency between one
P2P transfer application to another via Omni itself by linking their already installed application to Omni.
• What solutions does the stakeholder or user want?
To bypass the issue of installing multiple applications to transfer currency between peers who use differing
platforms.
It is important to understand the relative importance the stakeholder or userplaces on solving each problem.
Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like
addressed.
Need Priority Concerns Current Solution Proposed Solutions
User Friendly 2 More
complex than
a simple
system
Straightforward
request and
commands
Standard font size, inviting
color scheme, no redundant
additions within app
Broadcast messages 3 All alerts are
not able to be
seen
Display alerts that
require action before
removal
Display notifications to
alert users within app and
to direct them to app

Group 6
P2P consolidation 1 Each
platform will
not integrate
seamlessly
Allow integrations Allow users to transfer
without logins to other
internal wallets
4. Product Overview
4.1 Context Diagram
4.2 Assumptions and Dependencies
 Customers must possessa basic skill-set for using a digital device
 An internet connection,or WIFI, is needed to successfully use the software
4.3 Licensing and Installation
--
5. Goal Model
5.1 Provide effective transfers between multiple digital wallets
5.1.1. Allow users to send currency from one platform to others using the same or varying platforms.
5.1.1.1. WHEN a userwants to complete a transfer using,Cash app, PayPal, Google Wallet or
Venmo, THEN the systemallows payment.
5.1.1.2. WHEN a usersubmits recipient information, THEN allow transfer/request
5.1.1.3. WHEN a payment method is not saved,THEN close session to input payment information
5.1.1.4. WHEN the transfer is complete, THEN display confirmation
5.1.1.5. WHEN a userwants to submit a transfer/request,THEN the system requests which digital

Group 6
wallet to use
5.2 Require logins to maintain security measures
5.2.1. A password is required to login to the application
5.2.1.1. WHEN an account is not set up, THEN prompt to create an account
5.2.1.2. WHILE an account is set up, THEN always display login page
5.2.1.3. WHILE password is incorrect, THEN DO NOT authenticate user
5.2.1.4. WHILE password is correct, THEN always allow display account page
5.3 Develop retaliatory model for errors
5.3.1. After spending limit is reached,incur percentage costs for amount exceeding limit (e.g. 540/500,
percentage of the 40)
5.3.1.1. WHEN the spending limit has been achieved, THEN avoid percentage costs
5.3.1.2. WHEN limit is reached, THEN systemwill request surcharge from user
5.3.1.3. WHEN user refuses to pay surcharge, CANCEL or DECLINE the user’s payment
5.4 Implement new model for business system
5.4.1. Allow an option to send a personalized debit card, similar to those that Cash App issues, where
the card will be able to utilize all of the platforms that Omni offers
5.4.1.1. WHILE systemis in use,THEN display card option as recommended
5.4.1.2. WHILE offer is rejected, THEN DO NOT send personalized debit card
5.4.1.3. WHEN user requests card, THEN systemwill generate and mail card
5.5 Explore account data and permit amends
5.5.1. Allow a view of account and authorize account changes within application
5.5.1.1. WHEN an account is active, THEN grant account deletion
5.5.1.2. WHILE a payment method is present, THEN request changes to payment method(s)
5.5.1.3. WHILE a digital wallet is present,THEN request add/delete to wallet(s)
5.5.1.4. WHILE account is active, THEN allow changes to account
5.5.1.5. WHEN transactions are present,THEN allow examination of history
6. Constraints
6.1. Design Constraints
6.1.1. System-Supported Platforms
The systemwill be developed using platform tools and languages supported by the company, including:
o MS SQL Server Database
System must be multi-platform and support iOS, Android, and Windows mobile platforms.
6.1.2. Expose Features as Services
Where possible,the systemwill be designed in such a way that its features can be exposed as services.
6.1.3. Use Existing Services and Data
Where possible,the systemwill use existing services and data.

Group 6
6.1.4. Browser Compatibility
System should be web-based.
7. Precedence and Priority
--
8. Use-Case Model
[Place youruse-case model here. You can use the RUP template for use-case documentation; however, once
completed, they should be copied into this consolidated document.]
8.1. Goal Use-Case Traceability
Use Case Goals
5.1.1.1. 5.1.1.2. 5.1.1.4. 5.1.1.5. 5.2.1.1. 5.2.1.2. 5.2.1.3. 5.2.1.4. 5.3.1.1. 5.4.1.1. 5.5.1.1. 5.5.1.2. 5.5.1.3. 5.5.1.4. 5.5.1.5.
Make
Account
(UC 01)
X
Transfer
Funds (UC
02)
X X X X
Request
Funds (UC
03)
X X
Add
Payment
Method (UC
04)
X
Remove
Payment
Method (UC
05)
X
Add
Existing
Digital
Wallets (UC
06)
X
View
Account
Details (UC
07)
X
Update
Account
Details (UC
08)
X
Manage
Requests
(UC 09)
X
View
Transactions
(UC 10)
X

Group 6
Request
Cash Card
(UC 11)
X
Delete
Account
(UC 12)
X
8.2. Use-Case Diagram

Group 6
8.3. Business Process Model
8.4. Use-Case 1: Make Account
Name Make an Account
Description A customer can apply these steps to customize their
account information.
Goal 5.2.1.1.
Pre-condition The customer is a new user.
Post-condition The customer now has an account.
Customer (Actor) System
1. Watches Tutorial of app 2. Displays ‘sign up’ or ‘log in’ options
3. Selects “Not registered? Click here” 4. Displays popup menu for new accounts
5. Fills out personal information 6. Ask for creation of password
7. Enters account password 8. Send account verification code
9. User verifies account with email 10. Displays “Account Verified”
ALTERNATIVE(S)
A. User verifies account with different option
9. User verifies with phone number 10. Displays “Account verified”
8.5. Use-Case 2: Transfer Funds
Name Transfer Funds
Description A customer can apply these steps to enterand process
their payment information to process a fund transfer.
Goal 5.1.1.1.; 5.1.1.2.; 5.1.1.5
Pre-condition The customer proposes to transfer funds.
Post-condition The customer receives confirmation.
1. Select Digital Wallet 2. Requests for recipient information
3. Input recipient email/phone number 4. Prompts for an amount
5. Enter Amount & click “Send” 6. Choose a payment method
7. Select a payment method 8. Confirm payment method
9. Select “Confirm” 10. Displays confirmation
ALTERNATIVE(S)
A. Spending Limit Reached

Group 6
6. Displays error: “Spending Limit has been
reached.”
7. Prompts user to enter amount within limits
8. Enter amount & click “Send” [process
proceeds from step 5]
8.6. Use-Case 3: Request Funds
Name Request Funds
Description A customer can apply these steps to enterand process a
request of funds.
Goal 5.1.1.5.
Pre-condition The customer wants to request funds.
Post-condition The customer successfully requests funds from
recipient.
1. Select Digital Wallet 2. Requests for recipient information
3. Input recipient email/phone number 4. Prompts for an amount
5. Enter Amount & click “Request” 6. Choose a payment method
7. Select “Confirm” 8. Displays confirmation
ALTERNATIVE(S)
A. Cancel a Request
7. Select “Cancel” 8. Transaction cancelled
8.7. Use-Case 4: Add Payment Method
Name Add Payment Method
Description The customer wants to add a new or an additional
payment method.
Goal 5.5.1.2.
Pre-condition The customer wants to add a new or an additional
payment method.
Post-condition The customer adds a payment method.
1. Selects “Account” button 2. Presents Account Information
3. “Add Bank” 4. Select Bank to enter credentials
5. Enter bank login information & click
“Next”
6. Displays “Payment Method Added”
ALTERNATIVE(S)
A. Using Different Payment Method
3. Select “Add Credit Card”
4. Prompts to enter number
5. Enter Credit Card Number 6. Prompts for CVV & Exp. Date
7. Enter required information 8. Displays “Payment Method Added”
8.8. Use-Case 5: Remove Payment Method
Name Remove Payment Method
Description A customer successfully removes payment method.
Goal 5.5.1.2.

Group 6
Pre-condition The customer has a payment method on file.
Post-condition The customer successfully removes a payment method.
3. Selects “Remove bank or otherpayment
method” option
4. Presents banks and other payment
methods
5. Selects bank or payment method 6. Presents “Are you sure you want to
remove payment method?”
7. Confirms removal 8. Displays “Payment removed”
ALTERNATIVE(S)
A. Using Different Payment Method
7. Cancels removal of payment method 8. Takes user back to Account information
8.9. Use-Case 6: Add Existing Digital Wallet(s)
Name Add Existing Digital Wallet(s)
Description The customer successfully add more digital wallets.
Goal 5.5.1.3.
Pre-condition The customer wants to add a new or an additional
payment method.
Post-condition The customer adds new wallets.
3. Select “Add new Wallet” 4. Prompts for wallet
5. Chooses wallet
6. Enters wallet credentials
ALTERNATIVE(S)
8.10. Use-Case 7: View Account Details
Name View Account Details
Description A customer can apply these steps to review their
Goal 5.2.1.4.
Pre-condition The customer requests to view account page.
Post-condition The customer views account page.
ALTERNATIVE(S)
8.11. Use-Case 8: Update Account Details
Name Update Account Details
Description A customer can apply these steps to customize their
Goal 5.5.1.4.

Group 6
Pre-condition The customer wants to update existing account
information.
Post-condition The customer successfully makes changes to account
information.
3. Select “Edit” button & makes changes 4. Confirmation displayed
ALTERNATIVE(S)
8.12. Use-Case 9: Manage Requests
Name Manage Requests
Description The customer can accept or decline requested funds.
Goal 5.5.1.5.
Pre-condition The customer wants to edit requests.
Post-condition The customer makes edits.
1. Selects “Account” button 2. Account details
3. Selects “View Activity” button 4. Presents Account activity options
5. Selects “Manage Requests” 6. Displays pending requests
ALTERNATIVE(S)
8.13. Use-Case 10: View Transactions
Name View Transactions
Description The customer may view transaction history of outgoing
and incoming funds.
Goal 5.5.1.5.
Pre-condition The customer wants to view transaction history.
Post-Condition The customer views activity.
1. Selects “Account” button 2. Account details
3. Selects “View Activity” button 4. Presents Account Activity
ALTERNATIVE(S)
8.14. Use-Case 11: Request Cash Card
Name Request Cash Card
Description The customer may request to use the cash card for
transaction within, or outside,of app.
Goal 5.4.1.1.
Pre-condition Customer wishes to use a personalized Omni cash card.
Post-condition Customer receives card via mail in 5-7 business days.
1. Selects “Account” button 2. Presents account information options
3. Selects “Request Cash Card” 4. Displays Terms & Privacy Policy for
requesting Cash Card

Group 6
5. Accepts Terms and Privacy Policy 6. Presents Cash Card Customization options
7. User customizes Cash Card 8. Displays Confirm Card Design
9. Selects “Confirm” 10. Displays “Cash Card will be sent to your
address”
ALTERNATIVE(S)
A. Cancel account removal
9. Selects “Cancel” 10. Takes you back to Cash Card Customization
options
8.15. Use-Case 12: Delete Account
Name Delete Account
Description The customer may request to delete account.
Goal 5.5.1.1.
Pre-condition The customer has an account.
Post-condition The customer no longer has an account.
11. Selects “Account” button 12. Presents account information options
13. Selects account edit 14. Displays options for account edit
15. Selects account removal 16. Displays “Enter Password”
17. Inputs userpassword 18. Displays “Are you sure you want to delete
account?”
19. Selects “Yes” 20. Displays “Account Removed”
ALTERNATIVE(S)
B. Cancel account removal
9. Selects “No” 10. Takes you back to the main menu

Group 6
8.16. Object Model
9. Design Model
--
10.Stakeholder Requests
--

Omni Application - Vision Document

Recommended

Recommended

More Related Content

Similar to Omni Application - Vision Document

Similar to Omni Application - Vision Document (20)

Recently uploaded

Recently uploaded (20)

Omni Application - Vision Document