Journal of Architectural Engineering Technology
Open Access

Generally the Requirements are the definition of desired features or capabilities of any proposed system. It is highly accepted in the whole software development industry that the requirement engineering is critical in success of any project [1]. Software systems are subjects to security threats which may influence the organization assets. The security requirements are very important which undergoes at the beginning of the development of the phase. Some security threats are technical rather than social, as they define the interaction between social actors like human and organization. Also explain the dependencies of actors. In terms of security hacker always in search of weakness by performing unnecessary actions. The fitting of software after make public is very costly. It is obvious that a better way to achieve secure software is to incorporate security in the software starting from the beginning of the development process, an effective way of development secure software is to educate and train software developers on artificial software security issues [2].”Software developers should gain more software security knowledge and know how to follow the best practice of developing security software through various educational and training programs [3]. It is shown from the studies that there are multiple Challenges for Security Requirement Engineering which are may as follows:

• Mostly actual stake holders are not included or consulted at the stage of requirement identification [4].

• Requirement analysis phase is limited to the functional requirements and mostly non function requirements are ignored at this stage [4].

• The quality and design requirements are not effectively included at the requirement analysis phase [4].

Requirement Engineering is a set of different process that works at different levels, which are incorporated at individual and organizational level Projects [5]. Security Requirement Engineering deals with specification of security requirements for the system [6]. It is understood that it is very necessary that team must have a good understanding of Requirement Engineering process Models and their strengths and weakness for any quality software development. This Paper focuses on the detailed study and comparison details of different Requirement Engineering Process models defined from the existing literature review and defined some Pros and Cons that will be very helpful for the professionals for the selection of appropriate models [7]. This paper focuses on the giving a detailed view of Requirement Engineering Process models, and Elicitation techniques and comparative study including the characteristics of both and their strengths and weakness [8]. The Rest paper contains following sections: The Section two contains detailed survey of the RE Process models the next section three contains the strengths and weakness of the Process models which are discussed in the third section and finally in section 4 we have comparison of the different Process models. Section 5 contains the conclusion of the paper along with future wok and then section contains acknowledgement and finally references.

Requirement engineering phases

The Software Engineering Community (SEC) identifies the following activities as majors in the process of Requirement Engineering [8]:

1. Background Research

2. Requirement Elicitation and analysis

3. Requirement Prototyping

4. Requirement Verification and validation

5. Requirement Specification.

Requirement engineering process model

In our wish to enhance the learning and understanding of different

“Requirement Engineering process models” that already exists we find and explore the some standard “Requirement Engineering process models” and some other models that were presented by the other researchers that specify the behavior and working of models [7].

Detail description of RE process models

A. “Kotonya and Sommerville linear requirements engineering process model”

“Kotonya and Sommerville” “present this Abstract linear “Requirement Engineering Process Model” in 1980. This model incorporates the repetition between the different Requirement Engineering activities [7]. These activities are as follows:

• Requirements elicitation,

• Requirements analysis and negotiation,

• Requirements documentation,

• Requirements validation.

This model defines that the all these stages in this model overlaps repeatedly during the execution of the Process [8]. This model includes the iterations which used for validation of requirement engineering repeatedly. This process of Iterations continues as the all stakeholders are agreed and the finally system specification document is achieved. This model is highly useable incase where the all the requirements are highly accurate or called as pin point accuracy and these are validated through potential stakes a number of times [9] and Figure 1.

Figure 1: From the work of previous study [11].

B. “Macaulay linear requirements engineering process model”

This is a pure linear “Requirement Engineering Process Model” suggested by Macaulay as in Figure 2. It does not contain and support the overlapping of requirement engineering activities incorporated in RE Process. This model contains five stages which are sequentially arranged as shown in the figure below [9]. This Model comprises of following stages:

• Problem analysis

• Concept

• Feasibility study analysis and modeling

• Requirement documentation.

Figure 2: From the work of Macaulay.

Macaulay stated that this model is the RE Process is depend on the Relationship of Supplier and the customer [7]. It is the most simple RE model which is mostly used for the Small level and less complex projects. This is not a good approach for the large projects [9].

C. “Loucopoulos and Karakostas iterative requirements engineering process model”

This model is iterative as well as cyclic model presented by “Loucopoulos and Karakostas”.This model shows the connection between different RE phases as in Figure 3. There are following phases [7,10]:

• Requirement elicitation

• Requirements specification

• Validation to the problem domain.

Figure 3: From the work of by Loucopoulos and Karakostas.

Requirement engineering performed in this model is consists of several iterations and this is suitable for those systems which uses the approach of delivery by version by version which may be called as iterative development [11].

D. “Spiral model of requirements engineering process”

This Model is prosed by by Kotonya and Sommerville in 1998 as in Figure 4. This model operates in Spirals. Requirement engineering process completed in one spiral round in depends on the product under development. Every Spiral round is divided in two four quads which are as follows:

• Specification elicitation,

• Requirements analysis and negotiation,

• Requirements documentations,

• Requirements validations.

Figure 4: From the work of Kotonya and Sommerville.

The major Characteristic of Spiral model is easy handling of risks [12]. Such as:

• Speciation delay

• Requirements change

• Low ROI.

These risk badly the effect the Quality as well as cost of the project. New concepts in the Spiral model are that the design of system also created on the base of Requirement [9].

E. “Mr. Shams-Ul-Arif, Mr. Qadeem Khan, S. A. K. Gahyyur Tools Cost Benefit Analysis (TCBA) Re Process Model”

This Requirement Engineering model proposed by Shams-Ul-Arif, Mr. Qadeem Khan, S. A. K. Gahyyur as in Figure 5.

Figure 5: From the work of Shams-Ul-Arif, et al. [11].

This model proposed two processes which are as follows:

• If the users are in excess then this model proposed to use the method of surveys for the requirement elicitation.

• If the users are in less size then this model proposed to use the method of interviews for the requirement elicitation.

• The most special characteristic is its ability of “Return on Investment (ROI)” before to the start of the project i.e. [6].

• Computation of costs involving in staff payments

• Software/Hardware

• Maintenance

• Recreational

• Library

Networking

• Employee pensions

• Health facility.

The Risk management and customer feedback is a plus point of this model [6].

F. “Dhirendra Pandey and U. Suman an effective requirements engineering process model”

The model is presented by Dhirendra Pandey and U. Suman as in Figure 6. This Model made a relation between the Requirements Engineering Process and the Software development process. For the development of a high quality software product it introduces all important “requirement engineering process which is:

• Business requirements

• Customer requirements

• User requirements

• Constraints

• Security requirements

• Information requirements

• Standards.

Figure 6: From the work of Pandey et al. [6].

To address the problem of execution requirement this method includes the features of requirement planning phase and requirement management phase [13].

G. “P.B.F. arts requirements development and management model in highly turbulent environments”

This model includes three main phases as in Figure 7 which are as follows:

• Intake Phase

• Startup Phase

• Initiation Phase.

Figure 7: From the work of previous study [6].

This model recommends different three techniques for all the three phases listed above which are as follows:

➢ In the Startup Phase Brainstorming technique is used for Requirement Elicitation

➢ In the initiation phase Prioritization the requirement [14].

H. “K S Swarnalatha, G.N Srinivasan, and Pooja S Bhandary Bee Hive Model”

This model is proposed by “K S Swarnalatha, G.N Srinivasan, And Pooja S Bhandary”. This model make the process of requirement elicitation speedy to design the prototype. This model consists of following phases [12,15]:

• Background Research

• Elicitation, Analysis

• Prototyping

• Verification, Validation

• Requirement Specification.

Strengths and weakness of models: During the detailed study of “Requirement Engineering Process models” we found the following deferent strengths and weakness in the models [6,10,12-15] as in Tables 1-8.

Table 1:  Kotonya and Sommerville linear requirements engineering process model.

Table 2: Macaulay linear requirements engineering process model.

Table 3: Loucopoulos and Karakostas iterative requirements engineering process model.

Table 4: Spiral model.

Table 5: The Tools Cost Benefit Analysis (TCBA) RE process model.

Table 6: An effective requirement engineering process model by Dhirendra Pandey.

Table 7: P.B.F. arts requirements development & management model in highly turbulent environments.

Table 8: Swarnalatha, Srinivasan, and Pooja S Bhandary Bee Hive Model.

Comparison of models of RE models: We find a number of “Requirement Engineering process Models” in existing literature. Every model contains some strengths and weakness as we discuss those in the above section named “strengths and weakness”. Earlier we have studied all the models with respect to the requirement phase. Now we will shape the study in a tabular shape as in Table 9. For the comparison we use the following parameters [12,16]:

• Linearity

• Support for changing requirements

• Iterative in nature

• User feedback

• Support for reverse engineering

• Risk assessment

• Criteria for application specific elicitation technique

• Requirements preprocessing

• Requirements prioritization

• Effort estimation.

Table 9: From the work of Mona Batra and Dr. Archana Bhatnagar.

Requirement engineering tools/techniques

Requirement Engineering is the process of understanding of the actual functionality needed from the system. It is the Continues interactions from the stakeholders to know what they want exactly from the system. “Requirement Engineering” is a complex process and it includes following stages/activities [9]:

• Seeking

• Determining

• Learning

• Acquiring

• Discovering

• Elaborating requirements.

It is always impossible to get Quality requirements form a single source. We need to consult different sources to find requirements. We need to involve personals from the different fields to find a set of quality requirements. To get high quality requirements one must need to find and involve the actual user and get these requirement through the process of Requirement elicitation. There is a technique named as prioritization which used to compare the requirements get from different sources. There is no proficient technique for all the cases. May be we find one technique best for a project butt it become useless when we moved on to another project. There may be some weakness and strengths of any technique so any weakness found in one technique is covered by using another technique parallel to the first one used. It is found from the studies that a number of projects failed only because inappropriate selection and use of elicitation technique [8]. There are different tools and techniques available and used for the process of requirement elicitation. The selection of any Technique is purely dependent of the type of Project and its complexity. We are going to discuss following Tools / Techniques:

1. Interviews

2. Surveys

3. Questionnaires

4. Task Analysis

5. Domain Analysis

6. Introspection

7. Repertory Grids

8. Card Sorting

9. Class Responsibility Collaboration

10. Laddering

11. Group Work

12. Brainstorming

13. Joint Application Development (JAD)

14. Requirements Workshops

15. Ethnography

16. Observation

17. Protocol Analysis.

This section contains the description of above listed:

“Requirement Elicitation Techniques” and their Strengths and weakness also the process and detail for the selection of particular tools [9].

Interviews: This is the mostly commonly used technique which is used from early ages for the requirement elicitation. It is also called as the process of face-face conservation among the client and the requirement engineer [17]. Interview also called as “A verbal exchange of information between two or more people for the principle purpose of one gathering information from the other/s (Pole and Lampard 2002)”. Types of interview are as follows [9]:

• Structured

• Semi Structured

• Unstructured Strengths of this technique

• To Collect the Rich data having details

• To collect information that helpful in designing of a survey

• To get a holistic view of system under consideration. Weakness of This Technique

• It’s really a tough and time consuming task to collect data in large form from a number of stake holders. It’s really tough to collect a big amount of data in rapid way.

Surveys: This technique is used mainly where we have large number of peoples involved or mostly for the “market driven products”. This is used mostly for the surveys such as Charity or Census.

Strengths of this technique:

• This technique is helpful for collecting of information samples from a large scale.

It’s any quick an easy way for information collection if it is design correctly.

• It is relatively a cheap way.

Weakness of This Technique:

• In this process we lack the Rich Collection of data.

• It is not suitable to get a holistic view of system under consideration.2.

Questionnaires: It is the simplest tool used. This will contain the open or closed questions. It is useful for the rapid response. In order to get Rapid response must make the questioners clearly, concisely with clear definitions. Questionnaire is always problem focused. It’s good to avoid the redundancy in the questions [18].

Strengths of this technique:

• It is efficient way to get information from a multiple stakes.

• Commonly Questionnaires consider as useful tool for build foundation for requirement elicitation.

Weakness of this technique:

• This Process lacks the facility of more discussion on the same topics.

• If we get information once it’s tough to find or correct misunderstanding.

Task analysis: “This technique uses the working style in hierarchical style. In this technique main task and sub task are divided in a hierarchical way. It is also known as tree technique as this works starts from top of the tree and comes down till the roots”.

Strengths of this technique:

• This technique provides the interaction both for the system and the user.

• This task analysis used by manager to analysis the tasks.

Weakness of this technique:

• This technique requires extra effort in comparison with interviews.

Domain analysis: This technique involves the domain knowledge also called as background knowledge of the domain for which the system is being built. This technique is mostly used when we are going to replace the existing system.”

Strengths of this technique:

• This technique is very useful for the Requirement elicitation also include the design document.

• This technique always used as an extension of other technique as an input.

Weakness of this technique:

• It is complex to find the all hidden details of the Domain.

• There is need of highly professional staff and experienced to perform the domain analysis.

Introspection: As it is clear from the name that introspection, it is the process of gathering information before moving for any other technique. It is preprocessing to start any “Elicitation Technique” for the requirement gathering [9].

Strengths of this technique:

• It works as Parent technique for all other techniques.

• It is helpful to start and work with any other technique.

• It is mainly free technique with respect to cost factor.

Weakness of this technique:

• To perform this technique analyst must have core knowledge of the business process.

• This technique needs a highly experienced analyst.

Repertory grids: This technique used to make a grid around the requirements for assigning the numbers to requirements.

Strengths of this technique:

• It is used to find the differences and similarities between requirement information.

• In this Technique traceability is quite easy.

Weakness of this technique:

• It is works with limited framework in case of complex requirements.

Card Sorting: In this technique we provide different cards to customer and the responsibility of sorting cards is with the customer accordance with entities of domains [19].

Strengths of this technique:

• The main task performed in this technique is the prioritization.

Weakness of this technique:

• Analyst need to be a highly experienced background.

• The group work is most preferable than card sorting.

Laddering: This is a set of series of simple question developed to ask from the customer / client/Stakeholder.

Strengths of this technique:

• This provides a very close contact to among stake holder and requirement engineer.

These techniques arrange the requirements of the customer in proper way.

Weakness of technique:

• This technique is not recommended in case of large number of requirement or for a large scale system.

• The maintenance of requirements becomes very hard when you come to the operations of deletion.

Group work: In this technique more than one stakeholder are involved and a group meeting is conducted to elicit requirements.

Strengths of this technique:

• The conflicts occur due to the different requirement this is useful in resolving the issue.

• This process supports the suggestion from all members who joined the group.

Weakness of this technique:

• This technical need a high effort.

• Some time there is a possibility that all stakes are not available at the same time.

Brainstorming: “This Technique involves the informal discussion of stake holders and they put their input on the specific topic that is started in the discussion [20].

Strengths of this technique:

• This useful in means of where multiple stake holders comes up with their ideas.

• Every requirement is discussed and finalized.

• This is results in innovative ideas.

Weakness of technique:

• This technique is not usable to discuss in major issues.

Joint Application Development (JAD): This technique is used where we have a large number of stakeholders involved. This technique commonly used in the agile methodology where a number of requirements elicited quickly. Discussion made in this technique is useful in providing new ways to solve the problems [11].”

Strengths of this technique:

• This technique provides the means of decision making rapidly and moving towards the solution.

• This will handle those requirements that are changing rapidly.

• This will provide a well-structured and managed approach.

• It provides the means of direct communication among all stakeholders.

Weakness of this technique:

• Sometime this technique failed to produce the exhaustive validation in a limited time.

• Experts working with this technique are must have a strong background knowledge of the domain.

Requirements workshops: Requirement Workshops is the name of collection of all the meetings that are arranging for the purpose of gathering requirements.

Strengths of this technique:

• This technique is better than “brainstorming and group interviews” as these results in a good requirement gathering.

• Mostly the requirements remain unchanged if these are elicited using this technique.

• The main advantage is that this technique is suitable for the projects of larger size and complex.

Weakness of this technique:

• With reference to the time and cost this technique is very costly as compared to other techniques.

• It is not feasible for the small level projects.

• The requirements gathering process is relatively slow in this process.

Ethnography: “The name of technique “Ethnography” relates to the meaning that it relates to the term what the peoples understand from the problem. In other words this is what the peoples understand of the problem and what they think regarding the solution. In RE context what the peoples need from the software [16].”

Strengths of this technique:

• This technique is mostly used in gathering of quality related requirements.

• This is very effective incase when we have to consider the social factor in the problem solution.

Weakness of this technique:

• This technique failed badly when there are different peoples came with different social issues.

• It is a very tough task to find the social requirements belonging to different peoples.

Observation: “It is the requirement gathering process where the Requirement Engineers are supposed to visit that place number of time to find the domain requirements are called as Mutable requirements. This technique is mostly used in collaboration with other Elicitation techniques [9].”

Strengths of this technique:

• As these requirements gathered by this techniques are directly collected by the Requirement engineer by their visit of that particular domain so these requirements are highly authentic. It’s a post process mainly uses for the validation of requirements gather by using other techniques.

Weakness of this technique:

• As the travelling costs are too high so this results in a high cost.

• Mostly results in gathering of wrongly requirement as one cannot judge these requirements properly by just visiting and watch them working.

Protocol analysis: This is discussion of all possible stakeholders in which they are talk and discuss the requirements loudly.

Strengths of this technique [20]:

• This provides the analyst working on a specific project with information that is specific to the system processes.

• This provides all the stakeholders to involve and participate.

Weakness of this technique:

• Sometime we cannot get the true requirement picture by this technique.

• As all the participants are talking loudly so there are chances of conflicts among stakeholders. The selection of tool always depends upon the two factors:

• Type of the Project

• Size of the project

• Complexity of Project.

Motivation

The major concern of this research is to do a review of different Requirement Engineering Process models along with their strengths and weakness and Different Requirement Engineering Tools along with their Strengths and weakness to help the Professionals in the selection of better set of Process model and Requirement engineering tool for their project.”

In this paper we acutely clarify and discussed “requirement engineering process models” their “Strengths and weakness” along with the Requirement Engineering Tools and their details along with the “strengths and weakness” of these tools followed by the process of choice of suitable tool. Besides this we will do the comparative study of these models and shape this study in a tabular form. This is also helpful for the selection of any appropriate “Requirement Engineering Process model”. Multiple research areas are accessible in this paper on the basis of existing literature which helps other researchers to extend the research. The right selection of Process Model along with Right technique is supportive for any professional in terms of Cost and time.