alexa

GET THE APP

Dersleri yüzünden oldukça stresli bir ruh haline sikiş hikayeleri bürünüp özel matematik dersinden önce rahatlayabilmek için amatör pornolar kendisini yatak odasına kapatan genç adam telefonundan porno resimleri açtığı porno filmini keyifle seyir ederek yatağını mobil porno okşar ruh dinlendirici olduğunu iddia ettikleri özel sex resim bir masaj salonunda çalışan genç masör hem sağlık hem de huzur sikiş için gelip masaj yaptıracak olan kadını gördüğünde porn nutku tutulur tüm gün boyu seksi lezbiyenleri sikiş dikizleyerek onları en savunmasız anlarında fotoğraflayan azılı erkek lavaboya geçerek fotoğraflara bakıp koca yarağını keyifle okşamaya başlar
A Review of Requirement Engineering Process Models
ISSN: 2168-9717

Journal of Architectural Engineering Technology
Open Access

Our Group organises 3000+ Global Conferenceseries Events every year across USA, Europe & Asia with support from 1000 more scientific Societies and Publishes 700+ Open Access Journals which contains over 50000 eminent personalities, reputed scientists as editorial board members.

Open Access Journals gaining more Readers and Citations
700 Journals and 15,000,000 Readers Each Journal is getting 25,000+ Readers

This Readership is 10 times more when compared to other Subscription Journals (Source: Google Analytics)

A Review of Requirement Engineering Process Models

Mudassar Mehmood* and Ijaz BB
Department of Computer Science and Information Technology, Pakistan
*Corresponding Author: Mudassar Mehmood, Department of Computer Science and Information Technology, Pakistan, Email: [email protected]

Received: 11-Jun-2018 / Accepted Date: 04-Aug-2018 / Published Date: 13-Aug-2018 DOI: 10.4172/2168-9717.1000215

Abstract

As we are living in the period of Computer Science and almost all human beings and the organizations are completely rely on software. The requirement engineering is very essential and crucial phase for success of any software engineering project. Requirements engineering literature presents some different models for requirement engineering process. These different types of models have range from linear to iterative in structure. We need to see different sources to find requirements. This paper consists of details study and comparison of different RE Process Models and Requirement Elicitation techniques. This paper involved the vital features of different Requirement Engineering Process models that help in the selection of suitable model for the Requirement Engineers and practitioners working in the industry. In this paper, “we propose an effective requirements engineering process model to produce quality requirements for software development.” This Paper also Focus on the giving a detailed view of Elicitation techniques and relative study including the characteristics and their strengths and weakness. Some strengths and weakness found during detailed study are also ordered and scheduled that is also the helpful for the right selection of RE Process model.

Keywords: Requirement engineering process models; Requirement engineering elicitation tools; Comparison of RE models

Introduction

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.

Literature Review

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.

architectural-engineering-previous-study

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.

architectural-engineering-work-macaulay

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.

architectural-engineering-loucopoulos-karakostas

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.

architectural-engineering-kotonya-sommerville

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.

architectural-engineering-Shams-Ul-Arif

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.

architectural-engineering-work-pandey

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.

architectural-engineering-previous-study

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.

Sr. No. SStrengths Weakness
i.
  • It is highly useable for Small Level projects
  • This model lacks the Validation Activity
 
  • This model lacks the Feed Back Activity
 
  • This Model also called as base for the
other methods.
  • This model lacks the support for dynamic requirements.
 
  • This model lacks the support for Effort management.
 
  • This model lacks the policies for performing Risk Management.
 
  • This model lacks the activities of requirement Pre Processes.
 

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

Sr. No. Strengths Weakness  
ii
  • This model Provide the Support to
analyze the feasibility of system.
  • This model does not support the reverse Engineering process.
 
  • This model provides the facility of
validating customer requirements.
  • This model lacks the policies for performing Risk Management.
 
  • This is linear model so, It was not
support Overlapping in activities.
  • This model lacks the support for Effort Management.
 
  • This model lacks the Feed Back Activity
 
  • This model lacks the activities of Requirement Pre Processes.
 
  • This model lacks the facility of requirement changing.
 

Table 2: Macaulay linear requirements engineering process model.

Sr. No. Strengths Weakness
iii.
  • This Model Provide support for User feedback.
  • This model lacks the policies for performing risk Management
  • This supports the prototyping.
  • This model lacks the support for dynamic requirements
  • This model lacks the support for Effort management
  • This model lacks the activities of requirement Pre Processes.

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

Sr. No. Strengths Weakness
iv
  • This Model Provide the facility of
Contribution of active user.
  • This was lack the computing of effort in Starting Requirement phases.
  • This Model provides the means of
Client’s feedback.
  • This model lacks the activities of Requirement Pre Processes.
  • Faults can be found in the early stages
of software development.
  • This model lacks the process of requirement Prioritization.
  • This model supports the policies for
Performing Risk Management.

Table 4: Spiral model.

Sr. No. Strengths Weakness
v.
  • This Model provides the means of client’s feedback.
This model lacks the activities of requirement Pre Processes.
  • Faults can be found in the early stages
of software development.
This model lacks the process of requirement prioritization.
  • This model supports the policies for performing Risk
This model lacks the facility of selecting appropriate selection of elicitation technique.
  • Management The major aspect of this model is reckoning of ROI.
This will lack the facility of measuring accuracy of cost used to fix a bug.

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

Sr. No. Strengths Weakness
vi
  • This Model Provide the facility of contribution of active user.
  • This model lacks the support for Effort management.
  • This Model provides the means of client’s feedback.
  • This model lacks the activities of requirement Pre Processes.
  • This model Provide the facility of changing requirement.
  • This model lacks the policies for performing Risk Management.
  • For the software development this provides the means of requirement management and requirement planning.
  • This model lacks the facility of selecting appropriate selection of elicitation technique.

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

Sr. No. Strengths Weakness
vii. This model Provide the facility of
changing requirement.
This model lacks the support for Effort Estimation.
This model provides the facility of
requirement prioritization.
This model lacks the activities of requirement Pre Processes.
This Model Provide support for User
feedback.
This model lacks the policies for performing Risk Management.
This model lacks the activities of requirement documentation.

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

Sr. No. Strengths Weakness
viii This model combines both parallel and
serial prototyping.
Due to the large time involvement in feasibility phase required a lot of time for the other development phases.
This model runs the feasibility study
along with other phases.
This model lacks the support for Effort Estimation.
This model focuses on the vital
Requirements.
This model lacks the activities of requirement Pre Processes.
This model lacks the policies for performing Risk Management.
This model lacks the facility of selecting appropriate selection of elicitation technique.

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.

Characteristics Cost benefit analysis (TCBA) Macaulay Linear Requirements Engineering Process Model Iterative Requirements Engineering Process Model Spiral Model Tools Cost benefit analysis (TCBA) An Effective Requirement Engineering Process Model P.B.F. Arts Requirements Development & Management Model In Highly Turbulent Environments Bee Hive Model
linearity ü ü X X X X X X
Support for changing requirements X X X ü ü ü ü ü
Iterative in nature X X ü ü ü ü ü ü
User feedback X X ü ü X   X X
Support for reverse engineering X X X ü X X X X
Risk assessment X X X ü ü X X X
Criteria for application X X X X X X X X
Specific elicitation technique                
Requirements preprocessing X X X X X X X X
Requirements prioritization X X X X X X X ü
Effort estimation X X X X X X X X

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

Results and Conclusion

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.

References

Citation: Mehmood M, Ijaz BB (2018) A Review of Requirement Engineering Process Models. J Archit Eng Tech 7: 215. DOI: 10.4172/2168-9717.1000215

Copyright: © 2018 Mehmood M, et al. This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Select your language of interest to view the total content in your interested language

Post Your Comment Citation
Share This Article
Article Usage
  • Total views: 9932
  • [From(publication date): 0-2018 - Aug 12, 2022]
  • Breakdown by view type
  • HTML page views: 9279
  • PDF downloads: 653
Top