International Journal of Computer and Technology (IJCET), ISSN 0976 – 6367(Print),International Journal of Computer Engine...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print), ISSN 0976 – 6375(Online) Vo...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Vol...
Upcoming SlideShare
Loading in …5
×

Performance measurement of different requirements engineering

646 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
646
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Performance measurement of different requirements engineering

  1. 1. International Journal of Computer and Technology (IJCET), ISSN 0976 – 6367(Print),International Journal of Computer Engineering EngineeringISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEand Technology (IJCET), ISSN 0976 – 6367(Print)ISSN 0976 – 6375(Online) Volume 1 IJCETNumber 2, Sep - Oct (2010), pp. 01-15 ©IAEME© IAEME, http://www.iaeme.com/ijcet.html PERFORMANCE MEASUREMENT OF DIFFERENT REQUIREMENTS ENGINEERING PROCESS MODELS: A CASE STUDY Dhirendra Pandey Department of Information Technology Babasaheb Bhimrao Ambedkar University Lucknow (U.P.) - 226025 E-Mail: prof.dhiren@gmail.com U. Suman, A. K. Ramani School for Computer Science & IT Devi AhilyaVishwavidyalaya, indore (M.P)ABSTRACT: Numerous requirement engineering models have been proposed to find out thegood requirements for development of quality software product. In this paper we usedifferent requirements engineering process model which are linear to iterative instructure. In this paper, we also examine the performance of our requirementsengineering processes model as well as existing model at two Indian companies.Structured interviews were conducted with the aid of a qualitative questionnaire. Theresults from the interviews are discussed, with particular focus on requirementsengineering activities and the high-level descriptive process models of the requirementsengineering processes that were constructed from the data. These models are thencompared with the performance of our RE process model. Keywords: Requirements engineering process models, Indian companies,requirements elicitation, project management.1. INTRODUCTION The objectives of RE is to extract the quality requirements from the stakeholdersfor engineering principles and the development of information systems analysis and 1
  2. 2. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEdesigning of system [1, 2]. Requirement engineering is one of the most important toolsfor gathering requirements, which is concerned with analyzing and documenting therequirements [3, 8]. Furthermore, the cost of repairing requirements-related problemsdramatically increases as the software development process progresses [4]. It is thereforeevident that the RE process has important results for the overall success of the project. Inorder to improve RE processes, the current practices need to be examined. Understandingand modelling current RE processes is an important step towards improving RE practiceand therefore increasing the success of software projects [5]. Studies of current REpractices and the areas for improvement have concluded that the issues wereorganisational and non-technical in nature, for example, document management andmanaging uncertainty [6]. Some of the existing software process definition studies have focused onconstructing prescriptive models, rather than first examining the descriptive models incurrent practice [5]. This paper examines the performance of our model with existingmodel and model this RE process models in actual RE practice. Before modelling currentRE practices, a review of existing descriptive RE process models in literature provides anindication of common RE activities and their sequence. However, these models aredifferent and sometimes conflicting in their nature, ranging from linear and incrementalto cyclical and iterative in structure. Results from previous studies of RE practice haveindicated that the RE process models in practice differ from commonly accepted REprocess models in literature [7, 8]. Further complication arises with the idea that REprocess models are situation dependent, affected by the customer-developers relationship[9, 10], the product, technical maturity, disciplinary involvement and culture of theorganisation [11]. This paper also provide insight into the gap between descriptive REprocess models in literature and practice by constructing high-level data analysis of theRE processes at two Indian companies and comparing these to the performance of our REprocess models. The models represent the activities in the RE process and not additionalfactors, such as the three dimensions of RE identified by one of the researcher [12, 13]. Requirement engineering is a very important activity, which can affect the entireactivity of software development project [15]. In this paper we present literature reviewin Section 2. The research methodology of this research paper is presented in section 3. 2
  3. 3. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMESection 4 describes finding of our research presented in this paper. In continuation,section 5 present our research boundary and future work and finally section 6 presents theconcluding remarks.2. LITERATURE REVIEW ON RE PROCESS MODELS Quality of requirement engineering process model plays a key role indevelopment of software products. In this paper we use some existing RE process modelsfor the comparisons with our RE process model. These three models were selected fortheir different structures: linear, linear with iterations between some activities, and linearwith iterative. Within these models, common RE activities, such as elicitation andanalysis, are combined under different headings, but still follow a similar lineartransition. Two such linear models were selected for use in this research. Two of theresearchers have suggested a conceptual linear RE process model, which indicatesiterations between some activities. They state that the activities in the model overlap andare often performed iteratively [11]. One of the researchers provides a purely linear REprocess model. It does not indicate the overlapping or iterations of activities [9]. The REactivities are categorised under different headings, however the linear progressionresulting in documentation is common to both models. One of the researchersacknowledges that the RE process is situation dependent and discusses differentcustomer-developer relationships and their corresponding RE processes [9]. Whileliterature tends to portray the RE processes as linear, non-linear/iterative models havealso been suggested [12]. The third model selected for use in this research is our RE process model, whichdepicts the RE process as iterative and cyclical in nature [15]. Existing modeldemonstrates the interactions between elicitation, specification, validation, the user andthe problem domain [9, 11]. While similar activities to the two models already discussedappear in our model, the order in which they occur is non-linear and suggests a cause andeffect relationship between them. Our RE model provides a purely iterative RE processmodel which is shown in figure 1. It does not indicate the overlapping or iterations ofactivities, suggested by the existing RE model [11]. It consists of mainly four phases, 3
  4. 4. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEnamely; requirement elicitation and development, documentation of requirements,validation and verification of requirements, and requirement management and planning. Requirement elicitation and development phase includes requirement analysis andallocation and flow down of requirements. Documentation of requirements includesidentification of requirements and software and system requirement specification.Validation and verification of requirements phase is concerned with conforming thedocumented requirements. The requirement management and planning phase controls thecontinuously changing requirements. Each of these activities is further detailed in thefollowing sub sections. The proposed process describes requirements engineering forsoftware development systems in which requirement engineering must be a part of thesoftware development process [15]. Customer Business requirement Information requirements Requirements Security requirements User requirements Constraints Standards Requirement Elicitation Documentation Validation and of Verification of and development Requirements Requirements Requirement analysis Requirement Identification Validation Allocation and flow down Software Requirement Software requirements Specification Verification System Requirement Hardware requirements specification Modified Requirement Management & Software development Planning phases Figure 1 Requirement Engineering Process Model [15]. Existing studies of RE processes in practice have indicated that the systematic andincremental RE models presented in literature do not reflect the RE processes in currentpractice. For example, some researcher found that the RE process in their case study didnot occur in a systematic, smooth and incremental way, but was opportunistic, withirregular simplification and restructuring of the requirements model when it reachedpoints of high complexity [7]. Furthermore, some of the researchers performed a casestudy in the field but could not produce a massive RE process model of RE activities, as 4
  5. 5. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEthey were too heavily intertwined and not seen as separate tasks by the participants of thestudy [8]. RE field studies have also gathered conflicting results as to the status of REprocess standards in organisations. Two of the researcher examined the 15 RE processesin industry and found that most participants saw RE as an ad hoc process, with only someusing an explicitly defined RE process or customising a company standard RE process[16]. Furthermore, studies of web development projects have also shown that RE isoccurring an adhoc manner [17, 18]. In contrast to these findings, concluded thatorganisations tend to use standard RE processes, as they are thought of as best practices[5].2.1 RE PRACTICES The following seven common activities that occur during the RE process arereferred to in this research paper. These RE activities were used in the questionnaire toallow separate tasks to be identified, hence preventing the issue of merged activities [8].Project Creation: Project creation is the activity of setting up a project to develop anew product or to modify and existing product.Elicitation: Elicitation refers to gathering the requirements of the system from differentstakeholders. Boundaries, identification of stakeholders, goals and tasks performed arediscovered in this phase [21].Interpretation and Structuring: Following the elicitation of the requirements, theyare interpreted, structured and analysed. The requirements are then documented. Thisphase is discussed separately; however it is often interleaved with requirementselicitation, as some analysis invariable takes place in the elicitation process [11].Negotiation: The negotiation phase consists of the requirements engineers negotiatingwith the stakeholders to agree about the requirements definitions in the requirementsdocumentation [11].Verification and Validation: Verification and validation of requirements aims tocheck that the requirements accurately represent the needs of the system and that they arecomplete, correct and consistent [3]. The technical experts or quality assurers also reviewthe requirements. 5
  6. 6. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEChange Management: Change management makes certain that similar information isgathered for each change and that the overall costs and benefits of proposed changes arereviewed [11]. Therefore, change management involves evaluation of risks and impacts[21].Requirements Tracing: Requirements tracing is used to track the origins of eachrequirement, so that if a change has to be made to a design component, the originalrequirement can be located [22].3 METHODOLOGIES3.1 RESEARCH METHOD The basic goal of this paper is to discover and understand RE models in practiceand compare performance measurement between existing models and our proposedmodels. For this, a questionnaire instrument was selected in order to collect the largeamount of data required to gain a comprehensive understanding of the RE process [19,20]. The questionnaire consists of (1) background details of the participant, companyand project, (2) the RE process, and (3) RE techniques used. Many closed-endedquestions were used to minimise the length of the questionnaire. Open-ended questionswere used where it was important for participants to answer in their own words. Thequestionnaire was administered to each participant in an interview session, with theresearcher and one participant present. The participant was asked to complete the writtenquestionnaire and add any additional verbal information. The use of interview sessionsallowed for participants to clarify meanings of the terms and questions used, ensuring thatthey had a clear understanding of what was being examined. The duration of the interviews was between 60 and 90 minutes, with thedifferences in time resulting from the amount of additional information added verbally bythe participant and the use of contingency questions in the questionnaire. The interviewstook place at prearranged times in private meeting rooms at the companies’ premises tomaintain a quiet, undisrupted environment, which was consistent for every interview. Atotal of six interviews have been conducted at two companies, operating in themanufacturing and financial industries. Three interviews were conducted respectively. 6
  7. 7. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEThe participants were primarily in a project management or business analyst role, withresponsibility for RE activities on the relevant project.3.2 CASE STUDY Company A is a large company in the manufacturing industry. Less than 1% ofstaff works in the information technology (IT) department. Three projects conducted bythe IT department were examined. The objective of project α1, a large project, was toimplement an enterprise resource planning (ERP) system. Project α2, a medium project,had the aim of upgrading all systems, particularly the ERP system, for the introduction ofthe Goods and Services Tax (GST). Project α3, a small project, had the purpose ofimplementing enhancements to an existing sales promotions management system. Allthree projects produced a customer-specific business system for an internal customer andhad direct contact with the customer throughout the project. The customer-developerrelationship for these projects is considered to be similar to the scenario, ‘responding to abusiness centre within the same organisation’, suggested by some researchers, howeverthere is no specific RE process model identified for this scenario. Our study summarises the project characteristics which shows the project α1 islarge project having near about 75 project members in which 60% of members aretechnical and this project is easily accessible by the user. The project α1 having mediumnon-RE tool support. In this way project α2 is medium project and it has 25 projectmembers in which there are 16 members having technical skills. Project α2 is easilyaccessible to the user and it has low non- RE tool support. In project α3, that is smallproject. It has 10 project members in which 8 persons are technical hand. It is easilyaccessible and this project having low non- RE tool support (Table-1). 7
  8. 8. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME Table 1. Characteristics of Projects at Company A and Company BProject Size Project Effort Technical Special Customer Non-RE Members per background quality Access tool Month of Project requirements support Membersα1 Large 30-115 621 60% High Easy Medium Performanceα2 Medium 15-29 28 35% Legal Easy Low Complianceα3 Small 5-15 5 78% High Easy Low Performanceβ1 Medium 10-15 114 95% System Easy Medium Availabilityβ2 Small 5-15 12 65% High Normal Low Performanceβ3 Medium 10-15 26 95% System Easy Medium Availability Company B is a large company in the finance industry. Approximately 20% ofstaff works in the IT division. Time was a priority for all three projects. For projects β2and β3 this is attributable to the recent move towards iterative, shorter developmentcycles with fixed deadlines. Project β1 had the aim of developing a customised websitefor institutional clients and asset consultants, with content such as interactiveperformance data. The objective of project β2 was to replace an existing customerrelationship management (CRM) system with a new version from the same vendor. Theexisting system was so customised that it was more cost-effective to start again, than toupgrade the existing system. Project β3 implemented a new equities trading systemvendor solution. As for Company A, the customer-developers relationship for theseprojects is considered to be alike the scenario, ‘responding to a business centre within thesame organisation’, suggested by some of the researchers. Our analysis summarises the project characteristics which shows the project β1 ismedium project having near about 12 project members in which 95% of members aretechnical and this project is easily accessible by the user. The project β1 having mediumnon-RE tool support. In this way project β2, a small project has 10 project members inwhich there are 65% of members having technical skills. Project β2 is normal accessibleto the user and it has low non- RE tool support. In project β3, that is medium project and 8
  9. 9. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEin which all of the members are technical hand. It is easily accessible and this projecthaving medium non- RE tool support.4 PRELIMINARY FINDINGS The results from the questionnaire were used to describe the state of the art of REpractices at the companies. Brief discussions of the findings are as follows: company Ahad no standard RE process documentation, therefore the RE practices differed betweeneach process. There was a medium level of RE process awareness in the larger projects,α1 and α2, with many RE activities performed explicitly or implicitly. The RE processawareness in the small project, α3, was low, with only some of the RE activitiesexplicitly or implicitly performed. The processes in the large and medium projects, α1and α2, were structured, as several RE phases occurred with allocated documentation. Itwas evident that the RE process in the smallest project, α3, was ad hoc, with a low levelof RE process awareness and no dedicated role for RE. The results indicated that this rolewas influenced by the size of the project, since the larger project allowed for greaterseparation of tasks between the roles of business analyst and project manager. Projectsand α2 both had a medium level of tool support, as no specific requirements managementor modelling tools were available at Company A. Project α3 had a low level of toolsupport, which is consistent with the unstructured, ad hoc nature of the RE process.Projects α1 and α2 had a high level of documentation awareness, as all the suggested REdocumentation was produced where relevant. Project α3 was classified as having amedium level of documentation awareness, as only three of the suggested RE documentswere produced. General project methodology did exist at Company B. There was a companystandard methodology; however, there had been a move towards the Microsoft SolutionsFramework (MSF) methodology. There was an inconsistent response to whethercompany standard documentation existed for the RE process, with two respondentsindicating that no such standard existed and two indicating that standards did exist,however the size of these documents differed dramatically. Therefore, even if a companystandard exists, it is not widely used. The RE process awareness for projects β1 and β2were medium, with many RE activities performed explicitly and implicitly. Project β3 9
  10. 10. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEhad a high level of RE process awareness with most RE activities performed explicitlyand the others implicitly. The RE process for all three projects was structured, with several RE phasesoccurring with allocated documentation. All three projects had the role of businessanalyst defined for RE. In project β2 the business analyst was also performing the projectmanagement role. This is similar to project α2, in which the project manager was alsoperforming the RE activities. In both instances, having a smaller project team resulted inthe merging of roles, that may have been separated in a larger team. All three projects hada medium level of tool support for the RE activities. No project used specificrequirements management or modelling tools. Participant β1 commented that they hadused a requirements tracing tool at their former company. The documentation awarenesslevel was generally high, with projects β2 and β3 having a high level and β1 at a mediumlevel. One of the participants commented on the lack of time available to maintain thedocumentation, due to the move towards three-month cycles.4.1 REQUIREMENTS ENGINEERING ACTIVITIES Participants were asked whether each of the seven RE activities were performedexplicitly (required and definite), implicitly (performed but indefinite) or not at all intheir projects. The variance between the ways RE activities are performed is consistentwith the lack of RE process standards in Company A and B. There were clear differencesbetween the projects at Company A. Elicitation was the only activity performed explicitlyin every project. Negotiation was performed implicitly in every project. Interpreting &Structuring was performed in all projects, but differed between implicit and explicit.Project Creation, Verification & Validation, and Tracing ranged from being performedexplicitly, implicitly to not at all. Company B revealed a more consistent performance ofRE activities, but differences still occurred between projects. Elicitation and Negotiation were performed explicitly in approximately in allprojects. Change management was performed implicitly in all projects. Project Creationand Interpreting & Structuring were performed in all projects, but changed betweenexplicit and implicit. Verification & Validation was either explicitly or not performed.Tracing varied between explicitly, implicitly and not performed. Of the seven suggested 10
  11. 11. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print), ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME activities, Elicitation was the only RE activity performed explicitly in every project. Interpreting & Structuring, and negotiation were also performed in every project, but varied between implicitly and explicitly performed. It was established that there was some doubt whether project creation was seen part of the RE process. 4.2 PERFORMANCE MEASUREMENT The RE process models for each project were compared to the three models selected from this paper. As detailed in section 2, one of the RE model depicts the RE process as linear, but with iterations occurring between individual activities [11]. Second RE model presents the RE process as linear, with no iterations occurring [9]. Our RE model represents the RE process as a completely iterative and linear process, with activities depicted with cause and effect relationships, as opposed in a sequence [15]. In our study we found that, project α1 is iterative in nature and company has decided to use continuous RE process to complete the project. The company A used the RE model that is linear but iterative between some activity [11]. The project α1 give average performance. In Project α2, RE process is just start in project lifecycle. RE model is used is linear in structure, project α2 is also give average performance. Project α3 provide good performance to the company because in this project company used RE model that is linear than iterative. Project β1 has produced same result. In project β2, linear RE model is used which gave average performance. Lastly β3 project uses continuous RE process in throughout project life cycle, and company B used RE model that is linear then iterative. This project is also give good performance same as project α3 and β1 (Table-2). Table 2. Requirements Engineering Activities Performed at Company A and BProject Project Elicitation Interpreting& Negotiation Verification Change Tracing Creation Structuring & Management Validatingα1 No Explicit Explicit Implicit Explicit Explicit Implicitα2 Explicit Explicit Implicit Implicit Implicit Implicit Implicitα3 Implicit Explicit Explicit Implicit No No Noβ1 Implicit Explicit Explicit Explicit No Implicit Noβ2 Explicit Explicit Explicit Explicit Explicit Implicit Implicitβ3 Implicit Explicit Explicit Explicit Explicit Implicit Explicit 11
  12. 12. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME4.3 DISCUSSION AND FUTURE WORK One of the RE model was a good representation of generally linear RE processmodels that had some iteration of activities [11]. The purely linear nature RE processmodel did not indicate any iteration of activities [9]. Projects that made use ofprototyping required a more iterative depiction of that part of the process. Most of theseprojects followed a generally linear process until the prototyping phase, which thenresulted in an iterative process. Our model was a good representation of a linear processand the iterative nature of prototyping [15] . By analysis of above study it is clearly statedthat the project using iterative as well as linear approach was successful in businesscontext (Table-3). Table 3 Performance Measurement of Requirements Engineering Processes in different projects.Project RE in Project Model Structure RE Model Performance Lifecycle usedα1 Continuous Iterative (K) Average performanceα2 Start Linear (M) Average performanceα3 Continuous Iterative (P) good performanceβ1 Continuous Linear then iterative (K), (P) good performance prototypeβ2 Start of each Linear (K), (M) Average iteration performanceβ3 Continuous Linear then iterative (K), (P) good performance prototype This research is essentially an exploratory study, so there are many opportunitiesfor further research in this area. This study could be expanded to include a widerspectrum of industry and projects of different customer-developer relationships. Resultscould be gathered from other roles within the project team, such as the developers, toidentify whether the process is perceived differently from other perspectives. Participantscould also be involved in the process of comparing the company’s RE process models tothose from literature. Future studies could attempt to correlate the use of different REprocess models with project success. Additionally, the relationships between explicit andimplicit activities and project success could also be studied to identify if there is a link 12
  13. 13. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEMEbetween the nature of activities and the success of the RE process. This research couldalso lead into the area of RE process improvement, by identifying areas of strength andweakness in current RE processes.6. CONCLUSIONS The two existing RE process models are compare with our RE process modelsand also they compared to the RE process in each project. It was determined that none ofthese models were a good representation of every RE process but one of the RE processmodel represented some RE processes better than others [15]. While it is has beenestablished that one model cannot represent all processes, a purely linear model was notas successful as one that showed iterations of activities. Conversely, a purely iterativemodel neglected to represent a progression of RE activities. Therefore, an RE processmodel would benefit from a combination of linear and iterative structures which is shownin our RE model [15]. This outcome is based on the result which is found when we getthe project result. In that result it is clearly seemed that the project α3, β1, β3 issuccessful because in that project our RE model is used for requirement engineering.REFERENCES 1. Berry, D. M. and Lawrence, B. (1998), Requirements Engineering, IEEE Software, Vol. 15, No. 2, pp.26-29. 2. Leite, J. C. (1987), A Survey on Requirements Analysis, Advanced Software Engineering Project Technical Report RTP-071, University of California at Irvine, Department of Information and Computer Science. 3. D. Pandey, U. Suman, A. K. Ramani,(2008), “Impact of Requirement Engineering Practices in Software Development Processes for Designing Quality Software Products”, National Conference on NCAFIS, DAVV, Indore. 4. Boehm, B. W and Papaccio, P. N. (1988), Understanding and Controlling Software Costs, IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 1462-1477. 5. Madhavji N. H., Holtje D., Hong W. and Bruckhaus T. (1994), Elicit: A Method for Eliciting Process Models, Proceedings of the 1994 CAS Conference, Toronto, Canada, 31 October – 3 November. 13
  14. 14. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME 6. Lubars, M., Potts, C. and Richter, C. (1993), A Review of the State of the Practice in Requirements Modeling, Proceedings of the IEEE International Symposium on Requirements Engineering, San Diego, USA, pp. 2-14, IEEE Computer Society. 7. Nguyen, L. and Swatmann, P. A. (2000), Managing the Requirements Engineering Process, School of Management Information Systems, Deakin University, Geelong, Australia. 8. Houdek, F. and Pohl, K. (2000), Analyzing requirements engineering processes: a case study Proceedings of the 11th International Workshop on Database and Expert Systems Applications, Greenwich, UK, 6-8 September, pp.983-987. 9. Macaulay, L. A. (1996), Requirements Engineering, Springer-Verlag. 10. D. Pandey, U. Suman, A. K. Ramani. (2010) “Social-Organizational Participation Difficulties in Requirement Engineering Process- A Study”, Software Engineering Journal, Bioinfo Publication, Navi Mumbai. 11. Kotonya, G. and Sommerville, I. (1998), Requirements Engineering – Processes and Techniques, John Wiley & Sons, UK. 12. Pohl, K. (1994), The Three Dimensions of Requirements Engineering: A Framework and its Applications, Information Systems, Vol. 19, No. 3, pp. 243- 258. 13. Martin, S. R. (2002), Requirements Engineering Processes in Australian Practice, Unpublished Thesis, School of Information Systems, Management and Technology, University of New South Wales. 14. Loucopoulos, P., and Karakostas, V. (1995), System Requirements Engineering, McGraw- Hill Book Company Europe. 15. Pandey, D., Suman, U.,Ramani,A. K.(2010), An Effective Requirement Engineering Process for Software Development, Internation Conference on ARTCom, ACEEE, Kerla. 16. Hofmann, H. F. and Lehner, F. (2001), Requirements Engineering as a Success Factor in Software Projects, IEEE Software, Vol. 18, No. 4, pp.58-66. 17. Lowe, D. and Eklund, J. (2001), Development Issues in Specification of Web Systems, 6th Australian Workshop on Requirements Engineering, 22-23 November, University of New South Wales, Sydney, Australia. 14
  15. 15. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME 18. Dang, T. K. (2000), Understanding the Requirements Engineering Process for Hypermedia Systems, School of Information Systems, Technology and Management, University of New South Wales, Australia. 19. Blaikie, N. (2000), Designing Social Research, Polity Press. 20. Galal, G. H. and McDonnell, J. T. (1998), A Qualitative View of Requirements Engineering, Proceedings of the 3rd Australian Conference on Requirements Engineering, October, Deakin University, Geelong, Australia. 21. Nuseibeh, B. and Easterbrook, S., (2000), Requirements Engineering: A Roadmap, The Future of Software Engineering, Anthony Finkelstein (Ed.), ACM Press. 22. Davis, A. M. (1993), Software Requirements: Objects, Functions, and States, Prentice Hall. El Emam, K. and Madhavji, N. H. (1995): A Field Study of Requirements Engineering Practices in Information Systems Development, Second International Symposium on Requirements Engineering, York, England, IEEE CS Press, pp.68-80. 15

×