Test Specification Development

Professor Chris Hood

1/16/2019

Introduction

Software Requirements Specification for Online Banking actually gives the requirements that will be applied in the banking industry. It will more especially be used by the customers to ensure that for data verification. Upon the accurate verification of the specifications, the software specialist will then design the proposed system. Besides the customers, bank employees and software testers can also use these Software Requirements Specification.

Scope

With the increased competition in the banking industry, the bank customers have also continued to increase tremendously in recent years. As a result of these, the banking industry is being faced with challenges in serving their customers within the shortest time possible. Due to new markets entrants who provide services at lower costs, the boundaries pressure have significantly increased. Many customers make a demand for access to their financial information not considering their location regarding distance or the time. Failure of the banking sector to provide their customer's requirements, the customers will opt to move to other nonbanking institutions which provide financial services as they require. Therefore to avoid losing customers, this online banking software development becomes of great importance as it will facilitate the acquisition of the customer's demand (Thomas, et al. 2015).

Definitions and Acronyms

Bank: A place where the bank customers receive financial services like depositing and withdrawing from.

Bank customer: This is an individual who owns a bank account in the bank.

Bank employee: This is an individual who performs banking services on the bank after an employment opportunity by the bank.

OBS: Online banking system.

ARS: Airline Reservation System

Specific Requirements

System objectives; these are the initial requirements of the ARS which is in line with OBS. This section highlights all the goals based on the banking industry concerning its customers. The goals help in a top-down growth of the software requirements specification.

System context; this segment usually shows the surrounding and margins of the airline reservation system besides the entities with which it interrelates. This assists us to clearly see how the system fits into the accessible design of the equipment. The system functions and its expectations from other entities to do are clearly defined (Levin, & Stjernlöf, 2017).

Functional requirements; this is where the precise statement of the system function to take place. The dos and dons of the system are clearly defined under this section. The purpose of this requirement is to assist in the registration of new bank customers. This is achieved through data inputs concerning the specific customer. The data required include; the customer name, address besides customer title. To ensure that the customer has successfully been registered, a success message should be displayed or else an error message will have to be displayed, and that will call for process repetition (Hedberg, Helu, & Newrock, 2017).

Future Requirements; these usually refers to the specifications that have not been included in the software, but they might be required to be added versions shortly. These versions typically need advanced technologies and interfaces among other systems. For this to be achieved, the software (ARS) can be designed in future to incorporate the new features.

Non-functional requirements; these are usually the requirements that specify the performance heights required of the system by different kinds of activities. Some of the activities include; the numerical lower and upper boundaries set conditions on the response times and access times of the system (Laplante, 2017).

Software Quality Attributes

Reliability, this attribute measures if the designed product can be relied upon for sustainability in any condition. The product should give a consistency result if it will be concluded as reliable. This shows that product reliability is measured under different conditions and surroundings. The accuracy of a product is the essential requirement under the reliability attribute.

Performance attribute is measured through its’ efficiency. The efficiency of a system is the major requirement under the performance attribute. For instance, the systems’ processor capacity and disc memories need to be effectively utilized. If it happens that the system is inefficient, then its use in real-time applications is not guaranteed hence performance impairing of the system (Dinsmoor, et al. 2016).

Supportability attribute goes hand in hand with maintainability requirement of the system. The systems' various versions should be easy to maintain. For instance, for growth, it should be easy for code addition to the already present system. From time to time, upgrading of new features besides technologies should be easy for the existing system, and finally, the cost of upgrading should be relatively low. Finally, licensing attribute; under this, the ability to use the system with ease is mandatory. Restriction resulting from product licensing from one country to another should be minimal.

Some of the significant design constraints in this software include; there will be a specific minimum and maximum amount of money to be withdrawn by the customer, for one session, the software will allow a specified maximum amount and the same applies for the maximum amount to be withdrawn in a day from the customer account. Secondly, there will be a minimum memory for the software to effectively operate, for instance, 20GB (Davis, 2015).

Verification method; for a customer to access the system services, he or she will be required to enter his or her valid personal identification number and bank account number. Failure to enter the correct details for three consecutive trials, the account will be automatically blocked by the system. Secondly, the bank user can only access one account at a time, and for the administrator user, he or she will be required to enter his or her login identity to access and change any facility given by the software system.

Requirements Traceability Matrix

References

Davis, A. M. (2015). Achieving worth in software necessities. Great Software Debates, 143-154.

Dinsmoor, C., Mei, M., Wong, B., Agrawal, A., & Levene, G. (2016). Software Requirements Specification (SRS).

Hedberg, T. D., Helu, M. M., & Newrock, M. W. (2017). Software requirements specification to distribute developed information (No. Advanced Developed Series (NIST AMS)-300-2).

Laplante, P. A. (2017). Requirements engineering for software and systems.

Levin, L., & Stjernlöf, C. (2017). Computerised Testing Toolkit Service: Software Requirements Specification.

Thomas, J., Nair, J., Gautham, J., Meduri, P., Kaur, S., Sharma, R., & Singh, H. (2015). Software requirements specification (SOEN 6481) on Unlimited Space System (ISSv2).