¶ … Management Requirements engineering process is at the very core of project success. Rather than spend huge amounts of money for reworking the whole project it is prudent and cost effective to identify and rectify the problems early in the project development life cycle.

We are witnessing a paradigm shift in communication and computer technology and there is a consequent change in our business methodologies. In this automated business environment there is an ever-increasing stress on businesses to accomplish everything in an efficient and swift manner. The increasingly cutthroat completion, particularly in light of the global competition, has placed a huge stress on productivity. The need for timely completion of projects and the urgency to meet the deadlines has however cast new problems on its own with companies trying to rush in with their projects neglecting some fundamental aspects. The life of any project depends on the provisions provided with a view to future considerations. The lack in futuristic perception leads to project failure resulting in the utter loss of time, effort and money. There is an increasing realization in the corporate world as to the importance of proper requirements management for the success of any project. Let us briefly discuss the importance of requirements engineering process and how it affects all other aspects of the project life cycle.

Requirements Engineering

Requirements engineering is all about defining and describing what a software system should do to satisfy the informal requirements provided by a statement of need. The Thinking in requirements analysis is principally in terms of problem not its solution' [Davis, 1993]. Problem analysis defines the software solutions possible for a given problem. According to Yeh and Zave, Partitioning, Abstraction and Projection are the three main principles of structuring in a problem analysis. By partitioning we simplify our analysis making it easier to understand the relationship between the different objects and functions within the system. Abstraction identifies the 'generic / Specific' relationships while projection provides an overview of the structural and functional relationships between the objects and the functions. Problem analysis presents us with a clear picture and forms the base for the software requirements specification report. [James F. Peters, 120] Requirements elicitation is the process of gathering information from the stakeholders of the project. The requirements themselves differ for the different types of users. "The process for eliciting the work group and end user group requirements are premised on the notion that sound and accurate descriptions of the users and their environment is at first necessary" [Macaulay 90]

Requirements Identification

The success and applicability of any project depends on the proper assessment and understanding of the user requirements. It is imperative for companies to have long-term strategical considerations before they embark on any new project. Well-planned requirements analysis will give us a good idea as to the exact requirements of the project and it is indispensable for the proper functioning of the project. Barry Boehm, an expert developer of cost estimation models recounts that almost 50% of the project reworking costs are due to the poor requirements analysis [Ivy. F.Hooks]. A good requirements analysis would reflect all the customer needs in the requirements specification document. According to Dr. Robert Spinard, vice president of Xerox Corporation, New York, "The Biggest mistakes in any large system design are usually made on the first day." It is fairly obvious that the requirements specification document holds the key to project success and longevity and hence it is imperative upon the companies to invest all the care and effort in creating a good requirements specification.

Functional, behavioral and non-behavioral attributes are the three main aspects of a good requirements analysis. The functional description of the requirements specification report explains the main system activities. The behavioral description enables us to have a clear idea of the hierarchical structure of the different system functions and controls while the non-behavioral description is about the quality assurance. [Harel D, 1992]. The functional specification document contains the details of all the inputs, outputs and the data retained in the system. A brief overview of the audit and control requirements as well as the system acceptance criteria (testing and validation) should also be included in the report. Starting the compilation part of the project without preparing a clear-cut specification in consultation with the users is a frequently encountered problem in the software industry leading to project failures. According to a report from the Standish group more than 31% of all projects are cancelled and even more astounding is the fact that around 53% of the projects that are carried on...

[The Standish Group]
Requirements specification is the most difficult and abstract part of the software development life cycle. Prototyping, risk analysis, simulation, and modeling are the main feedbacks in the requirements life cycle. In short the software description provided in the SRS (Software Requirements Specification) constitute the basis for the software design. There must always be some flexibility in the project specification report to accommodate future changes, as they are an inherent part of the world. However it must not be forgotten that the specification report should avoid uncontrolled change leading to inconsistencies within the different parts of the document and consequently the project itself.

Requirements Specification (Desirable Features) good requirements specification report would be Correct, Complete, Consistent, Unambiguous, Functional, Verifiable, Traceable and easily changed. Software requirements must be functional, describing the actual needs without explaining the how it will be accomplished. Requirements should be traceable to the statements given in the system definition. When specifications are clearly indexed it is easy to make modifications later on. If customer requirements are not properly indexed it will result in inconsistencies within the system due to lack of integration. [Richard Fairley, 93] Dominick Perritano, an expert software engineer opines "a requirements document should allow a smooth and seamless flow through the development process, where it becomes easy to trace the requirement from analysis to design to development and, finally, to testing." [Accelea Communications]

Effects of a Poor Specification poor requirements specification report has a direct effect on every stage of the project. Every project is subjected to a feasibility study and if the requirements are wrongly ascertained then invariably the technical, economical and operational feasibility of the project will be wronged leading to additional time and expenses for project completion and in many cases even lead to project cancellation. Unless all the reports such as the requirements specification, quality assurance, schedule and a comprehensive software development plan are prepared during the process of the feasibility study it is not technically correct to proceed with reviewing the project proposal. [IEEE, June 1998]

Most experts agree that in vast majority of the cases failure of the project has nothing to do with technology. Iain M. Tolmie, on of the chief software consultants as well as fellow of British computer society, when talking about project failures says that, "30% are caused by the failure to get the basic project organization right- bad requirements specification, bad risk management, bad project management, customer interference and changes in specification" [Iain M. Tolmie]. A bad requirements report directly affects the profitability of the concern in many ways. In the first instance the project period is extended way beyond its initial schedule to provide for the changing requirements. This not only wastes valuable time but also adds significantly to the cost overhead. Secondly in the absence of a well-prepared requirements specification we might actually end up with a product, which does not serve the ultimate customer needs leading to lost customer confidence. Barry Boehm states that "finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase" [IEEE, Sep 1987]

Software Process Models and Specification

There are basically two main types of software process models. They are the waterfall model and the evolutionary model each with their own advantages and disadvantages. The main distinction between these two models is that in the "Waterfall' model the specification and the development process are distinct from each other while the they are interleaved in the evolutionary model. The waterfall model presents problems when the customer requirements changes as it is difficult to make changes once the project process gets underway. Hence it is all the more pertinent for the project manager to clearly understand the requirements specification, as changes cannot be easily accommodate later on. [San Jose state University]

Design and Validation

As we discussed earlier requirements specification forms the core of the project and hence it directly affects the design of the software. Quite often new versions of software projects fail to satisfy the customer needs because the new requirements are not propagated through the entire design process. A case in point is the huge loss (an estimated $500 million) suffered by the European space agency when 'Arian 5' was lost and went our of control because of the lack of proper integration of the new requirements (from Ariane 4) into all phases of the design process. When we have…