Jim Richardson Software Engineering Capstone 1 IP Phase 5

Running head: SOFTWARE DEVELOPMENT PLAN 1
Software Engineering Capstone 1
SWE 481
Project Risks
Professor N. Abbas
Individual Project Phase 5
Jim Richardson
December 19, 2014
*Repurposed work: Portions of this task contains material originally submitted by Jim
Richardson during the 1403A Session, Software Requirements Engineering CS455, with
Professor T. Atencio between July 6, 2014 and August 12, 2014 and during the 1404A Session,
Software Project Management SWE440, with Professor C. Tilden between October 5, 2014 and
November 11, 2014. Original submissions are the intellectual property of Jim Richardson and
Colorado Technical University Online.*

SOFTWARE DEVELOPMENT PLAN 2
Table of Contents
Document Version Control and Revision History.......................................................................... 3
I. Project Outline – Phase 1......................................................................................................... 4
 Functional System Features ............................................................................................. 4
 Non-Functional System Features ..................................................................................... 7
 Major Issues to Consider.................................................................................................. 8
II. Development Methodology – Phase 1 ............................................................................... 11
 Justification .................................................................................................................... 15
III. Requirements – Phase 2..................................................................................................... 16
 Requirements Table........................................................................................................ 18
IV. Design – Phase 2................................................................................................................ 22
 Smartphone Architecture................................................................................................ 22
 Operating Environment and System Architecture ......................................................... 23
 Application Specifications and Architecture.................................................................. 24
 Use Case Diagram.......................................................................................................... 26
 Class Diagram ................................................................................................................ 29
 Component Diagram ...................................................................................................... 30
 Visual User Interface Design ......................................................................................... 30
V. Development – Phase 3...................................................................................................... 32
VI. Testing – Phase 3 ............................................................................................................... 34
 Test Case 1: Login.......................................................................................................... 35
 Test Case 2: View Financial Statements........................................................................ 38
 Test Case 3: Transfer Funds........................................................................................... 43
VII. Project Schedule – Phase 4 ................................................................................................ 51
VIII. Risk Analysis – Phase 5 ................................................................................................. 54
 Impact Scale................................................................................................................... 56
 Probability Scale ............................................................................................................ 56
 Risk Identification and Risk Response Table ................................................................ 57
IX. References.......................................................................................................................... 64

Document Version Control and Revision History
Name Date Reason for Change Version Number
Jim Richardson 11/23/2014 Origination of the Software Development
Plan for Capstone Bank
1.0
Jim Richardson 12/01/2014 Added content regarding Requirements
Engineering, system architecture, and
design
1.1
Jim Richardson 12/06/2014 Added content to discuss Development
and Testing
1.2
Jim Richardson 12/13/2014 Added content to discuss the Project
Schedule
1.3
Jim Richardson 12/19/2014 Added Risk Analysis and finalized the
Software Development Plan
2.0

I. Project Outline – Phase 1
Recently, Capstone Bank discovered through market research that Capstone Bank’s
services were lacking luster to maintain a competitive edge within the financial industry.
Subsequently, Capstone Bank decided to explore options and solutions to regain their status as a
modern financial institution. Essentially, Capstone Bank aspires to regain their appeal to become
a worthy contender in the financial industry once again. During deliberations, the notion of
introducing a mobile banking application emerges. After considerable consideration, Capstone
Bank ascertains that the implementation and deployment of a mobile banking application would
restore Capstone Bank’s status and increase the image of their institution, as well as increase
revenue through an expanded clientele. Essentially, since mobility and portability are modern
conveniences, Capstone Bank determines that adding a new service, a mobile banking
application, to their existing legacy web-based and on-location banking services, Capstone Bank
will reach a new audience of users and appease the existing customers. Accordingly, Capstone
Bank begins to formulate the design, features, and services they wish to offer through the mobile
banking application. After Capstone Bank decides upon the overarching design, establishes the
fundamentals, and concludes the details of the mobile banking application, Capstone Bank issues
a formal Request for Proposal (RFP).
Accordingly, Capstone Bank determines that the Capstone Mobile Banking Application
(CMBA) will include the following functional and non-functional features:
 Functional System Features
Functional System Feature Description
FSF001: Login The Login feature will allow the user/customer to enter their
account associated login credentials to access their established
Capstone Bank account(s), which includes personal checking,
personal saving, business checking, and business saving

accounts. The Login feature will provide the user with a screen
that allows the user to enter both their Capstone Bank user
identification name and password. The user’s login credentials
will coincide with Capstone Bank’s legacy web-based banking
service to minimize the need to remember multiple user names
and passwords.
FSF002: View Balances The View Balances feature will provide the customer with
opportunities to view their Capstone Bank account balance(s).
After entering the correct login credentials, the CMBA will
present a screen of options to select. Within this list of options,
the user will be able to select the View Balances option to view
the current balances of all associated and linked Capstone
Bank accounts.
FSF003: Transfer Funds The Transfer Funds feature will provide the customer with
opportunities to transfer funds between all associated and
linked Capstone Bank Accounts. Essentially, after entering the
correct login credentials, the CMBA will present a screen of
options to select. Within this list of options, the user will be
able to select the Transfer Funds option. After selecting the
Transfer Funds option, the user will be able to select the
sending and receiving accounts, enter the amount of funds to
transfer from the sending account to the receiving account,
specify the date in which the transfer should transpire, and
indicate the frequency in which this transfer transaction should
occur. Once the user enters the appropriate information, the
CMBA will communicate with Capstone Bank’s existing
database and application servers to verify the transaction,
perform the transaction, and update the user’s accounts with
the recent transaction. Upon confirmation and performed
account update, Capstone Bank’s database and application
servers will issue a confirmation number back to the CMBA to
display to the user.
FSF004: Make Photographed
Deposits
The Make Photographed Deposit feature will provide users
with opportunities to deposit checks into their corresponding
Capstone Bank account(s). Principally, after entering the
correct login credentials, the CMBA will present a screen of
options to select. Within this list of options, the user will be
able to select the Make Photographed Deposit. After selecting
the Make Photographed Deposit feature, the CMBA will
trigger the mobile phone’s enabled camera. Once the mobile
phone’s enabled-camera is active, the CMBA will prompt the
user to capture the images of the front and back of the check.
Link Once the CMBA collaboratively works with the
smartphone’s enabled camera to capture the images of the
check intended for deposit, the CMBA will prompt the user to
send the images for verification. Once Capstone Bank’s

database and application servers receive the images, Capstone
Bank’s database and application servers will attempt to verify
and confirm the deposit, perform the deposit, and update the
corresponding account with the deposit. Upon confirmation
and performed account update, Capstone Bank’s database and
application servers will issue a confirmation number back to
the CMBA to display to the user.
FSF0005: Link Accounts The Link Accounts feature will provide users with
opportunities to link multiple Capstone Bank accounts to one
username or one account. After entering the correct login
credentials, the CMBA will present a screen of options to
select. Within this list of options, the user will be able to select
the option to add or link accounts to their main Capstone Bank
user login name or main Capstone Bank account. In the event
that user selects the Link Accounts options, the CMBA will
present a screen to the user to enter their corresponding
Capstone Bank account’s information intended for linked
access. Once the user enters the correct account information,
the CMBA will prompt the user to send the information for
verification. Upon verification of the intended account for
linked access, Capstone Bank’s database servers and
application servers will associate and link the corresponding
accounts to the main Capstone Bank account and user name.
Once association is complete, Capstone Bank’s database
servers and application servers will update the main account
and user name with the linked accounts and issue confirmation
back to the CMBA. In addition to providing users with abilities
to link accounts, the Link Accounts feature will provide users
with opportunities to unlink previously linked accounts via the
same process of linking accounts.
FSF006: View Financial
Statements
The View Financial Statements feature will provide users with
opportunities to review a list of financial transactions
associated with their Capstone Bank accounts. Essentially,
after entering the correct login credentials, the CMBA will
present a screen of options to select. Within this list of options,
the user will be able to select the option to View Financial
Statements. After selecting the View Financial Statements
option, the user will be able to view all transactions associated
with their Capstone Bank accounts. The View Financial
Statements option will retrieve and display up to three months,
from the data of inquiry, of transaction data for the user’s
review. Essentially, once the user selects the View Financial
Statements option, the CMBA will query Capstone Bank’s
database servers to retrieve a list of transactions. Upon
retrieval of the list of transactions, Capstone Bank’s database
and application servers will transmit the information back to

the CMBA for display to the user.
 Non-Functional System Features
Non-Functional System
Feature
Description
NFSF3000: Secure
Connection and Encrypted
Data Transfers
The CMBA will feature secure connection and encrypted data
transfers through Secure Socket Layer (SSL) network security
protocols. Once the user accesses and deploys the CMBA, the
CMBA will begin establishing a secure connection, utilizing
SSL network protocols, with Capstone Bank’s database and
application server. Upon establishing an SSL secure
connection with Capstone Bank’s database and application
servers, all information passed between the CMBA and
Capstone Bank, during the session, will remain under the
protection and encryption of the SSL connection.
NFSF3001: Prevention of
Simultaneous Logins
The CMBA Prevention of Simultaneous Login feature will
verify and confirm that only one instance of the user’s main
login information is accountable and logged in at a time.
Essentially, when logging into the CMBA or Capstone Bank’s
website, the Prevention of Simultaneous Login feature will
notify the user if his or her login credentials are in use on
another device or portal, such as the Capstone Bank website
and the CMBA. In the event that the user’s login credentials
are in use within another portal, both CMBA and the Capstone
Bank web portal will issue a notification prompting the user to
select an option. The options are to remain logged in on the
other portal or remotely log out of the other portal and log in
from the corresponding CMBA or Capstone Bank website. By
ensuring only one instance of login credentials are in use at a
time, Capstone Bank will provide the user with security and
peace of mind in knowing that their account cannot be
accessible simultaneously in more than one portal at a time.
NFSF3003: Application
Loading
The Application Loading non-functional requirement will
ensure the performance of the CMBA is optimal and congruent
with industry related parameters. Essentially, the Application
Loading non-functional requirement will ensure the CMBA
loads within a reasonable amount of time, such as within 3 to 5
seconds upon deployment.
NFSF3004: Refresh Rate The Refresh Rate non-functional requirement will ensure that
the CMBA’s performance is optimal and congruent with
industry related parameters. Essentially, the Refresh Rate non-
functional requirement will ensure the CMBA refreshes the
information, when account transactions require an update, in a

timely manner, such as the CBMA shall refresh the account
information, after a transaction, within 10 to 30 seconds.
NFSF3005: System Lock Out The System Lock Out non-functional requirement will ensure
the system locks the account after several failed attempts to
enter the correct login credentials. Essentially, the System
Lock Out feature and requirement will ensure the system locks
the CMBA out from entering additional attempts after the 5th
failed attempt. By locking the system out, this security feature
will safeguard the user and Capstone Bank against potential
hackers and unauthorized users. Once the system locks a user
out, the CMBA will be inaccessible for 30 minutes or
authorization from Capstone Bank’s system administrators.
NFSF3006: System Time Out The System Time Out requirement and feature will ensure that
the CMBA automatically severs and terminates the secure
connection, notifies the user that due to inactivity the mobile
banking application will close, and closes the CMBA.
Essentially, the System Time Out feature will initiate after
three minutes of inactivity within the CMBA. After three
minutes of inactivity, the CMBA will begin the termination
procedure. By implementing a time out feature into the
CMBA, customers will have the peace of mind in knowing that
their account information will be safe from accidental access
from unauthorized users.
 Major Issues to Consider
In light of the fact that Capstone Bank has a legacy system in place, and the CMBA will
be an added service, there are several issues to consider. One issue Capstone Bank will need to
consider is the possibility that the legacy system will not have sufficient technology to manage,
control, process, and interface with modern mobile technology. Another issue Capstone Bank
will need to consider is how the legacy system will interact and function with the influx of
activity. For instance, since Capstone Bank has an existing website that offers banking from the
internet enabled and accessible devices, add the CMBA will increase traffic and access to
Capstone Bank’s internal database and application servers. Furthermore, in light of the fact that
Capstone Bank offers internet banking, adding mobile banking could pose the issue of

inconsistencies with data conversions, account information, transactions, and the ability to link
accounts.
Aside from performance issues and continuity between the mobile banking application
and the internet banking solution, another issue arises that Capstone Bank must consider is
security related. Essentially, with the addition of mobile banking services, Capstone Bank must
be aware that their legacy system will have additional points of entry and access into the legacy
system. Essentially, aside from the increase of traffic, which could result in denial of service,
Capstone Bank must consider the possibility of their legacy system experiencing a breach from
mobile devices. In addition, Capstone Bank must consider the possibility that the system may
prevent a transaction to process from one medium and not the other, resulting in fraudulent
activity. For example, if a user’s account has insufficient funds to perform a balance transfer, but
one medium or another does not recognize this deficiency, and performs the transfer, the
erroneous transaction could result in undesirable consequences for the user and Capstone Bank.
Lastly, another issue that could arise with the development of the CMBA is the issue of
unauthorized access. While the mobile banking application utilizes the same login credentials as
the web-based banking solution, Capstone Bank must consider the possibility of users storing
their login credentials on their mobile smartphone, and if stolen or lost, could result in
unauthorized access to the owner’s account information and funds. Subsequently, attempting to
prove or disprove such actions could be costly and detrimental for Capstone Bank or the account
owner.
Aside from performance and continuity issues, concerning development and
implementation of the CMBA, Capstone Bank’s CMBA development project is equally
susceptible to issues. For instance, Capstone Bank must consider and prepare for a lengthy

project that could cost more than the allocated budget. Specifically, in the event that Capstone
Bank continually alters the requirements or makes significant changes to the legacy system
during development of the CMBA, the CMBA project could result in negative consequences that
would require additional time, additional resources, and additional funds to compensate for the
changes or upgrades made to the legacy system. Furthermore, Capstone Bank faces another issue
when outsourcing the development of the CMBA, failure to complete the project. Even though
CMBA researched and hired a reputable software engineering organization, respective software
engineering organization could suffer from internal issues that would cause the project to fail,
such as incompetency, under allocated staff, inexperienced project managers, or the project
teams’ failure to adopt and commit to the project or the project’s software development life cycle
(SDLC) methodology. Moreover, the software engineering organization could fail to budget the
project’s schedule and budget inaccurately, which would result in failure to complete the project
or require additional funds to see the project come to fruition. Lastly, the CMBA development
project could suffer from unclear requirements that result in a program that does not meet
Capstone Bank’s initial business needs or actual requirements.

II. Development Methodology – Phase 1
Recently, AJAR Engineering entered contract negations with Capstone Bank to develop a
mobile banking solution, Capstone Mobile Banking Application (CMBA), which would extend
the existing services of Capstone Bank. Once AJAR Engineering and Capstone Bank agree upon
and establish a formal contract, AJAR Engineering must begin their project planning process.
Initially, before project development and planning can progress, AJAR Engineering must
research and select an appropriate Software Development Life Cycle (SDLC) Methodology to
govern and guide the project. Accordingly, after considerable deliberations, AJAR Engineering
concludes that the Scrum Methodology is the most appropriate approach to developing the
CMBA.
The Scrum Methodology is an Agile project management framework designed to assist in
completing complex projects through managing processes. Essentially, the Scrum Methodology
adheres to the agile software methodology manifesto in that, Scrum places emphasis on
communication and collaboration between stakeholders and the development team over focusing
on contract negotiations, software development processes, and software development tools.
Additionally, Scrum adheres to the concepts of concentrating upon developing functioning
software instead of relying heavily upon extensive and comprehensive documentation. Lastly,
Scrum Methodology aligns with the agile methodology’s approach of remaining flexible and
adapting to emerging business realities as they emerge, instead of adhering to a strict and
uncompromising software engineering approach (“Scrum Methodology”, 2014; Rouse, 2014).
Principally, specialized for software development projects, the Scrum Methodology is an
iterative and incremental approach to software development that focuses on team collaboration,
creativity, and short stints of development processes, also known as Sprints. Fundamentally,

Scrum bases development on capitalizing on small teams that collaborate in an intensive and
interdependent manner to achieve accomplishment of a project (Rouse, 2014).
Principally, a project implemented with Scrum principles and processes will function and
evolve through guidance and participation of three major roles. Scrum’s approach of employing
only three major roles is an attempt to capitalize upon flexibility and creativity. Essentially, the
three major roles within Scrum are Product Owner, Scrum Master, and the Scrum team.
Fundamentally, the Product Owner is responsible for facilitating communications between client
and software development team or the Scrum team. In addition to facilitating communication
between the client and the Scrum team, the Product Owner is responsible for ensuring that the
Scrum team realizes and maintains the product’s vision throughout the project by conveying the
client’s interest, software and business requirements, and levels of appropriate priority. While
other software development methodologies bestow the most authority to the project manager,
Scrum imparts the majority of authority upon the Product Owner. Therefore, in the event that the
project becomes awry, it is the Product Owner’s sole responsibility to devise, formulate, and
integrate a corrective course of action to resolve the project’s obliqueness (“Scrum
Methodology”, 2014).
The next major role within the Scrum Methodology is the Scrum Master. The Scrum
Master’s function is to act as a facilitator between the Product Owner and the Scrum team. While
the Scrum Master is an active facilitator between the Product Owner and the Scrum team, the
Scrum Master is not responsible for managing the Scrum team. Alternatively, the Scrum Master
is responsible for resolving or removing any obstacle that may impede the progress of the Scrum
team or accomplishing the current sprint’s objective. Essentially, the Scrum Master is
responsible for ensuring that the Scrum team has all the necessary components to generate and

nourish creativity, efficiency, and productivity throughout each project sprint. Additionally, the
Scrum Master must ensure that the project progresses successfully so that each sprint’s
accomplishments are visible and capable of placating the Product Owner. While the Scrum
Master is responsible for the success of each sprint, the Scrum Master also acts as an advisor to
the Product Owner. Generally, as an advisor, the Scrum Master has the opportunity to advise the
Product Owner with methods and approaches to maximize their return on investment (ROI) for
the entire project, as well as the project team (“Scrum Methodology”, 2014).
The last of the three major roles within the Scrum Methodology is the Scrum team
members. Principally, the Scrum team consists of a small number of cross-functional team
members that are capable of completing the predetermined work. Fundamentally, the cross-
functional team members should include a combination of software engineers, software
architects, software programmers, software analysts, software testers, software quality-assurance
experts, and software user-interface designers. Dissimilar from most conventional SLDC
Models, Scrum encourages the Scrum team to collaborate and determine how they will
accomplish each sprint. While providing the Scrum team with liberties and autonomy to manage
their own progression and approach to accomplish the sprint’s tasks, the Scrum team must also
be willing to accept the responsibilities of project failure or sprints gone awry (“Scrum
Methodology”, 2014).
Vitally, Scrum’s objectives are to increase and improve the software engineering teams’
efficiency by reducing the amount of processes and documentation required to complete the
project or produce a project’s iteration deliverable. As a result, Scrum’s approach to reduce the
amount of engineering processes and documentation relies upon Scrum’s nature of incorporating
a dynamic and living backlog of predetermined prioritized work. Furthermore, Scrum

concentrates on accomplishing conclusion of fixed sets of backlog of work items, rather
expediently, through short iterations, known as sprints. Generally, sprints are short iterations of
development that last from one week up to four weeks and produces work that is potentially
deliverable, such as implementation ready, marketable, or complete to the point of a working
demonstration. Accordingly, Scrum’s sprint deliverables are smaller portions of the whole
product and allows the team to build upon each portion throughout the project’s progression. In
lieu of extensive documentation, documented communication, or extensive electronic
correspondence, Scrum chooses to communicate directly with the team and stakeholders through
brief daily meetings, known as a scrum or scrum session. During scrum sessions, the Scrum
Master delineates the project’s progress, the Scrum team deliberates over the upcoming work and
descriptively explains the next sprint’s approach, and the Scrum Master and Scrum team
considers any project risks or obstacles that may impede the progress and objective of the next
sprint. Furthermore, the scrum session allows the Scrum Master and the Scrum team to expose
project risks and provides an opportunity for the risk mitigation management plan to receive due
diligence so that the next sprint progresses efficiently from lessons learned. In conjunction with
weekly scrum sessions, the Scrum Methodology exploits proactive approaches of suggesting
orchestration and incorporating opportunities to conduct planning sessions. During the planning
sessions, the Scrum team would organize and define the backlog of work items that would
become the focus for the next sprint. Lastly, similar to most SDLC Models, the Scrum
Methodology considers and benefits from conducting retrospective meetings after each sprint, in
which the engineering team would reflect upon the previous sprint and determine corrective or
alternative solutions to enrich and fortify the next sprint (“Software Development
Methodologies”, 2014).

 Justification
AJAR Engineering ascertains that the Scrum Methodology is suitable for the CMBA
development project for the following justifications:
 Scrum provides better opportunities for AJAR Engineering to gain more clear definitions and
understanding of the requirements through open and frequent communication with Capstone
Bank, which ensures the client and stakeholder’s desires come to fruition
 Scrum is a cultural improvement in that Scrum advocates and promotes creativity,
collaboration, and communication among the AJAR Engineering’s project team, which
increases productivity and promotes quality
 Scrum eliminates the feel of a dictatorship and empowers the AJAR Engineering project
team with control of the project, which increases job satisfaction
 Scrum provides AJAR Engineering with opportunities to improve the processes and product
through lessons learned
 Scrum’s focus of open and frequent communication provides AJAR Engineering with better
opportunities to develop exactly what Capstone Bank needs and a product that will suit
Capstone Bank’s business requirements
 Scrum capitalizes upon Capstone Bank’s feedback to ensure the product is within
specifications
 Scrum’s iterative and incremental approach ensures that Capstone Bank has a working
deliverable after each sprint, which engages and satisfies Capstone Bank’s apprehensions, as
well as provides ample opportunity for feedback to enhance the next iteration’s deliverable
 Scrum’s backlog of work items facilitates AJAR Engineering in realizing the required work
and work schedule (“Features of Scrum”, 2014)

III. Requirements – Phase 2
With intentions of eliciting requirements, for the CBMA, from Capstone Bank, AJAR
Engineering will develop a specific requirements elicitation strategy. Accordingly, AJAR
Engineering’s requirements elicitation strategy will be a hybrid approach that consists of two
distinct formats, brainstorming sessions and informal interviews. Initially, AJAR Engineer will
assemble a team of qualified Business Analysts, Software Engineers, and System Analysts. Next,
the requirements team will meet with Capstone Bank’s key stakeholders to conduct a
brainstorming session. Essentially, the brainstorming session will be informal, relaxed, and
include a catered lunch. By providing an informal and relaxed atmosphere, AJAR Engineering
aspires to encourage creativity and free-flowing communication. During the brainstorming
session the requirements team will ask specific questions to provide Capstone Bank’s key
stakeholders with an opportunity to, freely, express their interpretation of what the CMBA needs
to feature so that the CMBA satisfies Capstone Bank’s business need. As the questions and
solutions evolve throughout the brainstorming session, the requirements team will note and
document the proposed solutions as they become final (Wiegers & Beatty, 2013, p. 48).
Once the brainstorming session concludes and all the elicited requirements documented,
AJAR Engineering will begin to storyboard the requirements to ensure AJAR Engineering has
significant information and requirements. After AJAR Engineering storyboards the requirements
and establishes a formal foundation for designing the CMBA, AJAR Engineering will create
Unified Modeling Language (UML) Use Case diagrams to present and verify the requirements
with Capstone Bank through informal interviews. Essentially, conducted informal interviews will
further clarify, expose, and identify issues with the requirements or provide Capstone Bank with
an opportunity to deliver or specify additional requirements. Principally, the informal interviews

will be intimate in nature. Specifically, the conducted informal interviews will transpire as AJAR
Engineering’s Business Analysts prepare a list of specific questions, meet with the key
stakeholders on a personal level, and discuss the requirements one-on-one. During the informal
interview, the Business Analyst will read from a list of predetermined open-ended questions
regarding the previously established requirements to gain additional clarity and understanding of
the client’s needs. As the stakeholder exposes the details of the requirements, the Business
Analyst will document the new information, take notes of the stakeholders’ body language and
reaction to the questions, and document any new information exposed. By conducting face-to-
face intimate interviews, AJAR Engineering aspires to establish a better rapport with Capstone
Bank and engage the client on a personal level so that the key stakeholders feel involved with the
project (Wiegers & Beatty, 2013, p. 48; Famuyide, 2013).
After conducting both the brainstorming requirements elicitation meeting and the
informal requirements elicitation interviews, AJAR Engineering and Capstone Bank determines
and establishes the following functional and non-functional requirements:

 Requirements Table
Requirement/Featu
re
Functional/
Non-
Functional
Category
Description Success Criteria Priority
1. FSF001: Login Functional The CBMA Login feature will
provide users with opportunities
to enter their associated
Capstone Bank web banking
account credentials to access
their Capstone Bank account
from their mobile smart device.
The Login screen will appear,
complete with text fields for
entering both username and
password.
Very High – Users
will require use of
this feature for each
session.
2. FSF002: View
Balances
Functional The CBMA View Balances
feature will be an option that
will allow the user to view their
Capstone Bank current
account(s) balance(s) after
successfully logging in to the
CBMA Portal.
After logging in, a menu screen
will appear, presenting the
option to view balances. The
success criteria for the View
Balances feature will be, the
CBMA will present and display
the current balance(s) for the
selected account(s)
Medium – Users will
only select this
feature when they
want to view
balances.
3. FSF003:
Transfer Funds
Functional The CBMA Transfer Funds
feature will be an option that
will provide account holders
with opportunities to transfer
funds between their associated
and linked Capstone Bank
accounts.
option to Transfer Funds. The
success criteria for the Transfer
Funds feature will focus on the
ability to transfer of funds from
one CBMA account to another,
add and subtract accordingly,
update accounts, and present
confirmation to the user.
Medium – Users will
only select to use this
feature when they
want to transfer
funds.
4. FSF004: Make Functional The CBMA Make After logging in, a menu screen Medium – Users will

Photographed
Deposits
Photographed Deposits feature
will provide account holders
with opportunities to deposit
checks into their account by
photographing and submitting
images of both front and back
of the intended check.
option to Make Photograph
Deposits. The Success criteria
for this feature will revolve
around the ability to trigger the
camera, capture images, add the
deposit amount to the current
balance, update the account, and
present confirmation to the user.
only select this option
when they wish to
make a photograph
deposit.
5. FSF005: Link
Accounts
Functional The CBMA Link Accounts
feature will provide account
holders with opportunities to
link several Capstone Bank
accounts and account types to
one main account and one set of
login credentials.
option to Link Accounts. The
success criteria of this feature
will revolve around the ability to
associate multiple accounts to
one set of user login credentials
and the main account.
Low – Users will only
select this option
when they wish to
link multiple unlinked
Capstone Bank
accounts to one set of
user login credentials.
6. FSF006: View
Financial
Statements
Functional The CBMA View Financial
Statements feature will provide
account holders with
opportunities to view an
account’s historical
information, up to three months
from the inquiry date, such as
deposits, debits, transfers, and
service fees.
option to View Financial
Statements. The success criteria
for this feature will revolve
around the ability to locate the
requested account, retrieve three
months of transactional
information, and display the
information on the user’s mobile
smart device via the CBMA.
Low – Users will only
select this option
when they wish to
confirm or view their
account’s
transactional
information.
7. NFSF3000:
Secure
Connection and
Encrypted Data
Transfers
Non-
Functional
The CBMA will feature and
provide SSL secure connections
and data encryption throughout
each session.
The success criteria for this non-
functional feature will revolve
around the ability to establish
and maintain the Secure
Connection and Data Encryption
Very High – The
system will require
secure connections
and encryption for
and throughout each

throughout. To verify the
CBMA has established a secure
connection and is encrypting
data, the CBMA will display an
icon, a shape of a shield, on each
screen, from the login screen to
each subsequent screen.
session.
8. NFSF3001:
Prevention of
Simultaneous
Logins
Non-
Functional
The CBMA will feature
Prevention of Simultaneous
Login to verify and confirm that
only one instance of the user’s
account credentials are
accountable and logged into the
system at a time.
around the system’s ability to
confirm and verify that the
user’s login credentials are not
in use through another portal. If
the user’s credentials are in use
on another login portal, the
system will notify the user that
they are logged in elsewhere and
request action, such as log out
from the other location and log
in from the current location.
High – The system
will verify that the
user’s login
credentials only
appear once,
signifying an
established log in, in
the system at a time,
at the beginning of
each session.
9. NFSF3003:
Application
Loading
Non-
Functional
The Application Loading non-
functional requirement will
ensure the performance of the
CMBA is optimal and
congruent with industry related
parameters.
load the mobile banking
application within 3 to 5 seconds
from deployment.
High – The system
will verify that the
application loads
within the specified
time range at the
beginning of each
session.
10.NFSF3004:
Refresh Rate
Non-
Functional
The Refresh Rate non-
ensure that the CMBA’s
performance is optimal and
congruent with industry related
parameters.
refresh the account with updated
information, after each
transaction, within 10 to 30
High– This non-
functional feature will
transpire with each
instance of a
transaction, such as
transfer funds, make

seconds of the transaction. deposits, and link
accounts.
11.NFSF3005:
System Lock Out
Non-
Functional
The System Lock Out non-
ensure the system locks the
account after several failed
attempts to enter the correct
login credentials.
lock the system after 5 failed
attempts to enter the correct
login credentials. Once the
system locks a user out, the
CMBA will be inaccessible for
30 minutes or authorization from
Capstone Bank’s system
administrators.
Very High – This
non-functional feature
will be active for each
instance of logging
into the system.
12.NFSF3006:
System Time Out
Non-
Functional
The System Time Out
requirement and feature will
ensure that the CMBA
automatically severs and
terminates the secure
connection, notifies the user
that due to inactivity the mobile
banking application will close,
and closes the CMBA.
detect inactivity of 3 minutes,
notify the user of inactivity,
terminate and sever the secure
connection, and close the
CMBA.
High – This non-
functional feature will
be active for each
instance of the system
being active, logged
on, and connected to
Capstone Bank.

IV. Design – Phase 2
 Smartphone Architecture
The CMBA will be a new add-on service to Capstone Bank’s existing web based service,
legacy in-house system, and current network infrastructure. Since the CMBA will be a new add-
on service, the CMBA will rely upon Capstone Bank’s legacy system of database servers,
webservers, and application servers to communicate with Capstone Bank, retrieve information,
perform transactions, and update account information. Initially, the Samsung Galaxy S4 mobile
smart phone will be the piloting device for the CMBA, which will include initial design,
deployment, and testing. The Samsung Galaxy S4 specifications are as follows:
 Operates on the Android operating system
 Current version: Jelly Bean 4.2.2
 1.9 Gigahertz (GHz) Quad-core processor
 5-inch full high-definition (HD) super Active Matrix Organic Light-Emitting Diode
(AMOLED) touch screen display
 Offered in 16, 32, and 64 gigabit (Gb) capacities
 Capable of communicating across second and one half generation (2.5G), third
generation (3G), and fourth generation long-term evolution (4G LTE) mobile networks
 The S4 utilizes two cameras, front-facing camera and a back-facing camera
o S4’s back-facing camera is capable of capturing images up to 13 Mega pixels
o S4’s front-facing camera captures images up to 2 Mega pixels
 Air Gesture and Air View enabled
 Touchscreen interface
 Touchscreen QWERTY Keyboard
 Integrated Microphone and Speakers
 Global Positioning System (GPS) enabled
(“Samsung Galaxy S4”, n.d.)

 Operating Environment and System Architecture
Capstone Bank’s legacy system will consist of a network of distributed systems, which
will consist of the Hewlett-Packard Moonshot Server System. The system’s operating
environments will consist of Hewlett-Packard database servers, Hewlett-Packard webservers,
Hewlett-Packard switches and hubs, Hewlett-Packard application and login servers, and Hewlett-
Packard desktop terminals. Currently, Capstone Bank’s operating system comprises of Red Hat
Enterprise Linux (RHEL) Release 19, which seamlessly interfaces and communicates with
Capstone Bank’s Hewlett-Packard servers. Capstone Bank’s database servers utilize Microsoft’s
Structured Query Language (SQL) Server 2008-R2 database software application to store data,
perform various procedures, and maintain account information. In order to maintain secured
sessions and data encryption, Capstone Bank will employ SSL network protocols. Accordingly,
the Hewlett-Packard Moonshot Server System’s specifications are as follows:
 HP Moonshot Chassis (per chassis)
o Supports shared power, cooling, management, and fabric for 45 individual hot-
plugged server cartridges
 HP ProLiant m300 Server Cartridges (per cartridge)
o Dynamic content delivery of Web Services
o Intel Atom C2750 Processor
o Integrated Security Operations Center (SOC)
o 32Gb of RAM per node
o 1terabyte (TB) Serial Advanced Technology Attachment (SATA) Hard disk drive
(HDD)
o Controllers Embedded in SOC
o Operating System - RHEL
 HP ProLiant m700 Server Cartridge (per cartridge)
o Hosted Desktop and Mobile Infrastructure
o 4 x Advanced Micro Device (AMD) Opteron X2150 Accelerated Processing Unit
(APU)
o 8Gb of RAM per node
o 32Gb per APU
o SOC Embedded Controllers

o Operating System – RHEL
o Database server software – Microsoft SQL Server 2008 R-2
 HP Moonshot - 6SFP Uplink Module
o 1Gb Ethernet
o Low-latency
o 6 – 10 Gigabit Ethernet (GbE) Small Form-Factor Pluggable Transceiver Module
Plus (SFPTM+) uplink ports
o 45 1GbE downlink ports
 HP Moonshot – 45G Switches
o 1Gb Ethernet
o Low-latency
o 180 – 1GbE downlink ports
o 4 – 40GbE Quad Small Form-Factor Pluggable Plus (QSFP+) uplink ports
(“HP Moonshot System”, 2014; Lohrey, 2011; “FAQs for QSFP+”, 2014)
 Application Specifications and Architecture
o Programming for the CMBA will consist of Java’s version 7.0 programming
language coding conventions and syntax protocols
o Programming for the CMBA will be RHEL compliant
o Programming for the CMBA will be Microsoft SQL compliant and use SQL Data
Manipulation Language (DML) and Data Definition Language (DDL) commands
to interface with Capstone Bank’s database servers.
o Data transmission will transpire through Capstone Bank’s current web services
o Utilizing DML and DDL commands, Capstone Bank’s predetermined User
Defined Functions and stored procedures will be able to perform the following
actions and duties:
 Verify login credentials
 Verify account
 Locate account
 Retrieve account information
 Transmit account information
 Perform fund transfers
 Update account information
 Add and subtract funds
 Verify photographed images of checks to perform photograph deposits
 View balances
 Retrieve historical information for Financial Statements

 Issue error and confirmation messages
 Link accounts
 Monitor inactivity and terminate the connection after three minutes of
inactivity
The CMBA will consist of six main components, Login, View Balances, Transfer Funds,
Photograph Deposits, Link Accounts, and View Financial Statements. While the CMBA has six
main components, not all components will require existence or deployment of another
component. For example, the Link Accounts component will not require activation or use of the
View Balances component. However, all components will require activation and access to the
Login component before operating. Overall, the normal progression of the CMBA will flow as
such:
a. User locates and deploys the CMBA
b. Upon deployment, the CMBA begins to establish a secure connection with Capstone
Bank
c. Once a secure connection is established, the CMBA presents the Login screen to the
user
d. User enters the correct login credentials and submits them for verification
e. Upon verification, from Capstone Bank’s database server, the CMBA displays a
menu of options, which includes the five remaining components/features
f. From the menu of options, the user selects a component/feature, such as View
Balances. The CMBA then sends a request to Capstone Bank to query the database
for the corresponding account balance
g. After the user verifies the account balance, the user returns to the menu screen to
select another option or log off the system

 Use Case Diagram

Sample: detailed view for the Make Photographed Deposit Use Case and corresponding Use
Case Scenario:
Use Case ID: UCS4
Use Case
Name:
Make Photographed Deposit
Created By: Jim Richardson Last Updated By: Jim Richardson
Date Created: November 30, 2014 Date Last
Updated:
November 30, 2014
Actors: Customer, Samsung Galaxy S4, and Capstone Bank’s server system (includes:
webserver, database server, application server, and network server)
Description: The Make Photographed Deposit feature provides customers with
opportunities to make deposits from their mobile smart device by capturing
images of the check and sending them, wirelessly, to Capstone Bank’s sever
system.
Trigger: Customer clicks on the Make Photograph Deposit option from CMBA’s main
menu
Preconditions: 1. The user must have the CMBA installed on their mobile smart device
2. The user must have a qualifying Capstone Bank account
3. The user must have login credentials
4. The user must have a camera enabled mobile smart device
5. The user must have a qualifying check to deposit
6. The user must sign the check appropriately
7. The user’s mobile smart device must have sufficient network connection
to transmit images

8. Capstone Bank must be able to receive transmitted images
9. Capstone Bank must be able to verify images
10. Capstone Bank must be able to perform deposits
11. Capstone Bank must be able to update accounts
Postconditions: 1. Capstone Bank receives the transmitted images
2. Capstone Bank verifies the images
3. Capstone Bank performs the deposit
4. Capstone Bank updates the account
Normal Flow: 1. The user clicks on the CMBA
2. The CMBA and Capstone Bank’s server systems establish a secure
connection
3. The user enters their corresponding Capstone Bank login credentials
4. The user submits the login credentials
5. Capstone Bank confirms the login credentials
6. Capstone Bank locates the corresponding account information
7. The CMBA presents a menu screen
8. The user selects the option to make a photographed deposit
9. The CMBA responds by enabling the mobile smart device’s camera
10. The user captures the appropriate images
11. The CMBA prompts the user to transmit the images
12. The user elects to transmit the images
13. The CMBA transmits the images to Capstone Bank
14. Capstone Bank’s server system receives the images
15. Capstone Bank’s server systems verify authenticity of the images
16. Capstone Bank’s server systems locates the appropriate account
17. Capstone Bank’s server systems retrieves the corresponding account
18. Capstone Bank’s server systems performs the deposit
19. Capstone Bank’s server system updates the account to reflect the deposit
20. Capstone Bank’s server system issues confirmation
21. The CMBA receives confirmation
22. The CMBA displays the confirmation and updated account balance
reflecting the deposit
Alternate Flow: 1. User clicks on mobile banking application
2. A secured session fails to establish
3. User enters invalid login credentials
4. Database is unable to confirm or verify the login credentials
5. Database fails to retrieve customers’ account
6. Menu screen does not display
7. User submits an unacceptable photograph(s)
8. Check is not properly endorsed
9. The secured session terminates during the process
Exceptions: Capstone Bank’s system administrators will have liberties of overriding the
system and performing manual deposits. Capstone Bank’s server systems will
be inaccessible during routine maintenance.

 Class Diagram

 Component Diagram
 Visual User Interface Design
Figure 1: CMBA Login Screen

Figure 2: CMBA Main Menu
Figure 3: CMBA View Balances Screen

V. Development – Phase 3
When developing software products or applications such as the Capstone Mobile
Banking Application (CMBA), using the Scrum Methodology, development processes progress
as sprints. Sprints, by Scrum definition, are repeatable work cycles that transpires throughout a
specific amount of time, such as one-week, two-weeks, three-weeks, and a month. Generally, the
team decides the length of the sprint for each iteration of the project. Typically, scrum teams
favor shorter sprints, but depending on the project’s nature, the scrum team may opt for longer
sprint cycles. Nonetheless, during each sprint, the scrum team will create a shippable product.
According to the project, these shippable products may be basic in nature or can be fully
functioning portions of the product. However, due to limited timeframes, iteration release
products focus on essential functionality. Essentially, the scrum team places emphasis on using
code that works (“Scrum Sprint”, 2013).
To ensure the scrum team has a specific agenda and realizes which portion of the product
to code during each sprint, the Product Owner prioritizes the product’s most essential features
and backlogs them accordingly as upcoming milestones to attain. When the team produces a
successful version of the product, from the prioritized backlog, the team then moves forward
with the project and builds upon the previous released version. To ensure the scrum team is
aware of the prioritized backlog of product features, the scrum team begins each sprint session
with a sprint-planning meeting to discuss upcoming sprint’s agenda with the Product Owner.
During these sprint-planning meetings, the scrum team and the Product owner create storyboards
of the planning process to use during the upcoming sprint. Generally, the storyboards contain
four main columns, Release Backlog, Sprint Backlog, Working On section, and Completed Work
(“Scrum Sprint”, 2013: Csaba, 2013).

Generally, the Release Backlog column will contain stories that relate to the current
release and provides the scrum team with a foundation to begin the next sprint. The Release
Backlog also serves as demonstration of milestones met and completed. Next, the Sprint Backlog
column will contain the plan for the upcoming sprint. Typically, for the upcoming sprint, the
scrum team and Product Owner negotiate the needs and wants for this sprint by performing
estimation analysis on the difficulty of items that pertains to the upcoming sprint’s story.
Essentially, the Sprint Backlog items become the new milestones to accomplish. Once negations
are complete, the scrum team begins the coding process to complete the stories in the Sprint
Backlog column. To indicate which portion of the story the team is coding currently, the scrum
team will remove the respective item from the Sprint Backlog column and place it in the
Working On column. By placing or noting the specific item in the Working On column, the
scrum team is demonstrating communication of their progress. As stories come to conclusion,
the respective scrum team moves and denotes the corresponding story in the Completed Work
column (Csaba, 2013).
Before placing an item or story into the Completed Work column, the team must
establish criteria for specific levels of completion, such as the design must be minimalistic, there
should be a mockup or prototype of the user interface, the written code should function properly,
testing should transpire, and functional or acceptance tests must pass. Since Scrum does not
focus on extensive documentation, but instead focuses on stories, which are the proposed
features or functions from the end user’s perspective, to gauge or track the progression of the
project, the scrum team utilizes Tasks or Sub-Stories. Generally, Tasks or Sub-Stories are short
synopses from the developer’s perspective that indicate precisely where their progress lies in
relation to the main user story they are working on. Essentially, these Tasks or Sub-Stories

define the developer’s current task and progress, to which functions as a method to identify and
track milestones (Csaba, 2013).
VI. Testing – Phase 3
AJAR Engineering elects to adopt and adhere to the Scrum Methodology for the
development of Capstone Bank’s Mobile Banking Application. In light of the fact that Scrum
delivers functioning product components at the end of each sprint, testing necessitates
coexistence within the same sprint that originates and creates a working and deliverable
component. Essentially, to ensure the component functions properly, each deliverable unit
requires testing. Therefore, once the initial phase of coding concludes, and before releasing the
product to the stakeholders, each iterative release must endure testing. Furthermore, before each
iterative release is ready for deployment, and after initial testing, the respective tested component
must have ample time to endure modification or adjustments according to the test results before
the sprint expires. However, since AJAR Engineering and the incorporated Scrum Methodology
focuses on compiling with working code and delivering basic functionality, AJAR Engineering
will require a test plan that corresponds with their sprint parameters. Accordingly, AJAR
Engineering’s test plan for each sprint will consist of Black Box Unit Testing, Black Box
Integration Testing, White Box Usability Testing, and Whit Box Automated Regression Testing.
Once the final component is ready for implementation, AJAR Engineering will add Black Box
System Testing to the test plan. By incorporating Black Box System Testing near the end of the
project’s lifecycle, AJAR Engineering will be able to ensure the system functions as completely
integrated units.

Accordingly, AJAR Engineering will use the following test cases for both manual and
automated testing:
 Test Case 1: Login
Test Name: TC1: Login
Description: The login feature will prompt the user to enter their corresponding pre-
established Capstone Bank login credentials. Login credentials will consist of
username and password. For security purposes, upon entry of the user’s
password, the system will mask the user’s password with asterisks to conceal
the text from unauthorized users.
Requirement(s): FSF001: Login
Prerequisites: A database must be in place and the database must have capacities to
interface with the mobile banking application. A webserver and application
server must be in place to communicate with the database and smartphone.
The database must transmit and receive data across an SSL network
connection. The user must be a preexisting customer with Capstone Bank
and have a valid account. The user must have Capstone Bank pre-established
and recognized login credentials to access their Capstone Bank account(s)
information.
Setup: Tester will begin by ensuring installation of the Capstone Mobile Banking
Application (CMBA) is on the testing device, the Samsung Galaxy S4. The
Tester will launch the CMBA to initiate a secured session. All transmitted
data between the smart device, the webserver, the application server, and the
database servers will experience encryption through the SSL connection.
After establishing a secure session between the webserver, application server,
and the database server and the smart device, the login screen appears
prompting the user to enter their associated login credentials. Once the user
enters their corresponding Capstone Bank login credentials, the user/tester
will submit them for verification to access their account. User’s credentials
will be masked, as entered, to maintain security.

TC1: Login Start Time Stop Time Tester:
Step Operator Action Expected Results Observed Results Pass
/
Fail
Severity of
Failure
1. Turn on smart
device
The phone should power up
2. Open Capstone
Mobile Banking
Application by
clicking on the
icon
The icon should be visible and should
initiate connection when clicked by
displaying an hourglass until connection
is established
3. Wait for access The webserver receives the request and
verifies that the application is seeking to
establish a secure session
4. Wait for access The webserver confirms the application
and returns data to display the login
screen as verification that a secure
session is established between the
database and the smart device
5. View Results The login screen should be visible with
prompts for login credentials
6. Enter login
credentials
Text fields will have sample information
displayed, in gray text, so that the user is
aware of what information belongs in the
corresponding login fields. User will
start to enter information, by clicking on
the appropriate field, and the grayed out
text will disappear as the user’s entries

replace the greyed out sample text.
User’s password credentials should be
masked, as entered, to maintain security.
7. Submit login
credentials
The user will enter correct login
credentials and submit for verification.
User’s credentials should be masked, as
entered, to maintain security.
8. Waiting for results The webserver will receive the
information and pass the credentials
along to the database server for
verification.
9. Waiting for results Once the database server receives the
login credentials from the webserver, the
database will attempt to verify
authenticity.
10. Waiting for results Upon verification from the database, the
database will locate and retrieve the
corresponding account information.
Then, the database will issue
confirmation back to the webserver for
transmission back to the mobile smart
device, resulting in; the CMBA will
display the main menu screen.

 Test Case 2: View Financial Statements
Test Name: TC2: View Financial Statements
Description: The View Financial Statements option is part of a menu that appears, as a
result, after entering correct login credentials and receives verification from
the database server. The View Financial Statements option provides the
customer with options to view their account’s transactional history, up to 6
months’ worth of information from the request date, for the selected account.
Requirement(s): FSF006: View Financial Statements
interface with the webserver. The webserver must have capacities to interface
and communicate with the mobile banking application. The webserver must
transmit and receive data across an SSL network connection. The user must
be a preexisting customer with Capstone Bank and have a valid account. The
user must have Capstone Bank pre-established and recognized login
credentials to access their Capstone Bank account(s) information. The user
must have, at least, one valid and open account with transactional history that
is within the 6 month, from the request date, range. The account numbers
will only be displayed as the last four digits of the account.
will be masked, as entered, to maintain security. The database server will
verify the login credentials, locate the corresponding account, and transmit
data back to the mobile application prompting the mobile application to
display the menu screen as verification of successful login and account
verification. The tester will begin by selecting the View Financial Statement
option. Once the user selects the View Financial Statement option, the
CMBA will transmit the request to the webserver. The webserver will
forward the request to the database server. The database will locate and

retrieve the account balance, transactional history, and transmit the data back
to the mobile smart device via the webserver. The mobile smart device will
sustain the SSL connection, receive the data, and display the transaction
history on the screen for verification. The tester will have the ability to view
6 months’ worth of transactions, from the date of inquiry, by scrolling
through the transaction history.

TC2: View Financial
Statements
Start
Time
Stop
Time
Tester:
/
Fail
Severity of
Failure
1. Turn on smart device The phone should power up
2. Open Capstone
Mobile Banking
Application by
clicking on the icon
displaying an hourglass until connection
is established
screen as verification that a secure
session is established between the
database and the smart device
6. Enter login credentials Text fields will have sample information
corresponding login fields. User will
start to enter information, by clicking on
the appropriate field, and the grayed out
text will disappear as the user’s entries
replace the greyed out sample text.
User’s password credentials should be

masked, as entered, to maintain security.
7. Submit login
credentials
information and pass the credentials
along to the database server for
verification.
authenticity.
corresponding account information.
Then, the database will issue
confirmation back to the webserver for
transmission back to the mobile smart
device, resulting in; the CMBA will
display the main menu screen.
11. Selects the View
Financial Statements
option from the menu
From the main menu, the tester will
select the option to View Financial
Statements. Then, the tester will select
which account to view the corresponding
financial statement. The mobile smart
device should send a request to the
database server via the webserver, the

database server should query the
database, through predefined functions
and user defined SQL scripts, and the
database should return the corresponding
6 months’ worth of transaction history to
the CMBA via the webserver. While the
database performs the queries, the
hourglass should reappear, signifying a
transaction is in progress
12. Waiting for results While the database server locates the
account and performs the queries,
through predefined functions and user
defined SQL scripts, the hourglass
reappears indicating the process is in
progress
13. Waiting for results Once the database server locates and
retrieves the corresponding account’s
financial statement, the database server
will transmit the financial statement, via
the webserver, back to the CMBA for
display
14. View Financial
Statement
Once the CMBA receives the data, the
CMBA will display the corresponding
account’s financial statement for review.

 Test Case 3: Transfer Funds
Test Name: TC3: Transfer Funds
Description: The Transfer Funds option is part of a menu that appears, as a result, after
entering correct login credentials and receives verification from the database
server via the webserver. The Transfer Funds option provides the customer
with options to transfer funds between linked accounts, such as from
checking to saving or vice versa.
Requirement(s): FSF003: Transfer Funds
interface with the webserver. The webserver must have capacities to interface
and communicate with the mobile banking application. The webserver must
transmit and receive data across an SSL network connection. The user must
be a preexisting customer with Capstone Bank and have, at least, two valid
accounts. The user must have Capstone Bank pre-established and recognized
login credentials to access their Capstone Bank account(s) information. The
user must have, at least, two valid and open accounts with sufficient funds to
transfer. The transfer amount must not exceed the sending account’s current
balance. The account numbers will only be displayed as the last four digits of
the account.
will be masked, as entered, to maintain security. The database server will
verify the login credentials, locate the corresponding account, and transmit
data back to the mobile application prompting the mobile application to
display the menu screen as verification of successful login and account
verification. The tester will begin by selecting the Transfer Funds option. The
database will locate and retrieve all available account balances and transmit
the data back to the mobile smart device. The mobile smart device will

sustain the SSL connection, receive the data, and display the account
balances on the CMBA screen for verification. The CMBA will then offer
the option to transfer funds between available accounts. The tester will enter
a transfer amount, which does not exceed the current balance, from the
transferring account and select the sending from and receiving accounts.
There will be two open, valid, and available test accounts with test data to
conduct the transfer, checking and saving. The current balance will be
$123.45 in the checking account and $67.89 in the saving account.

TC3: Transfer Funds Start
Time
Stop
Time
Tester:
/
Fail
Severity of
Failure
15. Turn on smart device The phone should power up
16. Open Capstone
Mobile Banking
Application by
clicking on the icon
displaying an hourglass until connection is
established
screen as verification that a secure session
is established between the database and
the smart device
20. Enter login credentials Text fields will have sample information
corresponding login fields. User will start
to enter information, by clicking on the
appropriate field, and the grayed out text
will disappear as the user’s entries replace
the greyed out sample text. User’s
password credentials should be masked,

as entered, to maintain security.
21. Submit login
credentials
information and pass the credentials along
to the database server for verification.
authenticity.
corresponding account information. Then,
the database will issue confirmation back
to the webserver for transmission back to
the mobile smart device, resulting in; the
CMBA will display the main menu
screen.
25. Selects Transfer Funds
from the main menu of
options
From the main menu, the tester will select
the option to Transfer Funds. Then, the
tester will select which accounts to
transfer funds between. The mobile smart
device should send a request to the
database server via the webserver, the
database server should query the database,
through predefined functions and user

defined SQL scripts, and the database
should return the corresponding available
accounts, complete with current balances,
back to the CMBA via the webserver.
While the database performs the queries,
the hourglass should reappear, signifying
a transaction is in progress
26. Waiting for results While the database server locates the
account and performs the queries, through
predefined functions and user defined
SQL scripts, the hourglass reappears
indicating the process is in progress
27. Waiting for results Once the database server locates and
retrieves the corresponding available
account’s current balances, the database
server will transmit the balances, via the
webserver, back to the CMBA for display
28. View Financial
Statement
Once the CMBA receives the data, the
CMBA will display the corresponding
account’s current balances for review.
29. Select accounts to
transfer funds between
Once all available account balances are on
display, the CMBA will prompt the user
to select the appropriate accounts to
transfer funds between

30. Select accounts From the list of available accounts, the
user will select the sending account and
the receiving account. Then the CMBA
will prompt the user to enter the transfer
amount. The transfer amount must not
exceed the current sending account’s
current balance. The test data will reflect a
checking account balance of $123.45 and
a saving account balance of $67.89. The
account numbers will only be displayed as
the last four digits of the account number.
31. Transfer Funds The tester will perform the transfer by
submitting the request to Capstone Bank.
The CMBA will send the request to
Capstone Bank’s database server, via the
webserver, to perform the transfer.
According to the test data, the tester will
attempt to transfer $7.11 from the
checking account to the saving account.
The sending account will have a right facing
arrow displayed behind the account balance
and the receiving account will have a left
facing arrow  behind the account balance.
The account numbers should only be
displayed as the last four digits.
32. Submit Transfer Funds
Request
After selecting the sending account, the
receiving account, and entering the
amount to transfer, the tester should see

an hourglass icon, that indicates the
transfer is in progress, after submitting the
transfer funds request
33. Waiting for results The hourglass icon, signifying a
transaction is in progress, should maintain
visible until the transaction is complete.
34. Receive Request The hourglass icon should remain visible
while the transaction is in progress. Once
Capstone Bank’s database server receives
the transfer request, via the webserver, the
database server will activate the
corresponding SQL commands to verify
the transfer.
35. Perform Transfer Once the database confirms the transfer,
the database will perform the transfer,
using SQL commands, by debiting the
transfer amount from the sending account
and crediting the receiving account with
the transfer amount. According to the test
data, the transferred amount of $7.11
should result in the checking account
should have a new balance of $116.34 and
the saving account should have a new
balance of $75.00
36. Update Account Once the database performs the transfer,
the database will update the corresponding

Balances accounts to reflect the transfer. the
checking account should have a new
balance of $116.34 and the saving account
should have a new balance of $75.00
37. Final Transmission Once the database completes the transfer
and account balance updates, the database
will transmit confirmation, via the
webserver, back to the CMBA for display
and review. Once the user/tester finishes
reviewing the transfer confirmation, the
CMBA will provide options to Return to
the main menu or perform another
transfer.
38. View Confirmation A confirmation screen should be visible
with updated account balances. The
checking account should reflect the
transfer with a balance of $116.34 and the
saving account should have a new balance
of $75.00. The account numbers should
only be displayed as the last 4 digits of the
account number.

VII. Project Schedule – Phase 4
For convenience and better organization, the Project Schedule, major milestones for the
project, subsequent detailed tasks, Gantt chart, and Network diagram depicting the critical path
are included in the Microsoft Project Computer Aided Software Engineering (CASE) Tool.
Figure 4: Link to Capstone Bank MS Project File
Jim Richardson
Software Engineering Capstone 1 SWE481 Phase 4 IP.mpp
Generally, all the scheduled times are best-case estimates. In order to ensure true
flexibility of the project, we incorporated float time. Float time, in project management, means
that a task can begin later in the sprint and its lateness will not delay the overall project or
specific sprint (“Leads, Lags and Floats”, 2014). For example, within each sprint, the project
team needs to review specific standards, protocols, and independent plans, such as
communication plans and human resource plan, but those tasks are viewable at any time
throughout the sprint. By incorporating float time, the project team can view the task important
plans, protocols, and standards as they apply to their specific task. If we did not incorporate float
time for these tasks, the project team may forget or omit a critical step later in the sprint.
Therefore, by incorporating float time tasks are more applicable and capable of corresponding to
the current task. Furthermore, by implementing base-case estimates, the schedule has extra time
built in to ensure that float time is achievable. For example, most of the testing tasks, both Black
Box and White Box testing conventions, have a list time of two days. However, due to
automation and reusable test scripts, general testing will not require both days to complete. By

padding the schedule by one day, we are not only capable of floating tasks but also consuming
the extra time for tasks that encounter difficulties that would endanger the overall schedule.
In order to track the progress of each task, the project team will move their story point to
the Completed Work section on the project storyboard. This will not only demonstrate to the
team which tasks are complete, but this convention will also illustrate the percentage of
completion. In addition to moving story points to the Completed Work section, the Scrum Master
will update the MS Project Capstone Bank project file with color-coded schemes. Essentially,
before the project initiates, the entire MS Project, in Gantt chart view, will be in red. After each
task concludes, the Scrum Master will update the file with the following color-coded schema:
 Green = 100% Complete
 Blue = 75% to 99% Complete
 Yellow = 50% to 74% Complete
 Orange = 25% to 49% Complete
 Red = 0% to 24% Complete
In addition to the color-coded schema of designating the percent of completion, the Gantt chart
time line will illustrate the percent complete with the following convention:
Figure 5: Sample screen shot of color-coded schema

As an attempt to verify the completion of tasks, the project team will also utilize Sub-
Stories to confirm that their chosen task is complete. Essentially, Sub-Stories are short synopses,
from the developer’s perspective, that indicate precisely where their progress lies in relation to
the main user story they are working on. Essentially, these Tasks or Sub-Stories define the
developer’s current task and progress, to which functions as a method to identify and track
milestones (Csaba, 2013). Additionally, Project Capstone Bank will utilize metrics, such as the
Release Burn down chart, to depict the progress of each task visually. A Release Burn down
chart is a method that Scrum utilizes to track the progress of a sprint or the project against the
overarching release plan. Essentially, a burn down chart graphically illustrates each sprint or task
and depicts the amount of work remaining to completion. As each task or sprint concludes, the
graph will display a downward connecting plotted line that will correspond with the amount of
days, stories, or tasks left to complete before the project concludes. For example, in Project
Capstone Bank, the estimated time to completion is 73 days. The burn down chart would display
the amount of days on the left as a vertical axis. Then along the bottom, the burn down chart
would display the number of sprints as the horizontal axis. As each sprint concludes, the graph
would display a downward progression until all sprints conclude on the last day (“Release
Burndown Chart”, 2014). To illustrate this further, please review the following graph:
Figure 6: Sample Sprint Burn Down Chart for Capstone Bank

VIII. Risk Analysis – Phase 5
“A project risk is an uncertain event that, if it occurs, will have either a positive or a
negative effect on the prospects of achieving project objects” (“What is a project risk”, n.d.).
Accordingly, an uncertain event is something that may or may not happen but must experience
identification, evaluation, and definition so that the project team may establish a mitigation plan
for preparedness. Positive or negative effects are the result and consequences that ensue if a
project risk comes to fruition. As each project begins and progresses, each project must endure
the process of identifying, evaluating, and defining risks so that the project may experience fewer
obstacles that prohibit the success of the project or the project’s objectives. Essentially, this is a
Risk Management Plan. As defined by the Project Management Institute (PMI), Project Risk
Management is a predetermined set of processes that formulates the orchestration of risk
management planning, risk identification, risk analysis, methods and practices of responding to
risks, and establishes the procedures for monitoring and controlling risks within a project.
Fundamentally, Project Risk Management objects to decrease the probability and reduce the
impact of negative events while aspiring to increase the prospects of capitalizing upon positive
impacts from positive events (PMI, 2009, p. 4). In conjunction with our chosen software
development model, Scrum, project risks remain under the same category and definition.
However, the Risk Management Plan is different from other more traditional software
development models’ Risk Management Plan.
Within the Scrum software develop model, Risk Management is different because Scrum
develops software in Sprints. Therefore, with each sprint, risk management begins anew and
progresses throughout each sprint until the sprint concludes. Each sprint requires its own risk
management plan because the objectives of each sprint may differ from the previous and

subsequent sprint. Nonetheless, the overarching agenda of the Project Risk Management Plan
remains unchanged. Specifically, even in conjunction with the Scrum Model, Risk Management
follows the same set of processes, which are Identify, Assess, Respond, and Review.
Figure 7: Risk Management Processes
(Yegi, 2014)
With the concepts of Risk Management in mind, clarified, and understood, we now begin
to evaluate the project risks for the development of Capstone Bank’s mobile banking application.
Principally, Risk Management will be a collaborative effort of the entire project team, Scrum
Master, and Product Owner. Risk Management will transpire during each session’s pre-sprint
and post-sprint Scrum meetings. Accordingly, the following Risk Identification and Risk
Response matrix will demonstrate and elucidate the risks for Project Capstone Mobil Banking. In
conjunction with the Risk Identification and Response Matrix, we will use the following Risk
Impact Scale and Risk Probability Scale to measure the risks.

 Impact Scale
Consequence Ranking Impact on Project Relocation
Extreme (9 -10) Complete Failure to attain/accomplish project
objectives
High (7-8) Severe extension of the project’s schedule and
budget
Moderate (5-6) Moderate delays, but recoverable, and
moderate costs incurred
Low (3-4) Slight Impact and minimal delay to the
project
Negligible (1-2) Little to No Concern
 Probability Scale
Probability Ranking Probability of Risk Occurrence
Not Probable (NP) 0 - 1% chance of occurring
Low Probability (LP) 2 – 4% chance of occurring
Moderate Probability (MP) 5 – 7% chance of occurring
High Probability (HP) 8 – 10% chance of occurring
Expected (E) >10% chance of occurrence

 Risk Identification and Risk Response Table
Risk Name Risk Description Risk
Potential
Ranking
(1 -10)
Risk
Impact
Ranking
(1-10)
Risk Impact Description Risk
Response
Type
Risk Mitigation Description
1. Users
Resistance to
Change
Users have attachment
to legacy systems,
familiar tools, and
existing software.
Therefore, when
introducing change, it
is possible that
Capstone Bank’s
employees will resist
interfacing with the
new Capstone Mobile
Banking Application,
which could result in
maintaining legacy
solutions or request
changes that would
result in a subpar
system.
8 10 If end users refuse to interact or
accept the new changes of the
software structure of Capstone
Bank, they could influence the
stakeholders into requesting
changes to the User Interface or
other components of the
system. Introducing too many
changes would have a negative
impact on the project’s
schedule and budget.
Furthermore, if the project team
continuously accepts and
implements the changes, the
new changes could hinder the
performance of the system,
resulting in customer
dissatisfaction.
Accept We will accept and implement a
certain degree or amount of
changes to ensure the users are
willing to accept and embrace the
change. However, we will
implement cut-off dates for
change requests and implement
subsequent changes, as necessary,
in subsequent Sprints. In order to
ensure users accept and embrace
changes further, we will highlight
the strengths of the new system
and promote the advantages of
adopting the new system.
Additionally, we will conduct
User Training to ensure Capstone
Bank is more susceptible to
accepting change.
2. User’s Lack of
Commitment
If user’s do not
commit to the project
and participate
actively, the project’s
details, business and
software requirements,
functionality, and
overall design could
be “left up to
interpretation”, to
which would result in
building the wrong
product or a product
that was subpar to the
original business
8 10 If the user’s do not commit or
actively participate in the
requirements elicitation
process, during the system
design process, and during the
system development process,
the project team could assume
the client’s needs and interpret
them incorrectly, to which
would result in a system that
does not meet the user’s
expectations and business
needs. Therefore, if we build a
system that does not meet the
client’s desires and business
Avoid To ensure User Commitment, the
project team proposes stakeholder
involvement through continuous
communication, such as email
correspondence, weekly updates,
and conferences. By engaging in
frequent contact and
communication, we anticipate
that communication will alleviate
anxieties and increase users’
commitment to the project.

needs needs, our efforts would be a
waste time, resources, and
money, resulting in customer
dissatisfaction and a product
that is unusable. Ultimately, we
could lose money by rebuilding
the software system and
assuming all the new costs in
attempts to preserve vendor-
client relations and our
reputation as a software
development organization
3. Lack of User
Cooperation
Similar to Lack of
User’s Commitment,
Lack of User
Cooperation could
lead to misinterpreting
the requirements, lack
of disclosed
requirements, and
ultimately end in
project abandonment
8 10 Lack of User Cooperation will
lead to project failure because
the software designers could
misinterpret the requirements,
functionality, and business
needs of the system, resulting
in loss of business, time,
money, and reputation as a
reputable software engineering
firm. Furthermore, Lack of
User Cooperation could result
in a product that presents
security hazards to Capstone
Bank, to which would endanger
the financial institution,
customers, and our software
engineering firm as law suits
ensue.
Avoid In conjunction with frequent
communication, we will include
the client (end User) in decision
making, such as eliciting
requirements through
brainstorming sessions. The
brainstorming sessions will be
informal, will include catered
meals, and will include door
prizes. By catering meals and
offering door prizes, we
anticipate that hospitality will
triumph and gain cooperation
from the client. Furthermore, we
will encourage, advocate User
Cooperation by promoting, and
rewarding creativity through
monthly prize giveaways that will
include free lunches/dinners for
two, free movie vouchers, and
gift certificates. The monthly
prizes will consist of the top two
contributors drawn from a list of
all the contributors, in raffle
format.
4. Unclear System
Requirements
If we do not elicit
the requirements
8 9 Unclear System Requirements
could lead to building an
Avoid In order to gain full awareness of
the System Requirements, we

properly, we could
develop wrong
functionalities,
wrong user
interfaces, and
wrong business
applicable
systems. It is
essential that all
requirements are
concise, clear, and
detailed so that the
correct system
materializes.
ineffective product, a product
that is susceptible to security
breaches, a product that does
not meet the client’s business
needs, and/or a product that
does not work. Resultantly, we
would consume the loss of
time, spent resources, and
misallocated funds, to which
would result in unfavorable
consequences, such as
bankruptcy, loss of employees,
and loss of reputation and
business relations.
will conduct brainstorming
sessions with the client/users. In
addition to brainstorming
sessions, we will conduct formal
one-on-one interviews. The
formal interviews will follow the
best practices of eliciting
requirements by adhering to a
predetermined list of questions.
Lastly, we will conduct
observational interviews to
witness user’s interaction with the
current system. From
observational interviews, we can
witness day-to-day observations
and apply expert knowledge to
formulating the requirements and
verifying the requirements from
previous elicitation techniques.
5. Incessantly
changing
requirements
and project
scope
Users’ needs may
change or their
perception of the
system may change
over the course of the
project, to which could
result in an endless
stream and influx of
requirement change
requests
9 9 If the user is unsure of their
desired outcome, they could
issue change requests
repeatedly and incessantly, to
which would hinder the
progress of the project and
change the scope of the project
if the Product Owner and
Project Team accept too many
changes. Change in scope
would ultimately affect the
project’s schedule and budget,
resulting in project failure, an
over budget project, or delayed
project.
Accept Although we will advocate
creativity and promote changes to
the system, in order to ensure the
project remains within budget and
on track with the predetermined
schedule, we will implement
Change Requirements’ deadlines.
Once the deadline comes to
fruition, we will table the
subsequent change requests for
review and possible
implementation later, such as in
subsequent sprints, through
software upgrades, or system
patch.
6. Incorrect
System
Requirements
If the client is unsure
of what they want,
they could present
requirements that
would not meet the
9 10 Incorrect System Requirements
would have a major impact
upon the project because the
software product would not
meet or satisfy the business
Avoid In order to ensure the client is
aware of their actual needs, we
will conduct brainstorming
requirements elicitation sessions,
as often as necessary and confirm

needs of Capstone
Bank, to which would
result in a system that
does not coincide with
the original
perceptions or
business needs.
needs, functionality, and end
user requirements, to which
would result in loss time,
resources, money, and business
relations. Additionally,
erroneous requirements could
lead to development of a
product that would be
susceptible to security issues,
which would lead to further
loss of money and reputation as
law suits begin to materialize.
our interpretations with the client
after designing each sprints
objective. By incorporating
brainstorming sessions, we will
be able to guide the user through
expertise and knowledge. By
guiding the user, the user will be
more apt to arriving at a
formidable conclusion of their
needs, to which will aid in
exposing the correct system
requirements.
7. Misidentified
Requirements
If the requirements do
not experience
accurate identification,
functionality could
suffer, user interfaces
could become
cumbersome, and
exclusion of
requirements could
transpire.
9 10 Inaccurate identification of
requirements would have a
huge, negative impact upon the
software product. Essentially, if
the requirements do not receive
accurate identification, we
could, yet again, build a
product that did not meet
business needs, functionality
requirements, and satisfy user
expectations, to which would
result in loss of time, money,
resources, and reputation.
Unequivocally, we would either
consume the losses or charge
Capstone Bank, either way; one
or both businesses would suffer
the consequences and may not
recover.
Avoid In order to identify the
requirements accurately, we will
incorporate and implement
business analysts to gather
requirements and technical
writers to scribe and generate a
formal Software Requirements
Specification (SRS) Document.
By incorporating business
analysts, technical writers, and
SRS creation, we will be able to
not only document the
requirements but also expose any
inconsistencies that require
clarification. Furthermore, in
addition to a formal SRS, the
technical writers will collaborate
with the software designers to
create formal Unified Modeling
Language (UML) Use Case
Diagrams, Activity Diagrams,
and Sequence Diagrams to ensure
all the requirements receive
accurate identification.
8. Redundant
Requirements
Redundant
requirements emerge
when the clients do
6 8 If Redundant Requirements
emerge throughout the
software’s life cycle, survives
Avoid In addition the SRS and Unified
Modeling Language Diagrams,
we will utilize a Requirements

not express themselves
clearly and the
software requirement
elicitation process is
not concise,
appropriate, or well
planned.
analysis, and experiences
implementation into the design,
we would develop a system that
consumes too many resources,
performs poorly, and may not
function according to the
business requirements.
Therefore, Redundant
Requirements would cost time,
money, and resources as a
cumbersome software product
emerge. Furthermore, building
a system with redundant
requirements could lead to
missing essential requirements
that relate to functionality,
operability, maintainability,
usability, and security.
Traceability Matrix to ensure all
the requirements are in place and
to minimize the chance for
redundant requirements.
9. High Level
Technical
Complexity
If the project requires
high-level technical
complexities, we may
succumb to
complications if the
required technologies
are too advanced or
technical
3 8 If the project requires high-
level technical complexity, and
we are unable to perform
accordingly, the software
project could fail, the schedule
could experience substantial
delays as we attempt to obtain
the necessary knowledge or
subject matter experts, and the
project could experience budget
increases, to which would be a
detriment to the project’s
schedule, budget, and abilities
to culminate. Therefore, High
Level Complexity could have a
major, negative impact on the
project, resulting in a
potentially ineffective product
that would not function as
required, meet the customer’s
needs and business
requirements, and potentially
Avoid To ensure the project’s
requirements are not too
complex, we will contract subject
matter experts as necessary,
provide and advocate ongoing
training to our software
development team, and ensure
that all employees have all the
proper certifications.
Furthermore, we will collaborate
as a team effort to overcome any
potential complexities that may
arise.

Jim Richardson Software Engineering Capstone 1 IP Phase 5

Jim Richardson Software Engineering Capstone 1 IP Phase 5

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to Jim Richardson Software Engineering Capstone 1 IP Phase 5

Similar to Jim Richardson Software Engineering Capstone 1 IP Phase 5 (20)

Jim Richardson Software Engineering Capstone 1 IP Phase 5