Received 17 December 2015; accepted 14 March 2016; published 17 March 2016
1. Introduction
In software engineering, software development methodology known as software development life cycle (SDLC) is a sectionalisation of software development work. Common methodologies include Waterfall, Prototyping, Iterative and Incremental development, Spiral development, Rapid application development, Extreme Programming and other different kinds of Agile methodology. All these methods comprise of multiple phases and a variety of different activities. For instance design, re-factor, reuse, re-engineering and maintenance are some common activities, employed to complete software solutions. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One software development methodology framework doesn’t adequately suffice for all projects.
Over the years, most of the software development methods have been made immaculate and then referred to as traditional methods. One of the oldest of these traditional methods is waterfall which was firstly explained by Winston Royce in 1970 [1] . It is still very much in vogue widely practiced both in large and small projects [2] . The Waterfall model is a sequential design process which is used in software development processes where progress palpably is flowing downwards like a Waterfall through the phases of requirement gathering and analysis, design, coding, testing and maintenance. Every stage is to be treated separately at an opportune moment so you cannot jump stages. Documentation is done at every stage of a Waterfall model, providing an opportunity to the people to decipher as what has been done. Similarly testing is carried at every stage. Waterfall method is understood for its concrete and complete requirements and these features make this approach more viable and stable. It is often said about this method that spending more time early in the cycle can pave way to greater success at later stages.
The Agile development method came to limelight as the result of gathering of seventeen representatives from the software development industry in snowbird, Utah in 2001 [3] . Their intention was to develop innovative approaches to software development that would make organization react rapidly and adapt to volatile requirements and technologies.
In Agile Manifesto [3] they gave the identification of the following four priorities:
Priorities in Agile Manifesto
There exist multiple types of Agile methods as extreme programming, scrum, feature-driven development, dynamic system development method, adaptive software development, crystal and lean software development. What is common to all methods is the division of client’s requirements into multiple release cycle which are available in smaller portions regarding to their business value [4] . These methods comprise of most recognizable quality factors such as cost effectiveness, efficiency, extendibility, maintainability, portability, reusability and robustness [5] .
The remainder of the paper is organized as follows: Section 2 gives a comparison between traditional and Agile software development methodologies. Section 3 explains the Requirement Engineering process. Section 4 describes the RE in waterfall and RE in Agile, also the challenges of traditional RE resolved by Agile RE are discussed. Conclusion is given at the end of paper.
2. Comparison of Agile and Waterfall Development Methods
Agile and waterfall methods stand apart so far as their activities are concerned, as they are put to use within the development process [6] - [9] . To understand clearly the difference between Waterfall and Agile the comparison is made in a tabular form and is provided in Table 1.
3. Requirement Engineering
Software Requirements describe features and functionalities of the target system it also tells the expectations of the users from the software product .The requirements can be obvious or occult, either it is known or not known, expected or unexpected from client’s point of view. The formidable single part of making a software system is deciding clearly as what to build. No other part of the conceptual work is as formidable as making the detailed technical requirements. The process to glean the software requirements from client, analyze and document them is named requirement engineering. It is sometime overlooked or assumed to be a straight and undistorted task [26] , requirements collecting for software development projects is the most difficult phase of any software development methodology. To determine software requirements is the fulcrum to any successful project. Requirements cannot be easily defined and estimated for managing any project [27] . Some studies have exposed that around 37% of the problems occurred during the development of system related to the requirement phases [28] and is graphically depicted in Figure 1.
Requirement engineering stresses the use of systematic and repeatable techniques that ensure the completeness, consistency and relevance of the system requirements. The process used for RE changes widely depending on the
![]()
Figure 1. Problems of challenging system.
![]()
Table 1. Comparison of Waterfall and Agile development methods.
application domain, the people involved and organization developing the requirements. There exists a plethora of generic activities common to all processes. So RE process can be split up into 2-main assortments:
Requirement Development
Requirement Management
The goal of requirement development is to identify, capture and agree upon a set of functional requirements and product characteristics that will gain the stated business objectives. It contains four kinds of activities as shown in Figure 2 [29] .
![]()
Figure 2. Requirement development activities.
Elicitation: It is process discovering, reviewing, documenting, knowing user needs and constraints for the system.
Analysis: It provides feedback loop to refine user’s needs and restraints.
Specification: It is process of documenting the user’s needs and restraints.
Validation: This ensures that the system requirements are complete, correct, consistent and clear.
However, the requirement management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
4. Requirement Engineering in Agile and Waterfall
4.1. RE in Waterfall
Requirement engineering involves a number of processes for gathering requirements in accordance with the needs and demands of users and stakeholders of the software product. Waterfall Requirement Engineering involves some important features that are elicitation, analysis, documentation and managing of the requirements [30] [31] as already mentioned in Section 3. In the waterfall model requirements engineering is presented as the first phase of the development process. This traditional approach to the RE process focuses on gathering all the requirements and preparing the requirements specification document up front before proceeding to the design phase [32] . In the waterfall method the project is separated into stages distinctly and commitments must be made at an early stage, which makes it hard to alter the requirements if customers change their minds. So waterfall is more suitable when the requirements will probably not be changed during the implementation time. In conclusion, the waterfall model takes a static viewpoint of Requirements Engineering by ignoring issues such as the volatility of requirements and its impact on earlier and later phases of development [33] .
4.2. RE in Agile
According to various researchers Agile methodology and its family members are based on the following principles also known as Agile manifesto [34] - [37] :
These principles are fairly simple in concept, but are profoundly deep in practice.
Agile assumes that requirements engineering continues through the lifetime of a system. In Agile, RE is achieved through continuous collaboration while requirement gathering, developing and testing may happen at the same time. This is achieved by applying the practice of evolutionary requirements which suggests that requirements should evolve over time. In Agile, the business requirements are elicited and documented in the form of user stories, which are from portrays user’s perspective [38] . These user stories are used as a primary unit of work and continue to grow during the lifecycle of the project. Agile methods involve continuous planning, i.e. release planning, iteration planning and task level planning. Iteration planning is done for each iteration that spans from 1 to 3 weeks. It involves user story estimation, acknowledgement of the accomplishments of the previous iteration and determining overall progress and goals for the next iteration. Release plan is done for each release in which iteration length is decided, developers and customers unanimously decide what will be in a particular iteration; velocity points are determined per iteration. Task level planning involves the breaking down of user stories into subsequent tasks, allocation of tasks among team members and focus is put on implementation issues [39] - [42] . After the literature survey of RE in Agile the overall Agile RE process is accumulated and described in Figure 3.
![]()
Table 2. Issues of RE in waterfall resolved by agile RE.
4.3. RE in Agile VS RE in Waterfall Methods
It has been ascertained that traditional requirement process is a complex process where as real life development needs efficient requirement software which must have a flexible and speedy process. For a successful project an efficient RE process is needed. The objective of RE remains the same in all software methods, however RE in Agile and Waterfall methods is juxtaposed and opposite in nature [43] [44] . Remarkable variances are found in the process of carrying out RE activities in Agile methods when compared and contrasted to Waterfall methods. The traditional RE is facing many a challenges such as communication gaps, over scoping, requirement prioritization, validation and customer involvement [45] . These issues are resolved by Agile practices such as face to face communication for minimizing documentation and communication gaps, gradual detailing of requirements for reducing over scoping, requirement prioritization by customer based on the worth of business to deal with requirements validation and close interaction on the part of team and customer in order to avoid lack of customer participation [46] . Issues caused by the traditional RE and the solutions provided by the Agile RE are described in Table 2.
Therefore, we can summarize that several detrimental challenges posed by traditional RE can be eradicated or minimized by using Agile RE.
5. Conclusion
Differentiation has been clearly drawn and found that the traditional RE and Agile RE are two different approaches so far as their rules and activities are concerned. Comparison between the two shows why people have gone from traditional RE to Agile RE. The underlying idea of this apparent shift was to shed light on the magnitude of Agile development for efficacious requirement engineering process. By doing so, resultantly Agile RE works better than the waterfall RE in disciplines like communication, customer collaboration, documentation, delivering outputs, requirement prioritization and validation, etc. Practitioners engaged will come to comprehend and evaluate the various impediments/obstacles encountered by them while using traditional RE.
Acknowledgements
I, personally feel extremely beholden to Prof(R) Ghulam Qasim Shah who with self-abnegation graciously spared his time and reviewed this paper.