Purification of Requirement Engineering Model for Rapid Application Development Shoaib Hassan1 , Usman Qamar2 , Muhammad Arslan Idris3 1, 2, 3
College of Electrical and Mechanical Engineering, National University of Sciences and Technology, Pakistan
[email protected] [email protected] [email protected]
Abstract— Due to shortage of time, most of the software organizations are shifting their projects to rapid application development’s life cycle. But main problem is that rate of projects failure is increasing day by day. According to Standish group report, success rate of projects is only 16.2%. The main reason of project’s failure is poor requirement engineering. The main objective of carried research is to purpose a model for requirement engineering process of rapid application development. The proposed model has 7 steps. Our proposed model specifies techniques for each step of requirement engineering process. Our proposed model also introduces new stages of conflict management by win-win approach and requirement prioritization by card sorting in requirement engineering model for rapid application development’s life cycle. Validation of purposed model has been done by survey from 50 experienced software professionals of 20 different organizations. Survey proved that our purposed model has more customer’s favor then traditional requirement engineering model for rapid application development. Our proposed model is fully customer’s oriented. It is more time effective, cost effective, well managed and efficient than traditional model.
A. Activities in Requirement Engineering x
x
Keywords—Requirement Engineering, Rapid Application Development, Conflict Management, Requirement Management
I. INTRODUCTION
x
Requirement Engineering is the main branch of software engineering that deals with problems, goals, constraints and functions of real world [1]. It also define relationship among these factors to give specification of behavior of software. Requirement engineering term was firstly used by TRW Company in 1979. But it was came into use in 1990’s when peoples had done research and publications in this field. Requirement engineering is most important task for success of any project [14]. According to Standish report, only 16.2% projects were successful. The main reason of project’s failure is poor requirement engineering. Good requirement engineering process causes the project’s success. As requirement engineering’s error cost is 100 times greater than the cost of error that occur during the development phase [4]. So, it also save a lot of money of project’s development phase. We can improve our quality of product by improving requirement engineering process [2]. Requirement engineering is not a single step process. It is a combination of five major steps. These five steps are given below.
x
____________________________________ 978-1-47-- /1/$31.00 ©201 IEEE
x
Requirement Elicitation is first step of requirement engineering process. Requirement elicitation means collecting requirements from different stakeholders. This step gives raw material to all other activities of requirement engineering. The main aim of requirement elicitation is get knowledge about the problem of customer [5]. Better understanding of requirements will cause the success of requirement elicitation [32]. There are many techniques of requirement elicitation that will discuss in next section. Requirement Analysis is second step of requirement engineering process. Requirement Analysis means to analyze the requirements for ensuring their completeness and consistency. Completeness means requirements are complete in all aspects and there should be no confusion in them [2]. Consistency means requirements should not be conflicted with one another. In analysis phase, we also negotiate to remove conflicts between different stakeholders [1]. Different techniques of requirement analysis will discuss in next section. Requirement Specification is third step of requirement engineering process. It is a blue print for software development process. It control both the processes of specification and validation [5]. It is a document in which we have all the elements of software. It is like a contract between software team and customer on what the software should do. This document help us to estimate time, cost and effort for the project. Requirement Verification and Validation is fourth step of requirement engineering process. Requirement verification and validation proves that our product meet the customer’s needs [3]. Validation means that all stakeholders are agree on requirement specification document and problem has properly detected [1]. This is most important step of requirement engineering process. If requirements are properly validated then we can reduce requirement error cost [6]. Requirement Management is the last step of requirement engineering process. Requirement management means managing the changes in
ethnography and focus group [6]. Betty H.C and Cheng also suggested user centered design, reuse requirements, scenarios and questionnaire for requirement acquisition in rapid application development [4].
requirements [1]. Management means adding, deleting or updating requirements and fixing the errors. In this step, we ensure that present state of requirement will available at all the time [21]. This process continues in throughout requirement engineering process. We can also define requirement management as process of identifying and documenting the links of traceability among different requirement objects [3].
Requirement analysis has so many techniques. Bashar Nuseibeh & Steve Easterbrook suggested goal oriented analysis, fault tree analysis, card sorting and state machine for requirement analysis [1]. Ian Sommerville and Pete Sawyer suggested conflict management and viewpoint based analysis for requirement analysis in their paper [2].
B. Rapid Application Development It is a software development life cycle that permits organization to develop product faster while reducing cost and time [8]. This software development life cycle focuses on developing prototype model faster to get feedback from customer [9]. Prototype may be some model, some interface or some sub system. Rapid application development was firstly introduced by James Martin in 1980. According to James Martin rapid application development has four stages. x Requirements planning is first stage of James Martin’s model. At this stage, we take requirements from customer and plan all requirements. Make ensure that all requirements are correct, complete and consistent [7]. x Design is second stage of James Martin’s model. In design phase, we prepare design of system by analyzing the requirements. Make ensure that design is according to requirements. Design and construction tasks are working parallel. x Construction is most important step of this model. At this stage, we implement our design. Coding should be according to design [7]. x Cutover is final stage of this model. At this stage, we do testing. Maintenance and deployment are also in this phase. Rapid application development life cycle has more features than other development life cycles. Its silent features are given below. x Cost Effective x Time Effective x Fast Software Development Life Cycle x Life cycle consumes 60 to 90 days x Achieves High Customer’s Satisfaction x Good Risk Management x Reduce Developer’s Effort
Souhaib Besrour, Lukman Bin AB Rahim, P.D.D.Dominic suggested some techniques for requirement documentation in their paper [10]. Their suggested techniques are software requirement specification, structured natural language specification, decision table based specification and DIRT. Prototyping, requirement reviews, requirement checklist and test case generation are some validation techniques that were described by Ian Sommerville in his book titled “Software Engineering” [11]. Different models are introduced for requirement management. Zahoor Ahmed, Usman Qamar introduced requirement classification model for requirement management [13]. Olsen’s model, Ince’s model and seven stages change management model were also introduced for requirement management. B. Traditional Requirement Engineering Model for Rapid Application Development Traditional requirement engineering model for rapid application development suggested by Rajib Mall in his book titled “Fundamentals of Software Engineering” has following steps. x
Firstly, elicit requirements by any requirement elicitation technique. No specific technique was suggested for requirement engineering model of rapid application development.
x
At second step, document all those requirements by software requirement specification technique.
x
At third step, build prototype that should be according to documented requirements. Prototype may be some model or interface.
x
At fourth step, validate the prototype with customer. Customer checks either prototype reflects his needs or not. If customer accept prototype then requirement engineering process will complete. Otherwise we move to requirement management phase.
x
At fifth step, manage requirements by any management technique. No specific technique was suggested for requirement management in requirement engineering model for rapid application development.
II. RELATED WORK A. Requirement Engineering Techniques As we discussed before, requirement engineering is a combination of many steps and each step has many techniques. Selection of appropriate technique is very necessary for success of project. There are some factors like project size, project complexity, project time, project cost and project scope that cause selection of any specific technique. Organizational factors also cause the selection of techniques. Malcolm Eva suggested some requirement elicitation techniques like joint application development, brainstorming, interviewing,
III. PROPOSED METHODOLOGY
Requirement Elicitation
There are many problems in requirement engineering model for rapid application development as discussed before. There is no clarity of any task in requirement engineering process. Before doing any purification in requirement engineering model for rapid application development, we should focus on its architecture. Rapid application development is defining its meaning itself. Rapid means faster or immediately. So, it is a life cycle in which application develops faster than all other life cycles.
Requirement Documentation
Requirement Management
Build Prototype
Customer Rejection
Rapid application development is mostly famous in foreign countries. But now a days, failure rate of rapid application development based projects is increasing day by day. Out of 100 only 20 projects become successful. According to Standish group report, the main reason of project’s failure is poor requirement engineering. If requirement engineering is not good then project will not meet customer’s needs. There are a lot of problems that we are facing in requirement engineering model for rapid application development as discussed before. To solve these problems, we have proposed a purified requirement engineering model for rapid application development. Purification clears the picture of requirement engineering model for rapid application development’s life cycle. In purification of requirement engineering model, we specify all the techniques of requirement engineering steps by doing literature review and research. The proposed model consists of seven steps which will be discussed. Our proposed purified requirement engineering model for rapid application development based projects is given below.
Prototype Validation Customer Acceptance
Fig. 1. Traditional Requirement Engineering Model for Rapid Application Development
There are so many problems in traditional model. Some problems are given below. x
The main problem in requirement engineering model for rapid application development is poor requirement elicitation technique. Rapid application development is a fast development life cycle. So proper technique is required that elicit requirements more efficiently.
x
There is not any requirement analysis step in requirement engineering model. As in rapid application development, we have not clear requirements. So there is a lot of chance of requirement ambiguities and incompleteness. There is no conflict management mechanism in traditional model.
x
x
Requirement Elicitation by Joint Application Development
There is no mechanism of requirement prioritization in traditional requirement engineering model for rapid application development based projects. Before building prototype, we need requirements which have high priority.
Requirements Change Management by Requirements Classification
There is no proper approach for managing the changes in requirements. When customer give feedback about prototype then there is a high need of proper mechanism to manage those changes. Rapid application development has requirement management phase. But this phase is not so clear. Traditional model does not specify how to manage those changes.
Customer Rejection
Prototype validation by Customer
Conflict Management by win-win approach
Requirements Prioritization by Card Sorting
Requirements Documentation
Building Prototype
Customer Acceptance
Due to these problems, there is a high need of proposing a model that specifies each step of requirement engineering process. There is a high need of purification in each step of traditional requirement engineering model for rapid application development based projects.
Fig. 2. Purified Requirement Engineering Model for Rapid Application Development
This approach is very useful because all parties are happy in it. As JAD provides a collaborative environment to elicit requirements so it is necessary to use collaborative approach for managing conflicts. Because win-win approach also encourage collaboration among different stakeholders. And this approach also removes biasness because all parties are satisfied from the requirements.
A. Steps in Proposed Requirement Engineering Model Our proposed purified requirement engineering model for rapid application development has following steps.
x
x
Requirement elicitation is first and main step of requirement engineering. This is most important step in rapid application development life cycle because prototype depends upon it. There are many techniques for requirement elicitation, but we suggest JAD (Joint Application Development) for eliciting requirements in rapid application development’s life cycle. JAD is workshop of 20 to 30 team members. Stakeholders from all domains are present in JAD. In JAD, each stakeholder define his requirements. JAD covers all the requirements from different domain stakeholders. JAD has more usability than any other requirement elicitation technique. Using JAD as requirement elicitation technique will also help us to gather requirements from non-educated people. JAD brings all stakeholders and organization team on one platform. JAD will remove all the ambiguities about requirements. It will save a lot of time of organization. Usually rapid application development based projects are very complex and we have very less time to develop the system. In this situation, JAD is a right option. JAD is faster than other requirement elicitation techniques. So, it best suit with rapid application development’s life cycle. After eliciting requirements by JAD, there is a high need of analyzing the requirements. Analyzing the requirements is necessary for ensuring requirements completeness and consistency. Our traditional requirement engineering model for rapid application development has no requirement analysis phase. But for ensuring better quality of product, requirement analysis is necessary phase. We have many requirement analysis techniques but we choose conflict management for our proposed purified requirement engineering model. Conflict management is most common and simple technique for analyzing the requirements. In conflict management, we manage all the conflicts of stakeholders. The main reason of choosing conflict management technique for rapid application development’s life cycle is high risk of conflicts. Conflict management will manage all the conflicts that were produced by JAD. Removing conflicts is very necessary for building prototype. Because if we build prototype on the basis of conflicted requirements then customer will not satisfy from prototype. We proposed winwin approach for conflicts management in proposed purified model. In win-win approach, we define each win condition of each stakeholder. Then we make an alternative solution which meets all stakeholders’ needs. We make collaboration among all the parties to agree on a single solution.
x
After removing all the conflicts of requirements, there is a high need of prioritizing the requirements. Traditional requirement engineering model for rapid application development has not any requirement prioritization mechanism. But there is a high need of requirement prioritization in this life cycle. Because we want to make a prototype. And in prototype, we firstly show the major functionalities of the system. For this, we should prioritize requirements. We use card sorting for prioritization. Card sorting is simplest technique of prioritizing techniques. It also helps us to compare the priorities of different stakeholders. In card sorting, we write all the functionalities of the system on individual cards. Then, pass the cards to everyone in conference room. Every stakeholder writes priority on the top of the cards. After two to three cycles, all cards have some priorities. Collect all cards and make spreadsheet to analyze the data. After analyzing all the data, prioritizing functionalities on which all stakeholders will agree. This technique is most collaborative and customer’s oriented technique than others.
x
After prioritizing requirements by card sorting, there is a high need of documenting those requirements in a well-mannered way. Documentation makes an agreement between stakeholder and organization. There are many techniques for requirements documentation like decision table based specification, software requirement specification natural language specification etc but we suggest software requirement specification for documenting requirements. Traditional model also used this technique for documentation.
x
Prototype building is main task of rapid application development’s life cycle. Due to prototype development, it is often called prototyping model. Prototype is an executable model that reflects the original system. In prototype development, we firstly build major functionalities of the system. At this step, requirement prioritization gives us benefit of providing major functionalities. So using JAD, win-win approach and card sorting will help us to make better prototype which reflects the real customer needs. Prototype building process is same in traditional model and our proposed model.
x
x
TABLE I.
Validation is most important step in any development life cycle. In RAD, prototype validation is very necessary for success of final product. In RAD when we do validation of our prototype, customer check the prototype with documented requirements. If prototype matches with requirements then prototype will valid and we move towards our design phase. But if customer rejects prototype and ask for enhancements in prototype then we move forward to requirement management. This step is same in traditional model and our proposed model.
Step #1
Requirement Elicitation
If customer rejects prototype then we move to this step. If customer wants changes or enhancements in prototype then we follow this step. No specific technique was defined for requirement management of rapid application development based projects in traditional model. There are many techniques for requirement management but we have proposed requirements classification model. In requirement classification technique, we categorize our requirements in three categories [13]. These three categories are less likely to change requirements, fixed requirements and most likely to change requirements [13]. When customer change requirements then we check requirements by our change requirements repository. If changed requirement category matches with repository then we change our requirements otherwise we ignore this step. It is simplest and customer’s oriented technique for requirement management.
SURVEY RESULTS OF REQUIREMENT ELICITATION TECHNIQUES Techniques
Joint Application Development Interviewing Brainstorming Questionnaire Prototyping Reuse Requirements Scenarios Focus Group Ethnography Social Analysis User Centered Design
Results Strongly Agree/ Agree %
Neutral %
72%
16%
Strongly Disagree/ Disagree % 12%
66% 58% 42% 38% 30%
18% 32% 50% 46% 12%
16% 10% 8% 16% 58%
24% 18% 12% 8%
30% 16% 68% 54%
46% 66% 20% 38%
6%
16%
78%
Results show that our proposed technique has maximum software professional’s favor. It show that most of the people are agreed on our proposed model. We also put sections of next steps of our proposed methodology. Results of that part can be seen by following table. TABLE II. Step #2
SURVEY RESULTS OF REQUIREMENT ANALYSIS TECHNIQUES Techniques
IV. RESULTS AND COMPARISON After proposing the model, we need to implement that model for ensuring either this model will be useful or not. For the validation of our model, we choose survey technique. This is most simple technique for validation of any idea [[12]. We made survey form regarding requirement engineering techniques and filled it from different software professionals to know their opinions about requirement engineering techniques. Their answers help us to validate our proposed model. Survey forms have filled from 50 experienced software professionals of 20 different software organizations. Their answers have validated our proposed model. Out of 50 software engineers, 36 engineers are agree or strongly agree on using joint application development technique as requirement elicitation technique for rapid application development’s requirement engineering process. 8 engineers gave opinions as neutral on joint application development technique. And 6 software professionals were disagree on joint application development technique. Approximately 72% software professionals are in the favor of joint application development technique. 16% software engineers gave opinion as neutral. And 12% software engineers are disagree on using joint application development as requirement elicitation technique for rapid application development. We can see results by following results.
Requirement Analysis
TABLE III. Step #3
Requirement Management
Conflict Management Card Sorting State Machine Fault Tree Analysis Viewpoint Based Analysis Goal Oriented Analysis
Results Strongly Agree/ Agree %
Neutral %
76%
18%
Strongly Disagree/ Disagree % 6%
70% 56% 48%
28% 28% 18%
2% 16% 34%
42%
8%
50%
26%
32%
42%
SURVEY RESULTS OF REQUIREMENT MANAGEMENT MODELS Techniques
Requirements Classification Model Ince’s Change Model Olsen’s Change Model
Results Strongly Agree/ Agree %
Neutral %
68%
8%
Strongly Disagree/ Disagree % 24%
52%
12%
36%
38%
22%
40%
Above tables show that our proposed methodology steps conflict management, card sorting and requirement management by requirement classification model have high customer’s favor than others. These results validate our methodology steps. If we find average of overall results of our proposed methodology then we can see it by following table. TABLE IV.
V. CONCLUSION We purified requirement engineering model by specifying joint application development for requirement elicitation in our proposed model. We also introduced conflict management and card sorting in requirement analysis steps in our proposed model for ensuring requirements completeness and prioritization. We also introduced requirement classification technique for managing requirements in a well-mannered way. Results show that our proposed model is more cost and time effective than traditional model. It achieve maximum satisfaction level of customer because it is customer oriented model. Our proposed purified requirement engineering model purified each step of traditional model. It clear the picture of requirement engineering process to software developers and encourage the participation of all stakeholders. From above discussion, we conclude that requirement engineering is most important factor for the success of any project and our proposed purified requirement engineering model will remove all the difficulties that we were facing while during requirement engineering of rapid application development based projects.
SUMMARY OF PURIFIED REQUIREMENT ENGINEERING MODEL RESULTS
Model
Purified Requirement Engineering Model for Rapid Application Development
Techniques
Joint Application Development for Requirement elicitation Conflict Management Requirement Prioritization by Card sorting Requirement Classification for Management Cumulative Average of all proposed steps
Results Strongly Agree/ Agree %
Neutral %
72%
16%
Strongly Disagree/ Disagree % 12%
76%
18%
6%
70%
28%
2%
REFERENCES [1] 68%
8%
24% [2]
71.5%
17.5%
11%
[3]
[4] TABLE V.
COMPARISON BETWEEN PROPOSED MODEL AND TRADITIONAL MODEL
Functions
Requirement Elicitation by
Traditional
Proposed Purified
Requirement
Requirement
Engineering
Engineering Model
Model for RAD
for RAD
NO
YES
[5] [6] [7] [8]
JAD Conflict Management by
NO
YES
NO
YES
YES
YES
YES
YES
NO
YES
[9]
win-win Approach Requirement Prioritization
[10]
by card sorting Requirement
[11]
Documentation by SRS Requirement Validation by
[12]
Prototyping Requirement Management by
[13]
classifying
requirements [14]
Customer’s favor of our proposed model is 71.5%. Above table show that proposed methodology gives more functionalities then traditional model. It prove our methodology.
Bashar Nuseibeh & Steve Easterbrook “Requirements Engineering: A Roadmap”, Proceeding of IEEE 2000. Ian Sommerville and Pete Sawyer “Viewpoints: principles, problems and a practical approach to requirements engineering”, Annals of Software Engineering 3 (1997) 101–130. Betty H.C. Cheng and Joanne M. Atlee “Research directions in requirements engineering”, Future of software engineering (FOSE’07) IEEE 2007. Betty H.C. Cheng and Joanne M. Atlee “Requirement Engineering: elicitation techniques”, Master’s thesis Software Engineering 2008, Department of Technology, Mathematics and Computer Science University WEST, Sweden. P. Loucopoulos & V. Karakostas “CHAPTER 2 Processes in Requirements Engineering”. Ian Sommerville “Requirements Engineering Processes”, Software Engineering, 7th edition chapter no 7. Esmaeil Kheirkhah Aziz Deraman “Important factors in selecting Requirements Engineering Techniques”, IEEE proceedings 2008. CASEMaker Totem “What is rapid Application Development”, CaseMaker totem copyright. Fabrice Kordon and Luqi, Fellow “An Introduction to Rapid System Prototyping”, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 9, SEPTEMBER 2002. Souhaib Besrour, Lukman Bin AB Rahim, P.D.D.Dominic “Assessment and Evaluation of Requirements Elicitation Techniques Using Analysis Determination Requirements Framework”, IEEE proceedings 2014. Malcolm Eva “Requirement acquisition for rapid application development”, Journal of Information and Management, Elsevier 2001. Teade Punter, Marcus Ciolkowski, Bernd Freimut, Isabel John “Conducting On-line Surveys in Software Engineering”, Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE’03). Usman Qamar, Zahoor Ahmed, Musarrat Hussain, Abdul Rehman “Impact minimization of requirements change in software project through requirements classification”, ACM conference (IMCOM 2015). Paul N. Otto and Annie I. Antón “Addressing Legal Requirements in Requirements Engineering”, 15th IEEE International Requirements Engineering Conference 2007.
