Agile vs Waterfall: Requirement Gathering

This is the second in a short series of posts that compares agile vs waterfall and how and why iterative agile development can deliver better results than a waterfall development project; and how it gives back control of the project and more importantly budgets to customers.

Requirements Gathering

In a waterfall project, the vast majority of requirements are gathered right at the start of the project, in a requirements phase. The intention is to define what needs to be delivered so that everyone knows the scope and has a detailed description of what will be built.

A business analyst typically spends a focused period of time with the end users of the system, or their representatives, to capture how the business functions, and how this is to be realised in the software that is developed. This all results in a collection of documents and diagrams, such a functional specification and set of use cases. These act as the definition of what will be built and is referred to throughout the project.

In the more successful waterfall projects the specification will be kept up to date throughout the project as change occurs.

So, what are the problems with this approach?

I'll get this when?

The primary issue is related to the waterfall project timeline. A waterfall project can take many months or years before it's delivered.

Put yourself in the end user's position and try to answer the question: "What will you need to do your job in a year's time?" Then also consider the follow-on (often unsaid) assumption: "If you don't ask for it now, then you may have to wait for another year whilst (if) we develop phase two".

Typically people are not sure:

  • What business processes are going to be the most important in a year's time. They often can't answer this until they have the system and are using it.
  • What changes might affect the business over the next year. Who would have predicted the financial crisis of 2008? What about regulatory changes? What might the competition may come out with?

So because of a level of uncertainty and knowing that they will probably have to wait for, say, two years if they miss out something important; end users will typically ask for everything that they can think of that they may need.

This means that you can very easily over specify what is required, inflating the required budget.

Then comes the bun-fight over what is a "must have" and what is a "should have" etc, in order to try and bring the scope down to something that is manageable in the anticipated budget. This leaves scars on both sides and frequently means an unhappy customer.

If you're building a bridge or a skyscraper it's important to get the requirements right up front because it's almost impossible to make amendments throughout the construction; but as I discussed last time, software development has the advantage that it is much more flexible and amenable to change.

Half-Life

So how much do requirements change?

We can use the concept of the 'half-life' of a set of requirements to consider how long they remain valid. By this, I mean the time required for half the requirements in a set to become redundant.

Half Life Of A Requirement

In "System Error: Fixing the flaws in government IT", which references "The Curse of the Change Control Mechanism" by Susan Atkinson and Gabriella Benefield, it is claimed: "that while the requirements of a project in the 1980s typical had a half-life of a decade or more, by 2000 this had fallen to two to three years. It is estimated that today; specifications have a half-life of about six-months".

This shows that if you're starting a year long project today, then when you deliver, only a quarter of the requirements will still be correct. This also underlines why waterfall was an acceptable methodology in the 1980s and 1990s, but is less suited to projects today.

How Valuable Is A Specification?

Another aspect to consider is just how valuable a specification document is to the business?

In waterfall, you spend the first few months analysing the business and writing the specification. At that point the customer has spent a reasonable amount of their budget and the only thing they have for it is a specification document and perhaps some UML models.

Are those artefacts of value? In reality they don't add much value to the business. The customer can't earn any return on their investment with those documents, they need some working software in order to do that. The documents don't provide a single line of functional software, they just act as a necessary step along the way to getting that functioning software.

Even worse, given the previous discussion about the half-life of a requirement, those documents become less useful every day as the requirements age.

Iterative Requirements

In an agile iterative project; the customer doesn't need to work out all their requirements in detail up front. Instead the broad scope of the project is defined upfront; and then each iteration we analyse enough requirements to support the delivery of that iteration's functionality.

Most importantly the customer gets the result of that iteration's delivery very quickly, which means that they have the confidence to ask for what is most important to them today, knowing that as the project progresses they can refine what they need. There's no more "I'll ask now since otherwise I have to wait two years"; instead they can specify what they want when it becomes important to them. If it turns out the requirement is never needed then they save themselves and the analyst the effort of doing any detailed analysis, let alone the effort required to build, test and maintain that functionality.

Additionally, if a new requirement they hadn't thought of comes in they can re-prioritise the functionality without going through expensive change control. For example, if a competitor comes out with a new capability, the customer can schedule in a response quickly, pushing other requirements down the priority order.

Finally, the customer, the analyst and the development team learn more and more as the project progresses, particularly once the software is actually in use. This means that they have more experience and can write better requirements. For example, the analyst will have learned more about the problem domain having seen the software in use, and they'll have a better handle on what works best for recording requirements based on their interactions with the developers.

Stories

How do we manage requirements if not through a specification document.

We capture "User Stories". Each represents a small piece of functionality that provides some value to the business. Providing some value to the business is the important phrase there. We need to focus on delivering value for our customers.

In agile, we only produce the level of documentation that it is responsible to produce; that isn't no documentation as many people might believe is the case; it's simply the level of documentation that is necessary.

For each story, it can often be enough to write just a few sentences. The title of story may even be enough, it will typically take the form "As a … I need to do … so that …". It says who needs the requirement, what it needs to do and why it is needed.

In a waterfall project the analyst often documents a requirement to a very detailed level. This can be due to a number of reasons:

  • The analysis takes place often months before a developer looks at the requirement so it needs to be comprehensive in order that all the details are "remembered".
  • The analysts are often geographically separate from the developers so it's difficult to clarify requirements quickly
  • The developers may work for another organisation and the specification forms part of the contract

In agile, we look to short-circuit all of the above.

A story is considered to be a place-holder for a conversation. It's more important, and quicker, for the stakeholders to talk with each other. Therefore it's important that customer representatives, analysts, developers and testers all work closely together on a story in a timely manner. Then if there are any issues the analysis is fresh in everyone's minds and the detail of the requirements can be clarified quickly with a brief conversation with the customer.

This does mean that customers have to work closely with the development team, they aren't able to simply spend a few weeks at the beginning of the project and then forget about it until the software is delivered.

So, the obvious question is how do we know what the detailed requirements are if we don't write them down? In the short term the answer is that team collaborate together while the software is being developed and so do not need to refer to detailed documentation.

In the longer term, the detail requirements are actually embodied in the working software (and automated tests) that has been delivered.

A philosophical answer is, do we actually care what the detailed requirements were if the customer was happy to sign off the deliverable at the time and we can see from the tests and working software what was delivered?

If, at some point in the future, there is something wrong with the software or it doesn't do what the business now needs it to do, then because of the iterative nature of the agile process, we can change the software in the next iteration to be in line with current requirements. Then the newly delivered software and test suite will embody the current detailed requirements.

Next time, I'll look at development and quality assurance.

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

X