Deliverable Length:  7–10 pages, excluding title and reference pages In the final week, you have met with the customer and provided a real description of the software requirements engineering pr

Software Requirements Specification for Online Banking

Charles Williams

CS455 IP3

Professor Chris Hood

1/26/2019

Software requirement elicitation

Online banking services

In the current world, technology has taken over all aspects of the economy. This has not only eased the work but it has also led to the improvement of the product. For example, in the banking sector, technology has led to the introduction of online banking which has eased money transfer and withdrawal without physically visiting the bank. The software can allow a customer to know when any transaction is made on his/her account anywhere in the world. This has greatly improved the banking sector services to customers. In terms of security, the introduction of technology has enabled the tracking of any theft cases. The bank is also able to efficiently and effectively allow the use of biometric scans in accessing safety deposit boxes and accounts which is a great boost to the security of the assets in the bank. Therefore, this project will discuss the requirements elicitation, define them, identify and establish the documentation of the software.

Requirements for a kick-off meeting

For better preparation of the kickoff meeting of the project, some steps need to be taken into consideration. First, the organizer of the meeting should prepare themselves adequately on how they will control the meeting from the start. Then plan for the project to help to be able to explain yourself in the meeting and for smooth running of the meeting. Important aspects like the schedules of the meeting and the entire project, the budgets, and the supporting documents should be given more time for preparation (Klein, 2017).

Liaising with the accounts and any other manager who had the initial idea would be helpful. Talking with the accounts manager will help understand the customer desires and needs for the project since he is the one who talked them into committing to the project. Make sure to avail yourself with the original copies of the project schedule, its budget, and the work schedule. Analyze the customer’s requirements and the timeline for the entire project. Try to understand the customer by talking to him/her or the accounts manager to get their background (Klein, 2017).

It is vital to gather all the documentation required for the project and come up with a drafted risk list, time schedule, and the project's budget. Have a head start of the project before the meeting even if you don't have all the relevant information of the project that could help create the definitive version of the project.

For any project that is undertaken, there are expectations. Therefore, write down the project's goals and results. This will help come up with the best and more important decisions of the project; after that, confirm them with the manager or owner of the project idea.

The project will require expertise and manpower to execute it. Recruit them and allocate them responsibilities to perform. Avail of the required resources for the completion of the project form the technical, operations department, corporate and the management department. Come up with a contact list for the team members which will be distributed during the meeting. At the meeting ensure to ask the team members to confirm resource allocation and their responsibilities.

After gathering all vital information, create a presentation that is professional. Use the statement of work to guide your projects assumptions. Any changes suggested during the meeting will be added to the schedule at the end of the meeting. Create an assumption list with all chosen members of the project.

Schedule the meeting with the inclusion of all the participants and give suggestions of the time for the meeting and the dates. Inform the participants on the time of sending documents b3efore the meeting. so that they can review. After the date and time of the meeting has been confirmed, arrange the conference room and call and prepare for the meals and drinks prior to the meeting. Finally, inform the participants of the length of the meeting and whether meals and drinks will be provided during the meeting.

After the end of the meeting, send a thank you text or email to all the participants and explaining to them how you appreciate their attendance of their meeting and how important their views will be to the success of the project.

Skills required for elicit software requirements and elicitation process

Good interpersonal skills are a very vital asset in eliciting software project requirements. Being open-minded and a good listener, being a team player and able to create and maintain a viable relationship will greatly help in software eliciting. The project manager should be able to communicate effectively about the status of the project and resolve any issues and conflicts that may arise during the project among the stakeholders. This will enhance the chances of success of the project.

The manager should be a critical thinker who is able to think broadly. This will help understand the project well and know what the project will require for its execution. This will help in the identification of cost-effective solutions (Naeem, Waheed & Raza, 2017).

To efficiently and effectively understand the project, requirements and all the resource requirements that will be needed to facilitate the project. A feasibility study will help in collecting all the relevant information required for the project. After the feasibility study, analyze the findings of the study and come up with the relevant cases and brief resolutions of the project. Review all the relevant historical information in relation to the project, what policies the organization has, its standards and any regulations available will have an impact on the project and if they will constrain it in any way. Analyze all the previous projects done by the organization in the same area both the successful and failed ones. Review their specifications and documentation in technical terms to derive some direct and indirect lessons and what the requirements of the projects were. Determine whether there exist any descriptions of the present operations specifically the approved operational concepts and examine any issues that are documented. This information will help identify the types of stakeholders required to facilitate the elicitation of the project. After that, come up with a drafted requirement of the collection plan, approximate resource requirement examines the tools appropriate for the project with the use of the same method. Lastly at this stage identification of the risks that may arise during the collection process of the requirements and come up with strategies through which you will mitigate the risks. Although the project manager will be the overall person in charge of the project, other people will be required to facilitate the planning and execution of the project. This will affect all other people in the organization and the current systems put in place. The effect may be either indirect or direct thus expanding the stakeholder's list.

Stakeholders are the managers who will sponsor the project and contributor to the requirements of the project. Stakeholders who provide the technical and operational requirements form the primary stakeholders. Those people within the organization who are indirectly affected by the project, for example, the operations and business interfacing personnel, the SMEs like managers and technical and financial experts and others who must be kept in loop form part of stakeholders. Come up with a way that will help in communication across the stakeholders. This can be done through the creation of the project emails, meetings or any other formal presentation.

The person in charge should be able to establish the main reason why the problem exists. This should be done before the commencement of the requirement collection. For the project to effectively address the problem, the SE must be able to answer the question of why the project was chosen. This can be done by conclusively looking and investigating the real and perceived needs of the project through looking in the environment. The process can be facilitated by examining the informational needs through operations and concepts and analyzing them. Make sure all the stakeholders agree on the need to have a straight and outright problem statement that is in relation to the case of business. The ability of the software elicits in solving the problem is very important since some customers may raise the question of how and whether the software elicits will solve their problem with the laid down options. This can only be avoided by giving viable options to the customer with a very clear process (Shah & Jinwala, 2015).

The software elicits should be able to generate and explain the capability of the project. This will help in guiding the process of requirement collection. This process is important since it provides all information about the project at hand to stakeholders. Stakeholders can review it before they give it to the customer for approval. Software elicit explains the requirements of the project and with the help of scope give the boundaries of the project. This helps in reviewing the requirements of the project throughout the projects life cycle. This process may include the piloting and testing stages. It helps guide the project from the launching time to the completion of the project. Capability scope is important in describing the resource requirements and all the information needed during the planning process. The information that is found in the capability scope document is; purpose, value proposition, objectives of the project, sponsor, customers, the scope of the project, out of the scope, interfacing, major milestone, dates of schedule, critical assumptions, risks, issues, constraints and success criteria (Stanton, 2017).

The software elicits should collect information from all sources including the inexperienced users, customer users, SMEs, the managers, and all the stakeholders. For important system functionality and performance capabilities, operation users provide important of the needed requirements. Their contribution is vital in the delivery of the product and services and required systems which help enhance their efficiency. This is done by enabling access of required information on time. The software elicit can generate information from the customers who have used the project before and through observing those who currently are using it. Information can also be gathered from looking at the environment of the user and through the responses captured from the target questionnaires. The SE in consultation with the SME makes sure of the security of the project and that the requirements of operation are feasible and comprehensive. To determine the best suited, elicit requirement, the schedule, type size, and the complexity of the project are first determined (Peltier, 2005).

SRS requirements

SRS are categorized into several parts which when put together form a complete the requirement of the project. The scope of the project which briefly describes the software; it also gives the span, purpose, benefits as well as the goals of the project. SRS can explain the intended readers of the document which may include the stakeholders and any other party that may be of assistance to the project. The document will include the writing conventions that are used as a guideline in the writing of the document. The document will explain the main reason why the project is being undertaken and give a brief scope of the product.

The second step is coming up with an overall description of the SRS. This includes the product perspective which helps describe the context and origin of the product. Product features which describe all features of the product and the essential functions of the project; characteristics and the user classes which explains who the users of the product. The environment of operation; this describes the environment through which the product will operate including the hardware, operating systems, and projects version, constraints which explain the expected constraints to the project and user documentation which describes documentation components which may include manuals tutorial and online help (Laplante, 2017).

The third is system features. This includes all the specifications of the projects. This will include how the system functions and how it responds to certain actions.

The external interface which gives a description of the software interface between the user of the product and the software; this includes the hardware, communication, user interface and software (Dinsmoor, et al, 2016)

The last one is the nonfunctional requirements. This part includes any other information about the product which is not included in the above four sections.

In conclusion, for any project to be successful, good preparations are very important from the time of kick-off meeting to the completion of the project. During the elicit requirement process, clear communication among other key factors discussed above is very important in enabling the documentation of the requirements. Some factors to be discussed in week 5 in SRS have been outlined which will help the discussion of SRS.

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

WEEK 4(TBD)

WEEK 5(TBD)

References

Ahmad, R. A. (2016). Interface-driven software requirements analysis. European Scientific Journal, ESJ, 12(30).

Ammann, P., & Offutt, J. (2016). Introduction to software testing. Cambridge University Press.

Fayaz, S. K., Yu, T., Tobioka, Y., Chaki, S., & Sekar, V. (2016, March). BUZZ: Testing Context-Dependent Policies in Stateful Networks. In NSDI (pp. 275-289).

Chandra, S., Das, A. K., Mangipudi, S., Mukherjee, D., Sinha, S., & Thummalapenta, S. (2015). U.S. Patent No. 9,038,026. Washington, DC: U.S. Patent and Trademark Office.

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).

Guerra, E., & Soeken, M. (2015). Specification-driven model transformation testing. Software & Systems Modeling, 14(2), 623-644.

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).

Klein, G. A. (2017). Sources of power: How people make decisions. MIT press.

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

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

Naeem, M. A., Waheed, U., & Raza, S. F. A. (2017). Requirement Correctness Problems and Strategies for Web Applications. Pakistan Journal of Engineering, Technology & Science, 6(1).

Peltier, T. R. (2015). Implementing an Information Security Awareness Program. Information Systems Security, 14(2), 37-49.

Pohl, K. (2016). Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant. Rocky Nook, Inc.

Shafique, M., & Labiche, Y. (2015). A systematic review of state-based test tools. International Journal on Software Tools for Technology Transfer, 17(1), 59-76.

Shah, U. S., & Jinwala, D. C. (2015). Resolving ambiguities in natural language software requirements: a comprehensive survey. ACM SIGSOFT Software Engineering Notes, 40(5), 1-7.

Stanton, N. A., Salmon, P. M., Rafferty, L. A., Walker, G. H., Baber, C., & Jenkins, D. P. (2017). Human factors methods: a practical guide for engineering and design. CRC Press.

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).