Summary
Code can be perfect, and also perfectly useless at the same time. Getting requirements right is as important as making sure that requirements are implemented correctly. How do you verify that users' requirements are addressed in the code you're working on?

Many books and tutorials about agile development start out with a familiar scene: a developer sitting with a customer, together defining the requirements and setting the milestones for a project. Complex project management tools, as well as suit-and-tie business analysts, are shunned in favor of paper and pencil or, better yet, the back of a napkin or an envelope.

This scene about agile requirements gathering came to mind earlier this week, when I interviewed for an Artima news story Rob Cheng, Borland's director of developer solutions. Cheng, whose job involves talking not only to developers, but also to CIOs and CTOs, noted that real-world requirements gathering is far from being agile in most IT shops, often resulting in the following scenario:

The most common thing we hear from CIOs is that code can be perfect, but the application can be perfectly useless because it's not doing the right thing. It may be doing the wrong thing very well, but not doing what the business needs...

[Direct communication between developers and users] is a best practice that's not done nearly enough. There is often not enough involvement not only of developers, but also of Q&A practitioners and management, in meetings with customers... Agile development tools [such as a continuous integration server] are not enough. If people are not in the room, the process is broken.

Cheng considers getting requirements right a part of overall project quality:

Testing doesn't help, unless you're testing for the right thing. It's not so much about tools and products that can automate testing, but about [whether] you're testing the right things. You may have some... steps in the functionality of your application that you can write into a test suite, and you can automate the execution and tracking of that test, but that may not be what the end-user or the business really wants...

You need to make sure that you consider not only code coverage, but also requirements coverage: How much of the validation and testing are covering the things that the end-user or business values?

That's easier said than done. Even if end-user and developer communicate directly and constantly, it's not obvious how to formally validate requirements coverage. Requirements are often narrated in a language as imprecise as English, Dutch or Kirgiz, and are captured either as word-processing pamphlets, Wiki pages, email fragments, not to mention the back of Starbucks napkins.

At your company, how do you validate requirements coverage? What tools and methods have worked for you in capturing requirements so that your code ends up not only perfect, but also perfectly useful?

Talk Back!

Have an opinion? Readers have already posted 9 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.