Process-oriented complete requirement engineering cycle for generic projects

Software requirements express the requirements and constraints on a software product that contributes to the satisfaction of some 'need' in the real world. Ambiguity is a major problem in requirements specification. At its most basic, a requirement is a property that a system must exhibit in order for it to meet the system's motivating need. We ignore intentional ambiguity or the ambiguity that exists in early stages of requirements elicitation and focus on ambiguity that remains in a so-called final natural language requirements document. Ambiguity is a problem because the different readers of the requirements specification may understand different things. An essential property of all requirements is that they should be verifiable. In a typical project there will be a large number of requirements derived from different sources and expressed at different levels of detail. The existing Requirement Engineering Techniques and Methodologies are supporting to a specific set of activity like Elicitation or validation. Requirement Engineering develops a mutual understanding between customers and project teams about the product or system requirements. An agreed-upon and approved product requirement becomes the initial baseline for product design. Knowledge of ambiguous, inconsistent requirements to requirement engineer increases the capability to view the requirements from different perspectives. This paper discusses the requirement generation process and allied activities in it. It also focuses on methodologies, models and techniques for requirement engineering. As a part of applying complete requirement engineering, we claim that the crucial issues like architecture and design in system development can be effectively addressed.