Requirements are a necessary component of any successful project. In order for the project to go from the “pie in the sky” dreams and wishes of its stakeholders to a final and completed product, each aspect of the project will need to be thought through, boundaries must be set, and attainable milestones need to be accomplished. In order for the customer to gauge whether or not their needs have been met, the project should have certain requirements that are obtained.
But how are those requirements gathered in the first place, and how can they be translated to the individuals who will make them a reality? In software projects, this “phase” of requirements gathering is a practice unto itself, often performed by individuals who have quite a bit of experience in eliciting the needs of the customers and translating that into a language that the developers can use in order to supply the final product. But many times these gatherers of information may not have the best tools available to them, or they may be under constraints that limit their ability to fully understand the customer’s requirements for the final product. One of those limitations may be how the process of project work is being performed. Too many times, software projects fall under a pattern of concept, analyze, do the work, and then hope everything went right the first time. Unfortunately, this process is prone to failure. To combat that, new methodologies of project execution have been created, in the belief that by changing the process the outcome will also be changed.
Typical software projects under a “waterfall” approach try to make each of these steps its own process, relatively segregated from the others. Once a phase has been completed, the outcomes are “thrown over the wall” to the next phase, and the prior phases are usually not revisited. An alternative process to this is Agile, where the phases are intermingled, often repeating or iterating themselves many times throughout the project’s life. But does this repetitive iterating of the phases actually improve the individual pieces, including the gathering of requirements? Or does it merely introduce a level of complexity that only serves to muddle the actual requirements of the customer?
One of the main principles behind a waterfall approach to software projects is the consistency in how each phase of the project will be handled. First, the project is conceptualized, with the major goals identified and a go/no-go decision on whether to continue. Then the next step taken is to collect the requirements of this project. Will this be for the entire company, or just a subset? Will this replace a previous software application, or supplement it? Will there be menus, or tabs, or some other way of navigation? And so on they go. Once these requirements are obtained, then the project is designed. This is a critical point to understand. In order for the design to be correct, the requirements must be accurate and whole, gathered first in one big effort (Tomayko). Otherwise, the design will be flawed, which should not be acceptable. Once design is completed, then the development occurs, followed by testing, and them implementation and maintenance. Each major phase is a whole unto itself, depending on the previous phase to supply the inputs it needs.
But what does this say about the requirements gathered in the early part of the project? First, it means that the customers need to already know exactly what they want, and how they want it to appear, function, etc. It also makes the assumption that customers will know the full extent of their needs, encompassing the totality of the project’s objectives. This seems a daunting task, and rather an unfair one to the individuals trying to collect these requirements for the design team. To combat this, a process just for requirements development is practiced by many professionals in a waterfall project. Requirements Engineering (RE) is the practice of identifying, modeling, communicating and documenting requirements within a project (Eberlein, Maurer, and Paetsch). RE is concerned with getting requirements done right the first time, because it assumes that 1) mistakes found later in the project’s life are more costly to correct, and 2) stable requirements can in fact be established before design and implementation begin (Eberlein, Maurer, and Paetsch).
There are many ways that requirement engineers can work to obtain the necessary requirements and help to build a stable set of needs for the design and implementation teams. Activities such as interviews, scenario discussion, prototyping, brainstorming, and focus groups can all help to bring to light the needs and wishes of the customers. By eliciting these requirements from the customers, the requirement engineer is making sure that all of the components of the project’s mission are being brought to life. Further tools like modeling and joint application development (JAD) can help to bridge the gap between what the customers envision and what the developers can make possible (Eberlein, Maurer, and Paetsch). It is also the requirement engineer’s responsibility to ensure that these collected requirements are properly documented, and that any changes to the requirements are also retained and versioned. Documentation of the requirements is a paramount part of RE. It is the “holy bible” of requirements for the entire project. Finally, before the final requirements are presented to the design team, a consensus should be agreed upon about the “correctness” of the requirements. Once all of these activities have been completed, the project would move into the design phase.
But what if a customer makes a critical discovery later in the project’s life? Or what if the design team determines that they can’t provide a necessary functionality that was desired by the stakeholders? Should the requirements change, it becomes a difficult task to incorporate those changes into an already existing architecture or framework. Many times, if an important and unexpected change must be implemented the development team may need to start over and redesign or put in a new implementation of the application (Sillitti, Ceschi, Russo, Succi). Furthermore, if the requirements have a critical change later in the project, the RE process has “failed” to capture a complete and stable picture of the requirements before design.
Does this mean that the requirements gathering effort was a failure? Not likely. But does it translate into additional work for the design and implementation teams when these requirements change? Most definitely. As a change is discovered, it becomes more costly to fix the further into the project it is discovered. Also, the customer’s faith in the project may be brought into question. In fact, “100% of the document-driven (companies) consider the customer ability specify completely, precisely, and correctly the requirements, at the beginning of the process, “not much satisfactory””(Sillitti, Ceschi, Russo, Succi).
Are waterfall projects ever successful? Yes, although there is varying degrees of just how successful they are considered. One of the major complaints about waterfall projects is that they are too rigid and unable to accommodate the changes discovered in nearly all software projects, particularly as requirements are changed or modified. To combat this, new methodologies such as Agile methodologies have been introduced, in the hopes that a change in process will change the outcome and success rates of projects.
Recent changes in software development have produced a variety of new methodologies for how projects are managed. One of those methods is Agile. In Agile, many of the major tenets of waterfall development are pointedly ignored. People are considered more important than processes, and working examples of code are more highly valued that detailed documentation (Paulk). Instead of independent phases of the project lifecycle, many of the activities such as analysis, design and implementation are done concurrently, often several times over. It is an iterative progress that repeats over and over until the desired result is achieved.
One of the major differences between a waterfall process and Agile is how requirements are gathered and maintained. Instead of the document-driven requirements found in waterfall, Agile incorporates them into the product. Often, customers and developers are in the same physical location, talking through the needs of the project. A common tool used in Agile is prototyping. As the customer walks through the necessary requirements, analysts and developers are working to make those needs a reality, sometimes in real time. It is a working solution to “show” the customer their requirements in action. As the requirements are fleshed out, changes might be recognized. Because there is no distinct separation of requirements gathering, design, and implementation, often a much faster rate of turnaround is achieved. Furthermore, important decisions such as architecture and overarching system design are not made at the beginning. This gives the development team the flexibility needed to incorporate these changes in the requirements.
Agile requirements are gathered in many of the similar ways that are found in RE. Interviews, prototyping, and JAD are common methods of giving life to requirements. However, the focus is not on documented the requirements, but rather making them visible to the customer and allowing that customer to interact with the system, helping to discover potential flaws or improvements. It is a much more dynamic and free-flowing style of encompassing the requirements of the project. But herein lays the rub. If requirements can be changed without a lot of oversight, or if new requirements are being found on a continual basis, how can the requirements be contained? Scope creep is a potential downfall to the Agile method, as are requirements that repeatedly change, sometimes on a daily basis. How then can an Agile projects stay within the scope of their mission, and how can we get consensus from all customers?
Requirements are the backbone of a software project. They define what the application will be used for, how it will do this, and what constraints the application will operate within. Requirements often are driven from rules within the business. Requirements should align with the daily processes that the company uses to operate as a whole. In this way, the application and the requirements that define it are a part of the entire system that defines the company. So why are requirements often changed during a project? Many times, the needs of the project are not fully understood at the beginning. Sometimes errors are found in the logic of how decisions are made about a process or a function of the application. And many times, simply not enough is known before the project begins. It depends on what is discovered once the project progresses.
In order to adjust for these changes in preferences, business rules, or lack of foresight, requirements much often change. But as we discovered in the waterfall technique, this can be dangerous to the project that has already documented their requirements prior to design and implementation. Changing requirements are a risk, one that becomes more expensive the later they are found. If systems architecture has already been decided, too drastic a change in requirements can effectively derail an entire project’s efforts. The waterfall method is primarily useful only when the requirements are expected to have a very low turnover rate, and when the technology to be used is well understood (Eberlein, Maurer, and Paetsch ).
Conversely, Agile methods of requirements gathering are very fluid. It is not seen as a roadblock to progress when requirements need reworking. Instead, requirements are simply added to the already ongoing work, and a new example is given to the customers. In fact, it is the customers that help to continually mold the final product, offering insight and suggestions to the work in progress. But here too risk is involved. Customers can begin to give conflicting requirements. Requirements that may seem concrete one day can be scrapped another day. Sometimes the customers on a project have differing opinions on what requirements should be, and political or organizations conflict occurs. This often creates a rigid culture between organizational units, and is the main source of conflict within organizations (Sillitti, Ceschi, Russo, Succi).
Because these requirements can and do change often on an Agile project, it must be considered beforehand that scope could change. One study showed that 80% of firms employing Agile use “variable scope” contracts. This allows for requirements to be set at the beginning of each iteration, instead of at the beginning. Compare that to a waterfall project, where 75% of the time the requirements are set in stone before the design begins, in order to help control the amount of modification allowed (Sillitti, Ceschi, Russo, Succi).
But isn’t this flexibility in requirements a detriment to the stability of the project? To the conventional thinker, having requirements that can easily change seems to cast a light of uncertainty on the successful outcome of any software project. But here is where the Agile method shines. It is because of this flexibility that the creative powers can arise. Agile methodologies have an important aspect which directly affects this: There is an emphasis on highly skilled people in agile methods (Sillitti, Ceschi, Russo, Succi). The design and implementation is not done merely by unprofessional “code monkeys”, whose only job is to take the blueprints given to them and verbosely translate that into a working application. Instead, the developers are encouraged to be proactive in their assessment of the application, what is being requested, and determining how a solution can be created. This dovetails nicely with the core Agile belief that documentation is less important than working software (Paulk). To the Agile developer, having a customer in the room discussing the needs of the project is immeasurably more important than being sure that the documented requirements are sound. Change is regarded as growth, and the progressive nature of software development in an Agile shop expects those needs of the customer to blossom as well.
However, some caution must be exercised when dealing with Agile requirements gathering techniques. Many of the employed methods are the same – interviewing, mockups and models, and JAD. It is important to note that the major difference between waterfall approaches and Agile is the presence of the customer. In waterfall, there is a distinction between when requirements are collected, and when development begins. It separates the customer from the development team. When the requirements are well understood and highly unlikely to change, this can actually be a benefit to the project. Stability in requirements creates stability in the further steps of design, implementation, and eventually the final rollout of the application. If requirements are not changing, project timelines and expenditures can be more accurately budgeted. Less reworking of the architecture is also a benefit to having stable, well understood requirements.
Agile projects are difficult to estimate, especially for companies not used to running projects with an Agile mentality. If requirements will be rapidly changing, it can affect not only timelines but also the level of “success” a project results in. Customer opinion of the development team can suffer if working software is not being created to their needs. “Too many cooks” in the requirements delivery can cause conflicting messages to be sent. Sometimes, the customers themselves don’t really know how the functionality should work. They may know the high-level needs, but may have trouble detailing the particulars. Often, stakeholders make the assumption that the high-level description of the features implies the detailed procedural steps, (Lee, Guadagno, Jia) leaving the developers without a comprehensive picture. If developers proceed to write software that doesn’t fit the customer’s mental picture, rework will be needed.
Agile methods are not for the faint of heart or those that cherish their documents. Often what little documentation is written for projects, such as story cards, are ripped apart and thrown away multiple times per iteration. For the uninitiated, this can seem like sacrilege. It is the belief that working code is more important that drives this behavior. But that doesn’t mean that documentation is never created or relied upon. Lack of documentation might cause long-term problems for agile teams (Eberlein, Maurer, and Paetsch). Future team members may have questions that cannot be answered because the original developers are no longer available for questioning. Technologies may change. Sometimes the questions may be so large that it takes a team member too long to effectively answer. All of these are potential risks to an Agile project and documentation. To mitigate this risk, Agile methods depend on highly-skilled developers that should be writing good code, which can be investigated for future reference.
Another major concern for Agile projects is how to validate the work. In a waterfall project, the requirements are “set in stone”, being documented well in advance of the actual implementation. To verify, it is simply a matter of testing to see if the outcome produced equals the outcome expected. In Agile, there are usually not these clear cut examples. Instead, validation is made throughout the development process by testing against the function software being developed. If discrepancies are found, Agile promises a faster turnaround for the changes. By having the customer be a part of the conversation throughout the project, changes to the requirements can be quickly assimilated into the application.
The Agile methodology is growing in popularity. Agile methods were created because the perceived success rates of projects in the early 2000’s were only around 45% (SD Times). Since then, project using Agile methods have seen perceived success rates above 60% (Ambysoft). More shops are adopting Agile methods, whether it is Extreme Programming (XP), Scrum, or some other iterative process. Stakeholders are finding more success in Agile methods, as they have seen improvements. One area of improvement has been in requirements and their perceived correctness and accuracy. Half of all Agile firms choose agile approaches because they are trying to discover better methods for managing and gathering requirements (Sillitti, Ceschi, Russo, Succi). For those firms that choose Agile methods, as much as 75% of them report a very satisfactory level of satisfaction in the relationship with the customer. Compare that to only 13% of traditional, document-driven projects (Sillitti, Ceschi, Russo, Succi).
What I find most interesting is that the percentage of Agile shops employing a specific tool for requirements traceability (63%) is higher than those shops using traditional methods (50%) (Sillitti, Ceschi, Russo, Succi). For not focusing on documented requirements, it seems like the Agile shops are doing it smarter!
Traditional, or waterfall, methods of project management still have their place in software application development. If the requirements are well understood, or already defined, then a waterfall approach may be sufficient. But in today’s rapid development atmosphere, Agile is becoming a key player in how projects are managed.
Requirements in Agile can be successfully used, if they are maintained and held to standards agreed upon by all parties involved. Agile projects must be implemented by highly skilled people who have had experience with Agile methods in the past. Requirements and documentation should be kept to a minimum level of necessity, but if done correctly can help speed up the project’s velocity and success. Agile methods appear to be making great strides towards overcoming the failures of previous waterfall methods and turning out more projects deemed “successful”. It is because of these successes that companies will continue to employ Agile methods in their future projects.
There are two keys to successful documentation on agile projects. The first is finding the point of “just enough” documentation. This is difficult to determine and will vary by project. Fortunately, the iterative nature of agile development allows you to experiment until you get it right. The second key to successful agile documentation is to not get attached to it or have unrealistic hopes of keeping it updated. Documentation must be created to serve a specific purpose, and after it has served that purpose you’ll all probably have more important things to do than keep updating the documents. It may seem counterintuitive, but it’s often better to produce fresh documentation the next time some is clearly required. A side benefit of starting over each time you need to document part of your project is that it’s great incentive to keep your documentation efficient!Lindstrom, Lowell, and Jeffries, Ron. “Extreme Programming and Agile Software Development Methodologies” (2004). Auerbach Publications, Inc.
Paulk, Mark. “Agile Methodologies and Process Discipline” (2002). Institute for Software Research. Paper 3.
Sillitti, Ceschi, Russo, Succi. “Managing Uncertainty in Requirements: a Survey in Documentation-driven and Agile Companies”. Center for Applied Software Engineering, Free University of Bozen.
Eberlein, Maurer, and Paetsch. “Requirements Engineering and Agile Software Development”.
Lee, Guadagno, Jia. “An Agile Approach to Capturing Requirements and Traceability”. School of Computer Science, Telecommunications, and Information Sciences DePaul University, Chicago.
Fowler, Martin. “Using an Agile Software Process with Offshore Development” (2003). http://www.martinfowler.com/articles/agileOffshore.html
Tomayko, James. “Engineering of Unstable Requirements Using Agile Methods”. Carnegie Mellon University.
Cockburn, Alistair. Agile Software Development: The Cooperative Game. Pearson Education, Inc. Boston, MA. 2007.
Robertson, Suzanne and James. Mastering the Requirements Process. Pearson Education, Inc. Boston, MA. 2006.
“Answering the “Where is the Prrof That Agile Methods Work” Question. http://www.agilemodeling.com/essays/proof.htm. First access Oct 23, 2011.
“2010 IT Projet Success Rates Survey Results”. http://www.ambysoft.com/surveys/success2010.html. First access Oct 23, 2011.
“Recursivity – Is Agile vs. Waterfall the Wrong Fight?”. http://blog.recursivity.com/post/1174740958/is-agile-vs-waterfall-the-wrong-fight. First access Oct 25, 2011.
“Escaping the Waterfall: Reducing Risk with Scrum”. http://www.agilejournal.com/articles/columns/column-articles/5887-escaping-the-waterfall-reducing-risk-with-scrum. First access Oct 23, 2011.
“Ken Schwaber on Agile: It pushed success rates beyond 45%”. http://www.sdtimes.com/content/article.aspx?ArticleID=35653&page=1. First access Oct 23, 2011.