# Introduction s we know that reengineering [4,5,6,7] is the revolution in software industry, it will reduces almost more than 60 percent cost as compared to maintenance of any software modules. And we already know that maintenance is one of the critical activity of any software modules, but continue maintenance of software modules is not a good choice to increase the quality of the software. Because while continue maintenance takes place it will result increases the complexity of software modules. Therefore, Reengineering is good choice than maintenance. The fundamental goal of reengineering was to minimize the impact of implementation expected system changes to the system. The purpose of this paper is to revisit the existing design methodology and develop a requirement engineering model, that will help to determine actual requirement of stakeholders before reengineering of software projects takes place. This data strongly suggests that, reengineering through new methodology significantly reduce full life cycle costs, schedules and risk. # II. # LITERATURE REVIEW The research is based on the process models found in [8,9,10,11] as these are the models that have been designed keeping in view the GSD context for streamlining the phase of RE. The process models given in sideline of any case study as in [12,13] are excluded because such processes are only for specific case study and situation. Moreover, the generic process models for RE that are not designed specifically for GSD(Global Software Deevelopment) context such as that proposed in [14] have also been excluded because they are not suitable to this research In evolutionary model [8] , requirements elicitation, requirements analysis and negotiation, requirements specification, and requirements validation are covered but this model addresses only few of the major GSD issues including a cultural issue which covers cultural diversity. Knowledge management issues cover knowledge sharing with users and knowledge acquisition techniques whereas technical issues over artifact sharing. Communication issues, time-zone difference, communication media and strategic issues are not covered in this model. Though this model is proposed to support the management of telecommunication network topologies but the reason for including this model is that it is documented process for DSD and is a good candidate for the GSD as well and can be applicable to other projects and domains as well. In requirement traceability model [9] , requirement traceability and requirements management are covered. Though this model does not cover all RE activities but the reason for including this model in this paper is that it can be very helpful in elicitation of correct requirements in GSD and the other reason for including this model is the level of importance attached to the requirements traceability and how this model can assist for better understanding of requirements in GSD A environment is also illustrated in this model. Requirement traceability helps in collecting rationale behind the requirements and this model also helps in indicating Value attached to the requirement. The GSD issues covered by this model are knowledge management, which includes knowledge sharing, and knowledge acquisition techniques. Technical issues (documentation sharing) and communication mode (asynchronous) are also covered. Other important issues like cultural issues, communication issues, strategic issues and time-zone difference are not addressed in this model. In [10] , though all activities of RE are not covered but major issues of GSD and three important activities of RE are covered. The other reason for including this process model is that it is documented process and it is in the context of GSD. The important RE activities which are covered by this model include requirements analysis and negotiation, requirements specification and requirements validation. This process model does not address the problems related to geographically distributed specification team. For example if some of the specification team members are in country A and some are in country B then, requirement speciation is quite a hectic tasks as team members at both sites need to validate SRS. This model address important GSD issues including cultural, technical, knowledge management and communication issues (poorly defined). # 'Requirement Engineering Model' In the above model, there is four phase that play very crucial role during reengineering of software module before actual process takes place, because if we know each and every requirement of customers before actual process takes place then we can reduce overall complexity of module in later phase. The phases of requirement engineering model given below: # Concept of formulation / Problem Understanding This phase generally proposed by people outside the system. E.g Senior manager in the organization, politician, chairman, or other member of the organization who want to get benefit directly or indirectly. Here we will try to know, why reengineering takes place and the impact that the proposed concept is likely to have. This process should involves primarily domain experts rather than the system engineers. Although some system engineering input is essential. The above activity is iterative process ? all stakeholders involved are identified together with their goals (called win conditions); ? Conflicts between these goals are captured together with their associated risks and uncertainties; ? Goals are reconciled through negotiation to reach a mutually agreed set of goals, constraints, and alternatives for the next iteration. # Requirement Engineering Requirement engineering [1,2,3] play very important role in identification of need: ? Identify need, want or desire # Architectural Design Evolve through a series of stages and each stages is evaluated, before proceeding to next stage Here one of very important activity takes place that to determine information need, determine different sources from where information will be obtained. # Here two types of design takes place ? Logical Design: is a more detail design, which includes all major components and entities plus their relationship. The data flow and connection are detailed in this stage ? Physical Design: has all major components and entities are identified within specific physical servers and location or specific software services, objects or solution, include all known detail such as OS, Ver. No. etc. # Review and Analysis Review is one very important activity, in the requirement engineering model, it is essential to cross verification of functionality. Once anywhere requirement changes it is very important to review it according to change requirement. Review and analysis is again a iterative process in the requirement engineering model, it help in # Result & Discussion There is no doubt that requirement engineering is first activity of software development life cycle which play very important role in successes or failure of software projects, however there are some problem that we will face during requirement engineering during software development. The purpose this paper is design requirement engineering model during reengineer that will solve the inconsistency of management for requirements engineering that will suffers these problems during software development: ? The specific kind of inconsistency being considered is not always clear. In fact, there is no common agreement on what a conflict between requirements does really mean. The lack of precise definition is a frequent source of confusion. Moreover, most techniques consider binary conflicts only, that is, conflicts among pairs of requirements. As we will see, there may be conflicts among three requirements, say, that are non conflicting pair wise. ? There is no systematic support for detecting conflicts among non operational specifications of goals or requirements-if one excepts theorem proving techniques for logically inconsistent specifications. Current conflict management techniques take it for granted that conflicts have been identified in some way or another. ? There is a lack of systematic techniques for resolving inconsistencies through goal/requirement transformations-one notable exception is [15] , which proposes a set of operators for restructuring objects involved in conflicting goals. The above requirement engineering model solve above problem that we will face during software development, as well as it play important role during reengineering of module. IV. # Conclusion This model play very important role in reengineering, it not only reduces the risk to meet specification, but it also ensure to avoid immediately assuming you know what the problem and solution are, Going directly to try to solve the problem before thinking about it. It provides systematic and organized approach that allows us to focus on achievable goal and to attain the best possible results from available resources. Therefore it will set the system objective, where reengineering takes place in the organization, so that management and employees agree to the objective and understand what they are in the organization. This model play very important role in reengineering because it play very important part in testing of reengineered modules according to new requirement as well as existing functionality ![](image-2.png "") March 2011Design of Requirement Engineering Model during Reengineering ©2011 Global Journals Inc. (US) March 2011 * The impact of time separation on coordination in global software teams: a conceptual foundation JAEspinosa ECarmel Software Process: Improvement and Practice Wiley InterScience 2003 8 * Requirements Engineering Challenges in Multi-Site Software Development Organizations DDamian DZowghi Requirements Engineering Journal 8 2003 * Requirements Engineering in Distributed Projects DDamian International Conference on Global Software Engineering 2006 * The process redesign-the implementation guide for managers ARTenner IJDetoro 1992 Prentice Hall New Jersey * Process Improvement: A Handbook for Managers SCook 1996 Gower Publishing Hampshire, England * The New Industrial Engineering: Information Technology and Business Process Redesign HTDavenport EJShort Sloan Management Review 34 4 1990 * Need radical innovation and continuous improvement? Integrate process reengineering and TQM THDavenport Planning Review 21 3 1993 * Learning organizational knowledge: an evolutionary proposal for requirements engineering CMaidantchik MMontoni GSantos Proceedings of the 14th international conference on Software engineering and knowledge engineering the 14th international conference on Software engineering and knowledge engineeringIschia, Italy 2002 * Risk Management with Enhanced Tracing of Requirements Rationale in Highly Distributed Projects MHeindl SBiffl International Conference on Software Engineering (ICSE) Shanghai, China 2006 * Distributed Requirements Specification: Minimizing the Effect of Geographic Dispersion LLopes RPrikladnicki JL NAudy AMajdenbaum Proc. ICEIS (3) ICEIS (3) 2004 * Strategies to Minimize Problems in Global Requirements Elicitation GNAranda AVizcaino ACechich MPiattini CLEI electronic journal 11 1 June 2008 * Differentiating Local and Global Systems Requirements Gathering Processes in IS Software Development Projects CHanish Jo TBrian Theerasak PACIS Proceedings 2005 * Requirements Engineering During Global Software Development: Some Impediments To The Requirement Engineering Process-A Case Study HanischJo CBrian European Journal of Information Systems (ECIS) 16 6 Dec 2007 * An operational model for structuring the requirements generation process DAJames KGMarkus 2004 Springer-Verlag London Limited 10 * A Meta-Model for Restructuring Stakeholder Requirements WNRobinson SVolkov Proc. ICSE19-19th Int'l Conf. Software Eng ICSE19-19th Int'l Conf. Software EngBoston May 1997