Software Requirements Engineering

Abstract

The ability of a product to meet the clients’ intents and needs determines its quality. The clients’ requirements should thus be captured correctly to ensure the success of any business. This document focuses on the systems requirements engineering for an online banking project and states the requirements for the preparation of a requirements meeting and the skills that a systems requirement engineer should possess in order to carry out their duties properly.

Introduction

Technological advancements have revolutionized how companies interact with their clients as well as how they transact their businesses. This has been made possible by the development of the World Wide Web and the internet which are the media used for e-commerce transactions. Moreover, business transactions have been taken to the mobile Web applications through Web-enabled appliances and advancements in wireless technology. It is now easier to reach clients to provide them with product and service information as well as interactive business transaction opportunities. Companies are thus using Web-based information system to carry out their business with the help of software requirements engineering.

Software Requirements Engineering

Software requirements engineering is the process of finding the purpose of the software through identification of stakeholders and their needs and documenting them for analysis, communication and implementation (Pohl, 2010). Moreover, it defines the benefits of having the right software requirements by involving the stakeholders throughout the software development life cycle to look for, analyze, specify, and validate the software development. For an organization providing online banking services, the requirements would be determined and agreed on by the clients, users and developers of the software before its production.

The requirements define what the software does to provide value to its stakeholders by defining its capabilities, properties, characteristics and qualities the software possesses. Further, the requirements would define the performance of online banking software functions and the limitations that might arise in the implementation process. The business requirements would also define the reason for software development. When preparing for the requirement kick-off meeting, the system engineers would need good interpersonal skills, such as objectivity and open-mindedness for application to the users and stakeholders (Pohl, 2010). Such skills would also be useful in communicating project status to resolve conflicts and arising issues.

In the preparation phase, the participants include the requirements engineer and customer arena participants, such as analysts, managers and users, where they discuss issues raised during the indoctrination stage. Review and resolve issues are discussed during this phase with the issues remaining open until all the required information for resolution is available. The requirement engineer tracks all the open issues and determines whether they have been adequately resolved with consultations from the customers (Laplante, 2013).

This would be followed by scheduling and organizing the elicitation meeting through continual communication with the participants while they prepare for the meeting. Scheduling of the meeting takes place once the requirements engineer determines that the open issues from the elicitation meeting agenda are thoroughly resolved or need some further discussion. Further, the requirements engineer would lead the consultation process with the customers to ascertain the type and subject of the meeting (Pohl, 2010).  The meeting type would show the focus of the project, and its subject would pinpoint the specific requirements for examination.

Moreover, the level of detail of the meeting is determined by the engineer and the customers. These details include; an overview that provides the participants with a comprehension of the materials. An elaboration of the issues would be done to provide additional issues followed by a refinement for great deal would be further done. Participant identification would be the next step followed by artifact collection for distribution to the meeting participants (Laplante, 2013). A meeting notification would be made to all the participants after a determination of the meeting time, date and place. The participants would then be required to fill in assignments showing that they would beat the completion deadline. The meeting location would be determined by the majority of participants with the equipment and facility determined.

The systems engineers would need to think broadly to identify solutions for online banking system, that are cost effective. They should have to get prepared for the project by collecting data and documents for the project’s context. The data would be reviewed for concept analysis and familiarize themselves with organizational policies, regulations, standards and historical information that might affect the project and impose constraints (Laplante, 2013). It would be crucial to check information concerning the previous projects having the same characteristics with the project at hand. The previous projects would provide lessons and requirements as well as descriptions of current operations.

The scrutiny of the material and previous data would provide information about the potential types of stakeholders and important subject matter experts. The systems engineers would then draft the collection plan requirements, an approximation of the needed resources as well as the types of tools appropriate for the project. Moreover, the engineers would identify the potential risks that may come up during the requirements collection process and the mitigation strategies for potential risks. The other step would be identification and management of the stakeholders, who include the sponsors of the project, users, interfacing businesses and operations, and business analysts, legal and financial experts (Pohl, 2010).

A determination of the root cause of the problem would follow in the preparation process to ascertain the real need of the project is addressing. Defining the capability scope would follow to provide a framework for the project to act as a guide to the collection process of the requirements. The capability scope would be subjected to a review by the stakeholders and the later approved by the clients. The systems engineers are tasked with elicitation and discovery of the requirements to they fall within the scope of the project. Other documents, such as the project definition documents and statements of objectives would also assist in defining the capability scope of the project (Laplante, 2013).

The system requirement engineer should be a person who is creative, talented, as well as team oriented and should be capable of providing actionable solutions for the challenging problems experienced by clients. The person should be able to establish information requirements by employing analytical methods. Further, the requirements engineer should lead the design, development and specification of tools for new capabilities and should perform in depth studies and analyses. Other skills and abilities include; the ability to design, create, and support complex environments, technical consulting and solution engineering (Laplante, 2013). The requirements engineer should also possess broad experience with infrastructure technologies, experience in storage concepts and solutions, software intensive systems, cyber defense, strong interpersonal communication skills, trouble shooting skills as well as experience in software intensive systems.

The SRS specification document would have the details of the participants, issues assignment notification, the suggested meeting date, place and time. The assignments due date, participants and their roles would be included. Issues to be handled are included after they have been prepared and distributed to the participants before the meeting can take place. Contact name, address, phone and email would also be included. 

Leave a Reply