"The requirements, in whatever form they are gathered, are the most critical part of the whole development effort. If you get them wrong, then nothing else matters, regardless of how well you do it. "

Agile Development Uncovers Today’s Requirements

Agile development brings with it a wonderful opportunity to test requirements and their effects on your customers. The requirements are today’s requirements, not those that somebody thought they wanted sometime last year. Collaborating with your customer helps you find the subtle nuances of the requirements.

Those Aren’t Requirements!

By focusing on software solutions and using input from a narrow group of people (sometimes just one), you don’t understand the real needs of the business. Requirements — the true business needs — are found by looking outward, not inward. Being agile means you are just building the wrong system faster.

Opening Statement

When I speak with clients who are moving to, or want to move to, an agile process, they frequently tell me that they are hoping to save the time they currently spend on requirements. I am not sure where they get the idea that products built by an agile process do not need requirements, but this seems to have become a popular misconception. And it's one that arises, I am afraid, because the nature of requirements is elusive and little understood.

IMPROVING WORK

What the software does -- and this applies to any software except games -- is to improve somebody's work. The software builder is improving the work done by somebody or, in some cases, something. It does not matter whether it is software to detect an enemy sniper (which improves the soldier's work) or to calculate the optimal takeoff speed of an aircraft (which improves the pilot's work) or to reduce the factory inventory to its optimal level. In short, software developers are in the business of improving work.

However, improving someone's work is not enough. We also need some way of knowing whether improving the target area of work contributes to the wider objectives of the organization containing the work.

The software must not only improve the work and thus contribute to organizational goals, but it must also do so in a manner that is pleasing and efficient enough to entice its user to use it. If you work for a product company, then you well know that ungainly, awkward, or difficult-to-use software does not sell. If you build software for inhouse consumption, your users will find some way of ignoring or sabotaging your efforts if you do not pay attention to the way your user community looks at its work. Inappropriate work metaphors, clumsy workflow, or hard-to-understand language will be punished by a maliciously compliant workforce. These factors are some of the nonfunctional requirements that must be understood if the product is to succeed.

THE BUSINESS NEEDS, NOT THE SOFTWARE NEEDS

Clearly the product's requirements -- what it has to do for the organization and how well it has to do it -- cannot be left to chance or the good intentions of the builders. If the builders are to succeed, they must understand the real nature of the business deploying the software. This fact should be fairly obvious, but it seems to escape many developers as they rush to their keyboards. It appears to be a lesson that we (the IT industry) have learned -- painfully -- in the past and yet seem anxious to forget.

I recently witnessed an example of the needs of the business being trumped by the need to start programming. The client asked me to look into the way expenses were repaid to professional staff. The current way of doing it was consuming too much time and effort and was unpopular with most people connected to it. An employee would submit an expense claim each month. The claims were forwarded to the line manager for approval, then the claim and receipts were sent to Accounts Payable for processing and payment.

The developers were proposing a solution in which the claim would be entered using a smart form. The system would allocate an identifier so the claim could be tracked as it went through the approval process. The paper receipts would be tagged and sent to Accounts Payable for filing. The approved claim would be automatically forwarded to Accounts Payable for processing. The repayment was to be made by electronic transfer to the claimant's bank account.

Was this a good solution? Not at all. While it showed some good design ideas, it also showed that the developers had concentrated on the software and not on the business. Let's examine some of the steps:

• The line manager approves the claim. Why? The majority of claims are honest, as are the claimants (this is true for most businesses). While there is a need for managers to see the claims, there is certainly no need to delay a claim by making it wait for approval. Any discrepancies or disallowed claims discovered after repayment can easily be rectified in a subsequent month.
  
  
• The receipts go to Accounts Payable before the claim is settled. This is not necessary. Paper receipts are needed only in the event of claims being questioned by the tax authority. The receipts can just as easily be kept by the claimant, who is quite capable of putting several pieces of paper in an envelope and writing the date of claim on it.
  
  

This story has a happy ending. Once the real requirements were pointed out, the developers designed and implemented a simpler and more workable software system. The essence of it was to put the claimant online to the Accounts Payable system. The claimants are happy with the new process because they are repaid quickly -- sometimes on the same day -- and managers express satisfaction that they are no longer the bottleneck but can review claims as their schedule allows.

Note how this resolution came about: by studying the business and ignoring, for the moment, the software solution. In this case, as is fairly normal, the requirements were found by looking outward, not inward.

AN IPOD IS A SOLUTION; THE REQUIREMENT IS MUSIC

There is a difference between a requirement and a solution. The requirement is a need, whereas the solution is some part of an implemented piece of software. A pop-up window is a solution. So is a pull-down menu of country names, or an automatic lookup of an address book, or anything else we build out of software. You cannot determine whether these things meet a requirement -- in other words, a real business need -- unless you know what the business need is. Merely providing whatever the customer says he or she wants cannot guarantee you are meeting this need. Bitter experience shows that in many instances the customer working with the development team does not -- and it saddens me to say this -- know the real needs. These needs will, however, be discovered some time later when the change requests start to arrive.

Requirements are about business needs, not clickable buttons and floating pallets. The requirements, in whatever form they are gathered, are the most critical part of the whole development effort. If you get them wrong, then nothing else matters, regardless of how well you do it. The most elegant design cannot overcome the wrong requirements. The most perfect plans, the most effective risk management, the best project or program managers, the most effective or skilled programmers cannot overcome a deficiency in the requirements.

AGILITY AND REQUIREMENTS

The Agile Manifesto tells us that working software is to be valued over comprehensive documentation. Sadly, its overenthusiastic proponents see this plank of the manifesto as an opportunity to reject any activity that suggests documentation -- usually at the expense of capturing the real requirements for the business. Software can document itself, but it cannot document the wider business deploying that software.

In our first article, Rachel Davies and Helen Sharp tell us about capturing the wider business and, at the same time, give us an overview of how requirements can be captured in an agile environment. The article contains helpful guidance for anyone moving to an agile process, and it highlights many of the common pitfalls. As the authors observe:

Stories are not standalone written documents. Rather, they need to be understood in the context of an ongoing two-way conversation between the business and development teams.... Without this level of communication, the stories would become disconnected from the business requirements, and the software being developed would be unlikely to fulfill the business needs.

Davies and Sharp also tell us about planning the development effort and the crucial role of requirements in both planning and development.

If agile processes are to overcome the problems of gathering accurate requirements, then attention has to be paid not to the solution but whether the solution is solving the right problem. Chris Rupp of the Sophist Group in Germany has been involved in this conundrum for quite some time. Her article proposes that in order to communicate effectively, we have to get past the complexity trap and the communication trap. Large, complex systems involve many disciplines, and this in turn means involving a larger number of people who need to understand each other. Rupp's intelligent and relevant analysis of human communication will help any of us to better participate in the requirements conversation.

Cutter Consortium Senior Consultant Sam Bayer gives us insights into learning requirements by using customer focus groups (CFGs). In his article, Bayer tells us how he has used these groups when finding requirements -- with some surprising results. In the several instances he cites, the real requirements came to light after the first iteration of the product (or a model of the product) had been built and subjected to a focus group. Please note in his examples how the real needs of the business were uncovered -- not by extensive study before the event, but by demonstrating a prototype to the prospective business and using the collective wisdom of the CFG. The example that most warned my heart is the one in which the elaborate software solution was abandoned in favor of a simple solution that gave everybody just as much as they needed.

While it is not necessary to write the requirements, it is crucial to understand them. Keep in mind here that the people giving you the requirements do not always understand them either. Arriving at the correct understanding may take time, and it always takes communication. In our next article, Kert Peterson and Matt Smith tell us how they have used techniques derived from improvisation -- the same improvisation used by actors in the theater -- to help communicate with customers. They give us a terrific understanding of how improvisation can work by illustrating it with an example from their project portfolio. In the end, listening -- which usually turns out to be the most important part of communicating -- led the development team to uncover the real requirements.

Matthew Gelbwaks and Jerry Odenwelder work for product development at Borland. The needs of a software product company are different from those organizations in which the end product is intended for inhouse consumption. Gelbwaks and Odenwelder take us through the agile process they helped build at Borland. When you read this article, pay attention to the problems they encountered and how they solved them. After all, you have by now read dozens of articles promising you amazing success with no downside if only you adopt an agile process. I find it particularly refreshing to hear from people who have problems along the way, tell us about them, and then tell us how they managed to solve them to the benefit of better requirements.

Finally, Martin Bauer gives us an article entitled "Agility vs. Requirements." The title gives us a clue that agile processes are not an automatic panacea to the requirements problem and may, in fact, contribute to it. Bauer explores this theme by giving us two case studies -- both of them real agile projects -- in which the requirements were handled differently. In one case, the requirements were written, and in the other, they were gathered in a more agile fashion directly from the domain expert. Which one proved to be the best? The answer, dear reader, awaits you.

The question posed for this issue is "Do agilists understand requirements?" The articles in the issue do not give us a definitive answer. However, the authors give us insights and lessons through their experiences with requirements in agile environments. This is in line with the maturing nature of agile processes. The question is no longer "Should you move to an agile process?" but "Will your agile process deliver the right product?"

ABOUT THE AUTHOR