Agility vs. Requirements

Martin Bauer

The question posed is whether agilists understand requirements. The answer is both yes and no. A formal requirements phase is not necessary for a project taking an agile approach; the project team finds another way to determine the requirements. Whether this approach is better or worse than a formal requirements phase depends on how long it takes for the agile project to accurately establish the business needs the solution is to address. If it takes longer than it would have if formal requirements existed, then it was the wrong approach. If it was quicker and just as effective, then it was the right approach.

The question posed is whether agilists understand requirements. The answer is both yes and no. A formal requirements phase is not necessary for a project taking an agile approach; the project team finds another way to determine the requirements. Whether this approach is better or worse than a formal requirements phase depends on how long it takes for the agile project to accurately establish the business needs the solution is to address. If it takes longer than it would have if formal requirements existed, then it was the wrong approach. If it was quicker and just as effective, then it was the right approach.

Of course, the catch is we don’t get the chance to do the project twice, with or without a formal requirements phase, so we can never be sure which way was the best way. The real answer is it depends on the nature of the project. This article will explore the outcome of two agile projects, one with written requirements and the other without, to illustrate the issues that arose in both cases. These are real projects, although some names have been changed.


The CIT project involved a large Web-based application for a telecommunications company. SoftTel, a software development house specializing in telecommunications software, had won the contract to supply a Web-based solution. The purpose of the solution was to work out provisions for new services. Normally when a new service was requested, design engineers would take weeks to work out the appropriate paths in a complex telecommunications network. Let’s say a dedicated SHDSL service is required from an office in one state to an office in another state. The design engineers would determine the pathways from the originating office to the local exchange and then to each successive exchange all the way to the target office. Finally, they established a plan of how the service would be connected and passed it onto the provisioning part of the business. All told, the turnaround for installing a new service could be 30-40 days. The goal of the project was to automate the design process so that the service could be installed more quickly.

SoftTel had recently been trained in an agile method, Feature-Driven Development (FDD) (see Figure 1). The company decided that it would like to try FDD’s fiveprocess method on this project. For readers not familiar with FDD, the sidebar on pages 34 and 35 provides a brief overview. For a full understanding of FDD, visit


FDD was first documented after a large banking project run by Jeff De Luca in 1997, before the agile movement was established. The method was published in the book Java Modeling in Color with UML by Peter Coad, Eric Lefebvre, and Jeff De Luca [2]. FDD is a lightweight methodology, and it was identified as an agile method in Jim Highsmith's book Agile Software Development Ecosystems [3].

It consists of five processes.


In Process 1, the project team creates an object model of the business domain under the guidance of an experienced object modeler in the role of chief architect. The model is not fully defined with all attributes and methods; it is more about getting the shape (i.e., the major classes) of the business process captured correctly in an object model. The process is highly collaborative, with everyone working together to create the overall model, one piece of the business domain at a time, until everything has been covered. The end result is an overall model of the business domain. This approach helps the project team ensure consensus and understanding, manage scope and expectations, and establish who is best placed to play specific roles within the team. These outcomes are fundamental. If the project team doesn’t get them right, the risk of scope creep increases, as there’s a greater chance that people don’t fully understand the needs of the business.

FDD and Requirements

FDD does not stipulate a formal requirements process. Of course, no project can commence without some idea of what it’s trying to achieve. Some agile methods may claim to, and on small projects may even get away with it, but on larger projects this practice has the potential to cause significant problems. The two main problems are scope creep (when it becomes clear that the project is larger than expected) and getting the solution wrong (which usually surfaces when a release is shown to the client).

By applying themselves to Process 1, however, team members get an understanding of the business domain and the business goals for the project. This is what good requirements are supposed to achieve. Process 1 takes a further step by enabling the team to analyze the requirements during the modeling process.

One of the many criticisms of requirements is that they are not realistic or meaningful. This is part of the reason why agile approaches may appear to forgo this step. However, it’s not that requirements are unnecessary or misleading, it’s that often they are not properly collected and analyzed. (I will discuss this point further in the second case study.) Since Process 1 includes domain experts, the project team gets the true requirements of the business from the horse’s mouth, so to speak, and these requirements are formally tested in the modeling. If a requirement is difficult, complex, or unreasonable, it becomes very clear when the team tries to model it. This means it’s not necessary to have a formal set of written requirements to commence an FDD project.


In Process 2, the project team identifies all the features to support the requirements. Creating the features list is the task of the chief programmers involved in the modeling process. The client and stakeholders don’t need to be a part of this process; they made their contribution in Process 1, and now it is a matter of capturing the project in a list of features. The key to this process is defining the project using the language of the business domain. This means that the client will be able to understand and value each feature. It also enforces a common language across the project team and reduces the risk of miscommunication or incorrect assumptions.


In Process 3, the team produces the development plan. This process gives the project manager a means of planning the development phase in a meaningful way for both the client and the programmers. It is done in conjunction with the development manager and chief programmers.


Process 4 is a per-feature activity that produces the feature design package. It is broken down into three steps: domain walkthrough, design, and inspection. In the domain walkthrough, the programmers familiarize themselves with what they need to build before starting on a detailed design. The design usually takes the form of a sequence diagram and is the main step in this process. The design is then inspected so that defects can be found and removed before a single line of code is written for that feature.


Process 5 is a per-feature activity that produces a completed client-valued function (feature). It is also broken down into three steps: code, code inspection, and promote to build. As with Process 4, collaboration is promoted through the use of a code inspection. Inspections are one of the most effective techniques for reducing bugs, and FDD makes this a key part of both Process 4 and Process 5. What makes Process 5 distinctive is that a task is not finished until it is promoted to the build. This makes very clear what is finished and what still needs more work. Developers may say something is “finished,” but it’s not until it’s actually in the build.

Undergoing Process 1 Even though SoftTel developers had been trained in FDD and intended to use the method on the CIT project, the company decided to enlist the help of an FDD expert (who ran the company I worked for) to manage Process 1. The main domain expert had previously been involved in a similar project and therefore had an excellent understanding of what was required for this project. Consequently, the project started without formally written requirements.

As described above, Process 1 is a collaborative activity. SofTel rented an offsite location for the duration of Process 1, and all the key people were in attendance. As the domain expert knew the majority of the requirements, he played a key role in Process 1. The domain was broken down into its main subject areas. For each subject area, the domain expert explained how the system was to work; the project team then modeled this part of the system. After the team members modeled each subject area, they merged the individual models into an overall model.

The modeling process was expected to take two weeks. At the end of the first week, it was clear it was going to take longer, given that only a quarter of the subject areas had been covered. After four weeks, Process 1 was completed and the overall model was ready.

Project Issues The processes of building the feature list and planning development went smoothly, as did the start of development. Based on the FDD rule of thumb for project size, which states that Process 1 should be approximately 10% of the project time frame, the project should have taken approximately 10 months to complete. As the project had increased in size, SoftTel contracted with the FDD expert and his team of developers (chief programmer and three developers) to help in the development phase.

Halfway into the project, a number of features had been completed and some of the functionality had been released, allowing us to get client feedback. This was also the point at which details of certain subject areas needed further clarification. The model created in Process 1 was an overall model; as each feature was developed, a detailed design was done for it. On many of the features, this approach proved to be satisfactory. However, on more complex features, it was necessary to go back to the domain expert to seek further clarification. That’s when problems started to arise.

Clarification Is Hard to Come By

The first issue was access. The domain expert was a department manager at SoftTel, and as a part of his management duties, he was involved in pitching for new business. This meant he was often out of the office, which made timely access difficult. As there were no formal, written requirements, the developers had nothing to rely on when the domain expert wasn’t available. This caused inevitable delays and frustration. Development had to wait until the domain expert was available to answer questions, and while e-mail was sometimes sufficient, at other times a face-to-face meeting was needed to resolve an issue.

The second issue was consistency. At a high level, the model from Process 1 was correct, but when it got into the detailed design for each feature, things didn’t always quite fit together as expected. When we queried the domain expert on these issues, it became clear that there were gaps in how things were supposed to work. The domain expert would provide further details on what was required, and the developers would implement these requirements, only to find they raised further issues. As a result, the team required further clarification, and at times it became clear that the requirements didn’t make sense. This put the domain expert in the awkward position of being shown to be wrong.

After a series of arguments between the domain expert and chief architect, the project was starting to look as though it was in serious trouble. The project rested in the heads of two people who didn’t want to talk to each other. As no formal requirements existed, the project needed the domain expert. Replacing the chief architect would also be problematic, as none of the developers had the same skill level. It would mean a considerable delay to find a new architect and get him or her up to speed on what was a very complex domain. In short, the lack of requirements meant the only way forward was to resolve the tension between the two key players. In the end, a new project manager was appointed to mediate between the key players. Over a period of six weeks, tensions eased and the project was completed, but not without having a negative effect on morale, budget, and timelines.

Written Requirements Would Have Helped

The key problem in this project was that the requirements were in the head of a single person, the domain expert, who had other responsibilities and was often away from the office. Even though Process 1 helped the team to understand and determine the shape of the business domain, it wasn’t possible to test the requirements properly at this point because they weren’t written down. The project relied on what the domain expert knew at the time, and not enough detail came out during Process 1. Had the domain expert taken the time to write the requirements prior to Process 1, it would have exposed gaps that only surfaced later in the project when he was unavailable.

Waiting until the domain expert was available to rectify errors in understanding caused frustration, delays, and rework. Having written requirements prior to the start of the project would have helped mitigate this risk. Even if the requirements weren’t complete, Process 1 would have exposed this risk at the start of the project when the options for dealing with the gaps in understanding would be cheaper and easier to fix.


  • How many people would be filling out the survey?

  • How many questions would the survey contain?

  • In what format would the data be required?

  • Was the survey anonymous, or did it require a login?

The client’s response helped us shape a one-page requirements document of how the survey would work, which we presented to the client with a quote. The individual in charge of the survey, who was a different person from the normal contact, was asked to confirm the requirements. The inhouse developer (our normal contact) would then contact the survey manager (the domain expert), who was based in another state. From this exchange, a few more details were established. Even though there was only one set of questions, the survey was going to be used by different organizations and required rebranding for each organization. This changed the nature of the entire project. The project manager went back to the architect to think things through. The result was a longer requirements document that accounted for the new functionality.

This process continued back and forth for four weeks, with each iteration of the document revealing more intricacies. The survey had optional questions that the different organizations could choose from. The survey was run not once but twice a year with a minor change for each round. The two rounds then had to be compiled into a single set of results … and so on.

After six iterations of the requirements, we were still working out the details. From the initial quote to the most recent rendition of the requirements document, the cost of the project had increased by over 2000%. Another major factor was timing. Initially what looked like a small project that could be completed in under a week was now a three- to four-month project. Internal politics required that something be delivered by the end of the year — only two months away.

Something had to be done to move things forward. The project manager organized a workshop with the business owner, the domain expert, and the inhouse developer. The workshop was a mini-version of Process 1; it established the high-level project objectives as well as roles and responsibilities.

The project objectives were to:

  • Increase survey response rate

  • Improve service to clients

  • Maintain control of annual survey(s)

The domain expert became the key contact for the project, and the inhouse developer no longer acted as the go-between.

Given the need to deliver something within a short time frame, the project was broken into two stages. The first stage was to develop the user interface so that people could submit survey responses. The second stage was to build an administration interface to manage the surveys and export data.

It was agreed that with the outcomes of the workshop and the requirements document, although not 100% complete, there was enough information available to commence development. The project manager pointed out that as the requirements weren’t complete, there was some risk; in particular, requirements for the administration interface were sketchy. The risk was that the quote for Stage 2 would need to be revised once these were specified. Because of the time constraints, the client accepted this risk, and we began Stage 1.

Within two months, we successfully delivered Stage 1. Stage 2 then started. It didn’t take long before we needed to get more detail on the requirements from the domain expert. As the domain expert was in another state, we decided to take an even more agile approach and build what we knew and expose that to the domain expert for further guidance. Then, based on the feedback, we would extend and modify. We went through a number of iterations, discovering more and more details that were never mentioned previously. At times, these details blatantly contradicted the requirements stated earlier. One of the key features of the survey was that all questions would be the same for all surveys except for the optional questions. When building the administrative interface, this requirement was proven to be wrong, even though the domain expert had explicitly agreed to it earlier in the project.

More contradictions surfaced, and the second stage of the project almost doubled in scope and, consequently, timeline and budget. The key problem was the underlying business process. The domain expert had made arbitrary decisions about how an existing paper-based process would be constructed as a Web-based application.

Even though the business process was exposed during the workshop, the domain expert assured the chief architect that it was fine to adapt it as the requirements stated. This proved to be impractical when the administrative interface was exposed and the domain expert realized the restrictions that would be placed on the Web-based version of the survey. The existing business process wasn’t clear; it changed each year depending on the needs of the client. The domain expert failed to mention this, the requirements process failed to capture this, and the workshop failed to expose this as a necessary and important part of the business process.

The product was finally delivered. The following year, the client decided to reengineer the business process to bring it into line with the Web-based application and thus ensure consistency across the board.


In the first project, the lack of written requirements forced reliance on the domain expert to provide input to the development team. However, due to lack of availability (and in some cases, lack of clarity) on his part, the project suffered. In the second project, the written requirements, admittedly gathered by imperfect means, turned out to be inaccurate and were later contradicted. Again this forced reliance on the domain expert.

In both cases, the need for a solid — and detailed — understanding of the domain proved to be the crucial project need, as it is for all projects. In both cases, the projects would have been considerably better off if the requirements — the real needs of the business under study — were gathered and communicated more effectively. We learned that if the requirements are to be made into a written document, then they must be provably complete and detailed enough to significantly reduce reliance on the domain expert. If the requirements are to be gathered in a more agile fashion with the domain expert on tap, then that expert must be placed alongside the project team and be available at almost all times. If the latter approach is taken, however, the potential risks should be understood so they can be appropriately managed.

What became clear to us is that it didn’t really matter how the requirements were communicated. What was important was that they were correct in the first place.


1. Bauer, Martin. “Successful Web Development Methodologies.”, 13 May 2005 ( 2. Coad, Peter, Eric LeFebvre, and Jeff De Luca. Java Modeling in Color with UML. Prentice Hall, 1999. 3. Highsmith, Jim. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002.