Impact And Effectiveness Of Requirement Engineering

Published Date: 02 Nov 2017

Abstract- Requirements engineering is not straightforward for any software development team. To establish and manage a good set of requirements is one of the critical success factors for any system project, and for the development of any complex product in general. Developing software when team members are located in widely distributed geographic locations poses many challenges for developers, particularly during the requirements engineering phase.

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

I. INTRODUCTION

"Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families."

Requirements engineering (RE) is an important phase in the development of information systems. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting them in a form that is amenable to analysis, communication, and subsequent implementation.

Requirements Engineering (RE) research has played a critical part in systems development through exploring, studying and addressing issues of concern to both developer and business communities.

There are a number of difficulties in this process. Stakeholders may be numerous and distributed. Their goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish.

In the process, there are some areas that can be used to categories and compare RE activities; they include:

• Requirements Elicitation

· Requirement Analysis

· Requirement Specification

· Requirements Validation

2 REQUIREMENT ELICITATION

Requirement Elicitation is the first step for requirement engineering process. It is an effective procedure for gathering the exact requirements from the customer’s site through various advance methods:

2.1 Brainstorming

Brainstorming is a group oriented approach to extract the requirements from the customer. An effective session is conducted and every participants are free to expose their ideas in these ideas will be documented in such a way that everyone can see it. After a completion of session a detailed report is prepared and finally a document will be prepared which have list of requirements and their priorities.

2.2 Facilitated Application Specification Technique (FAST)

In FAST, a team of customers and developers work together to identify the problem and corresponding solution. Similar to the Brainstorming a meeting is organized at neutral site and controlled by a facilitator. Before the meeting a list of object is prepared and after the discussion some of the entries

3 Requirement Analysis

Requirement Analysis is done after elicitation process, for analysis of conflicts, ambiguities, inconsistencies, missing requirements or extra requirements. The requirement engineer identifies the risk associated with each requirement and analyzes it. Rough estimates of development effort, development cost and development time also calculated.

from the list is eliminated and new entries are also added to the list.

2.3 Quality Function Deployment

In this method, technical requirements are documented and three types of requirements are also identified:

2.3.1 Normal Requirement: The main functional requirement of the software product are identified.

2.3.2 Expected Requirement: Expected Requirements do not state explicitly by the customer and it enhance the level of satisfaction.

For ex- Protection from unauthorized access.

2.3.3. Exciting Requirement: These are beyond the customer expectation and make more satisfy to the customer.

For Ex- Providing an additional copy of important files of the software.

2.4 Delphi Technique

In Delphi technique session all the participants make a note of their requirement and exchanged them with each other. This process is repeated till all the participant agree on a common set of requirements.

2.5 Use Case Based Requirement Elicitation

Use case approach uses a combination of text and pictures. In order to improve the understanding of requirement. The two component, actor and use case, are used for design of use case approach. An actor can be a person, machine or a Information System that is external to the system model. Use Case describe the sequence of interaction between.

4 Requirement Specification

It is an activity which is done after the completion of requirement elicitation and analysis. It is also known as Requirement Documentation. It can be defined as an activity during which requirements are recorded in the form of system charts, pseudo programs, written documents, which is collectively known as Software Requirement Specification (SRS) document.

SRS includes general issues like speed, availability, response time, recovery time e.t.c. of various software functions. A SRS document should be portable, corrective, maintainable, secure and reliable.

5 Requirement Validation:

Requirement Validation certify that the SRS document is an acceptable document of the system to be implemented. In the requirement validation process, the requirement errors are identified and then fixed.

Requirement Validation is an effective and important phase to validate the requirements. There are various validation techniques such as plan review, distribute SRS document, organize review meeting and review SRS document.

6 Requirement Review

Requirement Review is a systematic manual analysis of requirements. Both the contractor staff and customer should be involved in review. Requirement review can be formal or informal.

In Formal requirement review development team should walk the client through the system requirements, explaining the implication of each requirement. The reviewers check each requirement for consistency, completeness, verifiability, comprehensibility, traceability, adaptability.

In Informal requirement review contractor discuss the requirements with as many stakeholder as possible.

7 Requirement Management

Requirement Management is a systematic approach to eliciting, organizing and documenting the requirements of the system and a process that establishes and maintains agreement between customer and project team on the changing requirement of the system. Requirement Management is the process of managing changing requirements during the requirement engineering process.

From an evolution perspective, the requirement falls into two classes:

Enduring Requirements: These are stable requirements which drive from the core activity of the organization and which relate directly to the domain of the system. For a library management system, issue/return a book is a core activity and stable for the system.

Volatile Requirement: These requirements are change during the system development or after the system have been put into operation. There are many reasons for such changes some of the reasons are environment technology, policies, customers expectations.