An Investigation On Requirements Engineering Core Practices

Published Date: 02 Nov 2017

Introduction

It is a complicated and difficult job to make new software (Duggan and Thachenkary, 2003), and one of the most important part of this procedure is specify the requirements (Reubenstein and Waters, 1991). If the errors and mistakes at this stage of process remain unsolved it will cause heavy costs in subsequent phase of developing software (Reubenstein and Waters, 1991, Sawyer and Kotonya, 2004). To evaluate the success of an application it should be measured how much of the user’s expectations are covered. Well developed software should fulfill the purpose it was created for (Nuseibeh and Easterbrook, 2000).

Software Requirements Engineering is the procedure of recognizing the necessities and what should be implemented in the application, analyze and define the specifications. At the end of the job the users demands should be identified and then generate the basic structure of the procedure of developing software (Cheng and Atlee, 2007). By specifying the needs and requirements of the software the goal and objectives of the project will be determined (Humphrey, 1989).

Requirements Engineering is based on efficient user-developer communication and it is more of an interaction and administration work than a technical job and it is consider as a backbone part of software developing process (Duggan and Thachenkary, 2003). Each one of social or individual company factors has its effects on RE activities (Sommerville, 2007). The result of errors in RE stage of programming is poor quality software and delayed delivery.

In "No silver bullet" reloaded: retrospective on "essence and accidents of software engineering" (Fraser et al., 2007), a convincing declaration about the importance of this stage has been quoted from Frederick Brooks (Brooks, 1987):

"The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later."

(Brooks, 1987)

Requirement engineering activities such as requirement gathering and analysis is one of the vital disciplines in software engineering. It includes numerous activities which contain requirements specification, negotiation, elicitation, analysis, and validation (Tahir and Ahmad, 2010). Many researches have demonstrated how much the role of requirements engineering practices is important for successfully accomplishing software projects. A clear relation exists between the quality of the software and requirement engineering process (Niazi and Shastry, 2003). Consequently, a few surveys have been conducted to identify the current RE challenges in industries. Each research focuses on specific group of industries with respect to their size, location and their goals. Berntsson Svensson et al. (2009), focused on quality requirements (QR) practices used in Sweden software industries. Its results show how the QR is gathered and handled in five major Sweden companies. Tahir and Ahmad (2010) studied the RE practices in the Malaysian software industry to identify the RE practices used in the Malaysian software industry. Moreover, Sikora et al. (2012) has investigated the needs and research directions in Germany software industry about the requirements engineering for embedded systems. Finally, in this research we are focusing on identifying the key core RE practices used in Iranian industries.

Background

There are many definitions for requirements engineering, one of the most famous definition for requirements engineering is provided by Zave (Zave, 1997) as follow:

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

(Zave, 1997)

Many researched referred to the given definition; however, the author also found Nuseibeh and Easterbrook (Nuseibeh and Easterbrook, 2000) description on requirement engineering suitable for this research. In Nuseibeh and Easterbrook (Nuseibeh and Easterbrook, 2000) description, requirements engineering is the process of determining if the purpose for which software system was intended is meet, by identifying stakeholders and their needs, and documenting these in a form which is agreeable to analysis, communication, and subsequent implementation. Requirements engineering is often considered as a front-end activity in the software systems development process. However, it is usually a subject to change during development and operation phases. Therefore, requirements engineering plays an essential part in change management during software development.

Software development life cycle (SDLC) is a conceptual framework or process that considers the structure of the stages involved in the development of an application from its initial feasibility study through to its deployment in the field and maintenance (Ruparelia, 2010). SDLC have several models in which the activities that should be performed at each stage of a software development project are described. An SDLC model is used to define the steps that should going to be followed within the software life cycle. It is important to understand the different between a software methodology and a software process model. A software process describes what to do in software development in descriptive view; on the other hand, a software methodology describes how to perform the process in prescriptive view.

According to Ruparelia (2010), software models can be categorized in three software categories, in order to provide a context for their application, as follows:

Category 1: Software that provides back-end functionality. Typically, this is software that provides a service to other applications.

Category 2: Software that provides a service to an end-user or to an end-user application. Typically, this would be software that encapsulates business logic or formats data to make it more understandable to an end-user. Occasionally

Category 3: Software that provides a visual interface to an end-user. Typically, this is a front-end application that is a graphical user interface (GUI).

Furthermore SDLC models may also be categorized as falling under three broad groups: linear, iterative, and a combination of linear and iterative models. In linear model all stages will be performed chronologically; in other words, in linear model stages will be performed, only if their previous stage is complete. However, in an interactive model, each stages of the model shall be reconsidered several times, one after each other; and development becomes a continual endeavor for improvement throughout its lifecycle. Never the less these two groups can be combined, in which iterative development process can be paused at a certain stage.

Requirement engineering always have to be early in the SDLC, that is why it is very critical process; and because it is human-centered in nature, any misunderstanding or error during requirements engineering can cause very expensive difficulties for the project later. Stakeholders might have several dispersed needs, their objectives could be different, uncertain, and sometimes conflict each other. Therefore, satisfying all these objectives and goals could occasionally not be feasible. The concern in requirements engineering is, how to find an engineering solution to control stakeholders’ requirements in and appropriate and cost-effective way which can then be analyzed later.

There are two main categories for software requirements according to (Leffingwell and Widrig, 2000): (1) functional and (2) non-functional. Functional requirements capture and describe system functionality, whereas non-functional requirements capture all other needs from software product such as quality, portability, performance, reliability and usability. Software development team usually considers that functional requirements are more important than non-functional because they describe how software should function. However, non-functional requirements are also as important as functional requirements, because software system functionality must be performed well with an acceptable level. This acceptable level is defined by non-functional requirements, which must be satisfied or the software is considered as failure.

There are several methodologies for performing requirements engineering, each methodology has different activities; for example in the methodology introduced by Nuseibeh and Easterbrook (2000), there are five core activities in requirements engineering as follow:

• Eliciting requirements

• Modeling and analyzing requirements

• Communicating requirements

• Agreeing requirements

• Evolving requirements

According to Pozgaj et al. (2003), requirements engineering methodologies can also be organized in three categories: (1) Methodologies for requirement discovery, (2) Methodologies for requirement organization, and (3) Methodologies for requirement change management. In requirement discovery process which is highly important, all set of requirements must be identified in order to produce software product which is enabled to satisfy customer needs. Requirement organization process will focus on requirements usage during SDLC; within this process, all requirements have to be continuously controlled during SDLC. However, Requirement change management is the process of handling the changes in requirement during all development phases continuously.

Requirements development during requirements engineering is a process of learning instead of a gathering process (Loconsole, 2004). For that reason it is very hard to identify exactly what a customer needs at the beginning stage of a software project; and even if all requirements are identified completely, requirement change is also possible during all stages in SDLC. The best way to ensure reliable requirement engineering is to carefully monitor and control all requirements throughout the software life cycle. Therefore it is also very important to realize the metrics of measuring the requirements.

Furthermore, defects in software applications are increasing and surveys show that the users are not satisfied by most of the software and they are far away from their expectations. Investigates in the reasons of this problems indicate the majority of this user’s dissatisfaction and the reason of project failure are errors in defining requirements (Hofmann and Lehner, 2001). One Software System develops base on the customer requirements and needs.

The future stage of software developing process defines by requirements specifications in the special form which designed for customer to explain needs and necessities for the software and how the software expected to work. Accordingly any contradictoriness and indefiniteness the system requirements lead to develop an unsuccessful software product.

Moreover, investigations on requirement engineering are still being performed by researchers on specific fields of software engineering (Sikora et al., 2012, Berntsson Svensson et al., 2009). However, despite of all research have been done on this area and investigation different strategies which address the requirements engineering process, even nowadays software engineers face this kind of problems. The issue, "most of the software product failures are attributed to unsatisfactory requirements engineering process" has being stated many times in numerous text books, articles, and papers for more than decades now (Duggan and Thachenkary, 2003, Hofmann and Lehner, 2001, Sikora et al., 2012).

Research Aim

In this research, we aim to investigate the scope of theoretical requirement engineering practices which are applied and used in practical software environments in the industries. Furthermore, the extent of theoretical requirement engineering principles and practices which are converted to practical requirement engineering in industries will be investigated. The scope of this research is to investigate the existing requirement engineering practices in Iranian software industries.

Research Objectives

In this research, we shall accomplish the following objectives to reach our research aims:

To inspect the current practical requirement engineering principles used by Iranian industries.

To assess the effects of implemented requirement engineering practices on them.

To identify the constraints which software engineers will encounter during implementation of requirement engineering practices.

Significant Contribution

The most significant contribution of this research is the empirically investigation of the gap among the theoretical requirement engineering and the modern practical requirement engineering in the software industries. Our work in this research will also contribute to the Software Requirement Engineering by identifying a set of constrains for implementing the requirement engineering practices in the industries. Furthermore, in this study, we are identifying which requirement engineering methods and practices are mostly practical and are applicable in the industries. Accordingly, the results of this study could be used as reference for deciding the next potential software requirement engineering research problems.

Research Methodology

According to Hasselbring and Giesecke (2006) ,there are four categories of research and experiment methods in software engineering which are Scientific, Engineering, Empirical, and Mathematical. In this section, we describe these four categories of research methods briefly, and then we will choose the most suitable research method for this project.

In scientific method the world need to be observed; then a model or a theory of behavior shall be proposed; and after measuring analyzing the hypotheses of the model or theory shall be validated; at last, this procedure shall be repeated if possible. Alternately, engineering method is performed by observing existing solutions; then a better solution shall be proposed which will be built or developed for measuring and analyzing. At last, this process shall be repeated until there are no more improves appear to be possible. Empirical method is slightly different; first, a model must be proposed, then statically or qualitative methods shall be developed accordingly; then the proposed model shall be applied to case studies to be measured and analyzed for validation; at last this procedure shall also be repeated. On the other hand, Mathematical method’s approach is different; first a formal theory or set of axioms shall be proposed, then the proposed theory have to be developed for deriving the results; at last these results shall be compared with empirical observation if possible.

Empirical study is one of well-known research methods for software engineering (Hasselbring and Giesecke, 2006). Hasselbring and Giesecke (Hasselbring and Giesecke, 2006) described empirical research as an observation of software development tasks in an experimental notion. An empirical study may consist of several research activities such as questioners, surveys, data analysis, case studies, experiments, quantitative studies, and qualitative studies (Kitchenham et al., 2002). An empirical research goal is to recognize the unknown information based on the existing hypothesizes, which always includes information gathering and systematic analysis on the gathered data.

Accordingly, we have found survey as an appropriate data gathering method in our empirical study. The survey will be used to investigate and gather the data from the extent of usage of the core requirement engineering practices. Moreover, we anticipate that a questionnaire based survey will help us to gather all the required information from the industry experts and professionals. A number of well-defined questions on the requirement engineering topic which considers the flexibility on analysis should be included in the questionnaire (Robson, 2002). For our empirical research purposes, we need to define a standardized questionnaire and choose a sample of respondents from the selected population group (Robson, 2002). Additionally, the sample of respondents will be chosen according to their position in software industry. Moreover, our empirical research used in this research includes four steps as follows:

Questionnaire design: designing a set of question that is able to capture our goals.

Survey distribution: distributing the questionnaires to the respondents.

Data analysis: analyzing the gathered data from survey.

Reporting: preparing the results of the analysis and reports.

These four steps shall be performed sequentially as they are shown in Figure 1. The procedures of these steps will be defined and described in the next phases of this research.

Figure : Survey research method

Expected Deliverables

The report prepared from our analysis on the gathered data from the industries is our final deliverable. This report is the result of our research; it will be validated and then delivered in our final thesis.

Expected Resources

Throughout this research, we will need to have access to various online databases such as IEEE eXplore digital library, Association for Computing Machinery Digital Library, Scopus, ScienceDirect, SpringerLink, and Web of Science. Furthermore, we need to travel to Iran at least for three months for the purpose of data gathering. We will contact the selected respondents, explain our research goals to them, and then ask them to help us in our research.