Transcript Software Requirement Specification

Software Description
Specification
Group 6
Tony Meteiver, Kyle Hertel, Andrei Vajiac
Introduction

Upon completion of this project, a user-friendly,
interactive mortgage system will have been
implemented to manage the lending accounts for
the people who apply for one through the Martha
Stockton Greengage Foundation. This foundation,
instated upon Martha Stockton Greengage’s
death, was left one billion dollars with the intent
of assisting young married couples who were
looking to buy their first home. The software
itself will be comprised of two parts; both a
client-side and lender-side interface will be
available to view and modify accounts,
respectively.
General Purpose

In essence, the final implementation must
not only be able to efficiently manage
many client accounts and provide an
interface to each client through which
they can access their own account
information, but also provide an interface
for the lenders themselves to be able to
access and modify any account in the
database.
General Purpose






The proposed system has two primary
functions:
Varying tiers of user access:
Client access – allows the user to view their
personal account
Lender access – allows the user to
view/modify all accounts
Admin access – allows the user to
add/remove Lender accounts
These tiers of access are hierarchical,
meaning that each level can perform the
tasks of the levels below it.
Scope


Account Management:
This part of the system will be implemented
to manage all of the different mortgage
accounts for the clients. It will need to be a
database that has the ability to access, store,
and modify its contents quickly and
efficiently. The Account Management will
have to work hand-in-hand with the different
tiers of user access to change what is
viewable by the client, the lender, and finally
the admin.
Scope
Data Description


ConnectionA connection through means yet to be
determined will be required to access the
database or to begin the application process.


AccessGives users of sufficient clearance the ability to
view users profiles. Different levels of clearance
will allow for different functionality including
query searches, manual account closings, and
individual user account status lookup.


SessionThis gives the user the options they have.
And in turn bars the user from making
changes that are beyond their clearance.


UserThis data object is a key feature as it will
determine per individual account what
clearances any given user has at any given
time. This will also hold all user functions.


UserClearenceOneInherits User. Lowest level of clearance can only view the
individual profile that the account name is associated with.


UserClearenceTwoinherits User. Standard level of clearance generally should
be issued to employees of the foundation. Will allow
account name to view any profile however has limited
ability to edit information.


UserClearanceThreeInherits User. Top level of clearance, generally given
to top level administrators. With this variation of account
name the user may change all variables of any given
profile.
Architecture Design







3.1 Architecture Overview
This software system will use the normal internet application with
3-tierd architecture. All system data will be stored on a system
database, (this is the database layer). We will use an application
layer to run all the system functionality. The access layer is run
from any remote terminal capable.
3.2 Database Layer
Within the database layer, we will have a MYSQL database, which
could be handled locally or remotely. Limiting factor being the
type of network the system is run from. The only way to get
access to the database is by going through the apache server
within the application layer.


3.3 Application Layer
The software functionality and operations will be handled though a php5
capable Apache web server. Depending on system network and security
settings, the web server can being ran remotely or locally. Since this
application layer is completely independent from the database layer, they do
not have to be run from the same sever, but can be.


3.4 Access Layer
To access this system, one must have a network capable computer with a
connection to the internet via a web browser. This system is compatible with
Windows, Linux and Mac machines. The access can go two ways, depending on
what the user wants. They can either have it setup on their own network so it
can only be accessed by computers on that network, or they can have it as a
fully web capable web application. In our case, we will use the ladder of the
two because of the security that has been implemented in the design with the
user name and password.
3.5 Architecture Diagram
4.0 Detail Design
















4.1 Class Member Functions and Details
4.1.1 Connection
• private host
o variable that stores the host name of the database
• private user
o variable that stores the database username
• private password
o variable that stores the database password
• function Connection()
o CONSTRUNCTOR: parameters passed in order to store
necessary
values to connect to the desired db with username and
password.
• public function Connect()
o Establishes a connection with the database.
• public function Close()
o Closes the database connection.
4.1.2 Access
• private tablename
o variable that stores the table name ; may well be dropped shortly
• private conn
o variable that stores the active connection to db from connection
class
• private num_record
o variable that stores the number of records affected by any query
• function Access(tablename)
o CONSTUCTOR: initiates the table name and this class's connection
• public function Result()
o gets the result set created by any query
• public function Error()
o gets the any error that occurs during any query execution
• public function search(key: string)
o runs any query that is passed to it and stores the result in the
result
set and the number of row affected as well. True if successful
execution of query False otherwise.
4.1.3 Session
• function Session()
o CONSTRUCTOR: Initiates a session.
• public function session_clearance()
o Gets the username from sessiont
• public function SessionID()
o gets user type from sessiont
• public function getSessionDetail()
o gets user id from sessiont
• public function getSessionAction()
o gets current action from sessiont
• public function setSessoinDetail($uid,$utype,$uname)
o sets necessary variables to establish a session
• public function time()
o checks up time
4.1.4 User
• protected username
o variable that stores the user name of the current logged in user
• protected clearance
o variable that stores the user type of the current logged in user
• protected userid
o variable that stores the user id of the current logged in user
• protected balance_remaining ()
o gets remaining balance
• protected balance_paid()
o gets balance paid
• protected sortby_last_payment
o sorts by last payment
• protected sortby_uid
o sorts by uid
(continued on next slid
• protected sortby_balance_remaining ()
o sorts by remaining balance
• public function Login()
o controls login functionality; if the login is not successful it sets an
error flag to true. If login is successful it sets the loggedin flag to true.
• public function Update()
o gets the posted form and makes the query and send it to the
appropriate function in the dataaccess class.
• public function getUesrType()
o gets the user type, or the staff level
• public function drawLogin()
o draws the GUI of form for system login
• public function Logout()
o logs the user out and destroys all session data
• protected confirmpayment
o confirms payment
• protected confirmorDeny
o confirms or Denies an app
• protected lookupuid
o looks up uid
4.1.5 UserClearenceOne
• function UserClearenceOne ()
o CONSTRUCTOR: Class constructor.
• protected ViewmyRecords
o view only their records
• protected apply
o application process
4.1.6 UserClearenceTwo
• function UserClearenceTwo ()
o CONSTRUCTOR: Class constructor.
• protected ViewanyRecords
o view any records
• protected appstatus
o application status
• protected editcontactany
o change contact info
4.1.7 UserClearenceThree
• function UserClearenceTwo ()
o CONSTRUCTOR: Class constructor.
• protected ViewanyRecords
o view any records
• protected appstatus
o application status
• protected editanyvariable
o edit any variable
5.0 Database Design
5.1 Entity Relationship Diagram
6.0 Software Interface Description
6.1 External Machine Interfaces
This program assumes the user has access to a web browser on a
computer with an internet or intranet connection.
6.2 External System Interfaces
The system will require access to an address repository to check
the validity of the addresses in the database. Also, a connection to
a credit checking program should be used to help determine how
much money should be approved for a specific client. These
functionalities are not currently included in the software, and may
be implemented later.
6.3 Human Interface
The user will input their information into a login interface, and will
be connected to their user account. From there, they can
access/modify their own personal and contact information, view
their loan information (if applicable), view their loan information,
and modify other accounts as allowed by their Admin/Superuser
status.