RUNNING HEAD: SRS AND METHODS

SRS and Methods

------------------------

-------------------------------

------------------------

-----------------------------------

------------------------------

------------------------

 
 Abstract

This paper will be the final creation of a Software Requirements Specification (SRS),

with the reasoning behind building a SRS. This document will dictate what is needed in detail all

of the aspects the software needs in order to be built. This is necessary to do prior to the

beginning of the projects creation, the assignment will include a brief appendix detailing what

agile methods are and how it effected the creation of this document.
 Software Requirements
Specification
For

Online Banking Services

Version 1.0 approved

---------------------------------

Wayne Bank

January 17, 2011

Table of Contents
Table of Contents..........................................................................................................................iv

Revision History...............................................................................Error! Bookmark not defined.

1. Introduction.............................................................................................................................vi
1.1 Project Scope.................................................................................Error! Bookmark not defined.

1.2 Kicking off Meeting.......................................................................Error! Bookmark not defined.

1.3 Skills needed by developer/Business Analyst/Facilitator...............Error! Bookmark not defined.

2. References...................................................................................Error! Bookmark not defined.

3. Overall Description....................................................................Error! Bookmark not defined.

4. Specific Requirements/Functionality.......................................Error! Bookmark not defined.

4.1 Key Functionality...........................................................................................................................4

4.2 User Case …………………………………………………………………………………4

5. Usability......................................................................................Error! Bookmark not defined.

6. Reliability....................................................................................Error! Bookmark not defined.

7. Performance................................................................................Error! Bookmark not defined.

8. Supportability.............................................................................Error! Bookmark not defined.

9. Design Constraints.....................................................................Error! Bookmark not defined.

10. Licensing...................................................................................................................................6

11. Requirements Verification........................................................Error! Bookmark not defined.

12. Appendix A.................................................................................Error! Bookmark not defined.

Revision History
Name Date Reason For Changes Version
Jan 15th 2011 Add Use Cases of the account to section four A
th
Jan 17 2011 Additional information sections 1, 2, 9 B
Jan 22nd 2011 Additional information section 11 Verification and C
Validation
Feb 5th 2011 Appendix added for final draft D
1. Introduction:
1.1 Project Scope

For this SRS project the team will be designing an online banking service for the Wayne

bank company to better serve their community. With the digital age introducing banking on the

go which has diminished the need for brick and mortar transactions, The need to provide the

customers easier access by of the internet to account information has become a vital part of the

everyday banking environment. For this reason The Company is in need of a software

application designed so Wayne bank customers can login, make the same transaction as with

physical banks and also access numerous other services for their everyday needs.

1.2 Kick Off Meeting

The project should speak for itself and the customer should know what they want. This

point of time is the best opportunity to establish a sense of common goal and to understand the

each other’s wants from the project. Here is the process of solving what the software must do to

add value for its stakeholders, there needs to be functional requirements define for the

capabilities of the software product. There needs to be defined the characteristics, properties and

qualities that the software product must possess, and a clear understanding of how well the

software will perform its function with the supplied information.

If the software requirements are not right, the company that is asking for the software to

be created will end up with software that does not qualify for their needs. Having the

stakeholders involved in the process is essential, eliciting, analyzing, specifying and validating

the software requirements is the key to a correct beginning. The main point of the kick off

meeting is to meet the people requesting the work, the people that will use the software, what
will be the rewards with the active software and if there is another source the company can use to

complete what they need. So to perform a correct kick off meeting there is three key areas to

remember with questions.

The first set of questions focuses on the customers and the stakeholders, what goals they

have for the software application and what kind of rewards they want. The next set of questions

should focus on getting a better understanding of the problems they are having, and the

perception the customer has about the application. Following that would be a final set of

questions that focus on getting a clear communication action between all parties involved, a form

a Meta questions that help to break the ice. A questions and answer section at the end will help to

track any last minute concerns form all parties involved in the project,.

1.3 Skills needed by developer/Business Analyst/Facilitator

Requirements Management is the process of identifying key practices within the project

that elicit documents, organizes and tracks any changes required, with the purpose of

communicating all the data across the entire team. There are many different techniques that can

be used to elicit requirements, these include interviewing stakeholders, using focus groups,

workshops that key requirements, monitoring current work habits and using questionnaires with

surveys. Documentation is another path to follow that involves the study of the industry

standards revolving around laws and regulations, product literature, work instructions help desk

reports and past projects the company had and where within them lessons have been learned.

This establishes and maintains an agreement with the customer and the users of the

requirements while keeping control of the baseline requirements, process proposed changes to

the requirements to best fit the customers’ needs. You also must keep requirements consistent

with the plans and work project created, when negotiating new changes or revisions make sure to
it is based on the impact of approval. Planning for different actions that can accrue is an

important quality, since software can increase in size and complexity during the development.

Requirements are added as knowledge is obtained; also know the organization and the area of

practice the people you talk to are in.

So for a developer to have the right skills to perform this action he or she needs to

understand what correct questions are needed. Keep control of the interviews; make sure all the

topics and the questions to be asked make sense to the environment the project is involved with.

Also the use of user scenarios to figure out the Who, What, Why, When and How will bring to

light the pieces of data information that will show a better understanding the interfaces

concerning the software.

2. References:
[IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.

[Bruade] The principal source of textbook material is “Software Engineering: An Object-

Oriented Perspective” by Eric J. Bruade (Wiley 2001).

[Reaves SPMP] “Software Project Management Plan Jacksonville State University

Computing and Information Sciences Web Accessible Alumni Database.”
Jacksonville State University, 2003.

3. Overall Description:
The on line banking service software encompasses numerous functions for the customer

to use from transferring money, to making payments for due bills. The design of the system will

be completely web-based, linking to the Banks remote web server from a standard web browser.

An internet connection is necessary to access the system. The Bank web site will be operated
from the server department location, when a customer connects to the bank web server, the bank

web server will allow the customer to access their account and provide the functions offered.

4. Specific Requirements/Functionality:
4.1 The on line banking will offer key functionality some of them will be:

 Inspection of account balance.

 The ability to transfer funds form account to another.

 The ability to download or print documented information of the account.

 The action ability to pay third party bills by of internet transactions.

 Actions of opening or closing either the first account or additional ones.

 Apply for personnel loans, credit cards, and mortgage or car loans.

4.2 User Cases

Use Case ID: Wayne Bank #18745AK

Use Case Name: Logging into web based account

Created By: Luis Binnier

Last Updated By: Luis Binnier

Date Created: 01/15/2011

Date Last Updated: 01/15/2011

Actors: Customer (The person in need of information pertaining to personnel account)

Description: The Customer navigates to the company’s website login security section

Trigger: The Customer applies an active login ID and password

Preconditions: Here there needs to be certain conditions that must be true before the

process can start for the customer.

1. The customer has a certified active account with the bank

2. The login ID and password must be applied correctly to be allowed access into the

account.

3. The customers’ computer needs to have the correct system requirements to launch

task.

Post conditions: At this point the system itself must be at a condition level so as to allow

the customer to achieve their goal within the means of the system.

1. System is up and active at central server site

2. The account of the customer has been updated with current financial information.

3. The system database is running in correctly if not attempts of hacking within

server or customers computers.

Normal Flow: Here is the description of the customers’ actions and systems response if

all conditions are met prior.

1. Customer navigates to the login website of the bank

2. The customer types in their login ID and password, hits the return button and

waits for the systems response.

3. If the customer types in the correct information in the correct format the system

will let them into their account.

Alternative Flows: If there are any alternate issues that arise outside the normal flow,

then these actions are taken by the system.

1. If the customer does not apply the correct information the system will inform them of the

mistake, if there is three attempts done and all three fail in sync then the system will disable the

account forcing the customer to call the bank for assistance.

Note: Some additional comments pertaining to the use case as a whole

This use case is the first step in the interaction with the system by any customer, this use

case cannot be bypassed for any reason if the steps in the normal flow are done correctly,

and this is for security reasons.

Use Case ID: Wayne Bank #28467SM

Use Case Name: Navigating account data for transactions

Created By: Luis Binnier

Last Updated By: Luis Binnier

Date Created: 01/15/2011

Date Last Updated: 01/15/2011

Actors: Customer (The person in need of information pertaining to personnel account)

Description: The Customer has opposition to move money around within the customer’s

account or make payments

Trigger: The Customer starts the process of viewing the account information and/or

makes a payment to the bank.

Preconditions: Here there needs to be certain conditions that must be true before the

process can start for the customer.

1. The customer must have enough currency to cover all transactions he or she applies for.

2. All actions applied for by the customer must meet the banks rules and regulations

concerning law guidance.

 Post conditions: At this point the system itself must be at a condition level so as to allow

the customer to achieve their goal within the means of the system.

1. The system is up to date with account balance information and payment policies.

2. All security measures pertaining to transaction protection is active and functioning

correctly.

3. System has a valued e-mail address to send the customers receipt of actions.

Normal Flow: Here is the description of the customers’ actions and systems response if

all conditions are met prior.

1. Customer views account information at leaser.

2. The customer makes a transaction pertaining to his or her needs

3. Once completed the customer receives a receipt at the predestinated e-mail address.

4. The system logs all account actions and proceeds to archive it and update account

information.

Alternative Flows: If there are any alternate issues that arise outside the normal flow,

then these actions are taken by the system.

1. If the customer applies for an account transaction but the funds cannot support it, the

customer will receive a notification on the website that they cannot process the request

and will be asked if they want to try another action.

Note: Some additional comments pertaining to the use case as a whole

This use case is the final step in the interaction with the system by any customer, this use

case is designed to cover all the customer’s needs they may have with their accounts that

the web based access can provide.

 Use Case ID: Wayne Bank #39456GU

Use Case Name: Downloading system activities logs

Created By: Luis Binnier

Last Updated By: Luis Binnier

Date Created: 01/15/2011

Date Last Updated: 01/15/2011

Actors: Employee (The person with the responsibility to track activates of all the
accounts)

Description: The employee needs to access the system logs to download them to check if

all updates have been done by the system.

Trigger: The employee logs into the system with bank employee certified credentials.

Preconditions: Here there needs to be certain conditions that must be true before the

process can start for the employee.

1. The employee logged into the system with active ID and password.

2. The employee puts in the correct codes to open the daily logs of the system for download.

3. The employee knows the process of getting the data any other actions they may need to

take.

Post conditions: At this point the system itself must be at a condition level so as to allow

employees to achieve their duties within the system.

1. The system was able to process all transaction correctly and log them with no issues.

2. The server has clear all data updates with no issues.

3. The system is up and running.

 Normal Flow: Here is the description of the employees’ actions and systems response if

all conditions are met prior.

1. Employee navigates to correct system page.

2. Then applies correct codes to implement the downloading of the logs

3. Once download is complete the system activates itself for a new log sequence.

4. Employee logs out after verifying the account updates for the day.

Alternative Flows: If there are any alternate issues that arise outside the normal flow,

then these actions are taken by the system.

1. If employee fails to login correctly notification will be sent to higher authority and the

employees account will be locked.

2. If the employee finds that logs are not correct with account updates a report to higher

authority will be sent and the system will stop processing online transactions.

Note: Some additional comments pertaining to the use case as a whole

This use case is the use case for employees to use for system verifications and report

retrieval.

5. Usability:

There are some key requirements that must be in place in order for there is usability of

the software.

 The customer must have internet access and a computer with Browser functions.

 The bank needs to have servers that qualify with the required hardware standards.
  The visibility of the screen to the customer should be orientated to the customer’s

account; it only shows the customer what it is able to use to prevent confusion.

6. Reliability:

The quality level of the system and hardware that is provided must be kept at a stingily

high level due to the customers need to access the accounts on a 24/7 level.

 With customers money being kept with Wayne bank there can no errors when

transactions are done by the system, fail safes must be mandatory.

 Government regulations that are in place to protect the customer’s interests and

affect the banks business actions are to be followed 100% within the systems

development.

7. Performance:

The speed at which the customer travels through the web site should be kept at the

average transfer rate of about six to eight seconds with emphases on the six second mark. Having

to keep the customer waiting on travel within the site will cause customer discomfort.

8. Supportability:

A good quality support of the system is from both the customers and the employees, the

system will offer the customer the ability to fill out a survey that lets them point out the good and

bad points they have found, and also the ability to express any wants they wish for the system.
Also for the company side a good level of support team needs to be implemented, the team must

make up the responsibilities of responding to customer issues, server support and maintaining

company policies.

9. Design Constraints:

There is points of interest concerning key elements that must be used in order for the

design of the system to be functional to the company’s needs, they are.

 The use of Microsoft SQL Server 2008 with visual basic manager, this will be

used to create and manage the database aspects of the system.

 All Dell Server hardware due to the high level quality and high ranking support.

 Since the system is a web based application there is some elements that cannot be

allowed to perform as in.

 No voice reconditioning ability, nor the action of depositing a check as in a brick

and mortar branch.

 No digital signature ability until authorization is granted by federal security

agency connected to the home land security.

10. Licensing:

All Licensing applications or processes concerning federal and state laws will be

managed by the legal department appointed by the bank management representatives. All

software licensing and leases will be managed by the I.T. department concerning the system

development and server support.

11. Requirements Verification:

It is important to keep in mind the level of testing that will be done during the

development stages and once the system is completed. There are some key points for the testing

of this type of software application, stress levels of account information transferring back and

forth to server databases during the high peak time of use. Also account accuracy of numbers,

requests and database time cost for actions taken by the requests. Once they core testing’s of the

system is done and is at an acceptable level there will so be testing done on the customers side,

all possible combinations of requests and transactions must be tested to assure that there will be

no bugs are found with any combination the customer can make.

12. Appendix A:

It is critical to objectively evaluate the impact of a software application for the company

when considering adopting tools for the development of the stockholders requests. It is important

to consider the benefits, costs and risks with the implementation of the work done in order to

fulfill what the software application must do. The agile methodology is an important step

towards adopting tools. Agile Software Development is an evolution of the group of software

methodologies concerning iterative development; this is when requirements and solutions

develop through collaboration of teams that are proficient at self organizing and cross

functioning. The agile manifesto is the values of individuals and interactions with the processes

and tools, working software with comprehensive documentation, customer collaboration and

responding to change through the life of the plan.

 With the agile manifesto it gives guidance and structures to software creation, the

principle points are customer satisfaction with quick completion of a software application that

covers their needs. Except changes at anytime during the development of the software, deliver

working software frequently, the working software is the key measure of the progress. Keep a

constant rate of sustainable development, constant cooperation between stockholders and

developers, communication face to face as much as possible. Motivation is a key tool to

remember, with attention to details to achieve an excellent level concerning the design. Included

with the principles is the idea of keeping it simple, organized and allow adaptation when

circumstances will it.

With the development of the SRS the key structure for it was imbedded in the

Requirement Engineering which gives a platform to understood what the customer wants, here

the six distinct tasks Inception, Elicitation, Elaboration, Negotiation, Specification, and

Validation. With the kickoff meeting is the beginning of understanding what the stockholder

wants and what the software application can do. With that a clear user case structure helps to put

in simple terms what the software application needs to do and what it can do, this helps

developers to write the structure of the software script. Following these steps is the specific

requirements which are the identification in detail what the software application needs to do in

order to satisfy the outcome, this is shown in section 4 with bullets and user cases. At this point

the structure that we talked about earlier pertaining to agile methodology is showing the structure

within the SRS, the steps that need to be taken is shown by the outline of the SRS as it follows

the mantra of the requirement engineering tasks. Another point of discussion is the usability and

reliability that governs the needs the software has outside itself and the points of interests where

failure is not an opposition. They too are part of the SRS for this assignment covering the points
correctly pertaining to Wayne’s banks needs. What the software needs in order to function

correctly for the stockholders is part of the supportability section, and the reliability is centered

on the security of customers money and any information they may place into the account. Design

constraints and verification is the aspect of what software and hardware will be needed in order

for the software application being created needs to function on the back end. Verifying that the

software meets the requirements allocated, in other words it means checking the software with

approval to the design specks. Validation is the process of authenticate that the software meets

the stockholders requirements; this involves inspecting the software with the customers’

expectations in mind. With the scenario that is designated for the operation of the system, and the

input data as the test case, the walkthrough is a manual execution of the software with test data to

simulate a machine execution of the software.