News

Requirements guru shares 'cosmic truths'

• By John K. Waters
• November 10, 2004

Requirements are the foundation of every software development project. Good, bad, or ugly, everything gets built on them.

Karl E. Wiegers believes that developers can put a little rebar in that foundation by recognizing a set of nearly universal requirements principles he calls "cosmic truths."

Wiegers is principal consultant with Process Impact, a software-process consulting and education company in Portland, Oregon. He's also the author of "Software Requirements, 2nd Edition" (Microsoft Press, 2003), "Peer Reviews in Software: A Practical Guide" (Addison-Wesley Professional, 2001), and "Creating a Software Engineering Culture" (Dorset House Publishing Company, 1996).

The key to requirements that are accurate, consistent, and unambiguous, Wiegers says, can be found in a handful of principles that emphasize the critical contribution that good requirements make to a project's success, as well as the critical contribution that customer involvement makes to good requirements.

Wiegers shared these principles with attendees at the recent Better Software Conference in San Jose, Calif. Here are his top three:

1. "If you don’t get the requirements right, it really doesn’t matter how well you do the work on the rest of the project, you will fail."

"I’m not talking about getting all of the requirements on the first specification," he says. "We all know that that doesn’t work. I’m talking about a whole set of requirements knowledge that you become aware of over the course of a project."

2. "Requirements development is a discovery and invention process, not a collection process." Requirements development, he says, is an intrinsically iterative process.

"I’ve heard people say that they are 'collecting' requirements, and I’ve used that phrase myself," Wiegers says. "It calls up a mental image of people walking around with a basket labeled 'requirements.' But it doesn’t work like that. It’s not a matter of picking up requirements from wherever they happen to be hiding, or sucking them out of users’ brains in full form. Instead, it’s an exploratory process. You have to plan on being presented with some, discovering others, and making some stuff up as you go along-- particularly when you’re doing highly innovative things that people haven’t done before."

3. "Nowhere more than in the requirements process do the interests of all the project stakeholders intersect."

"Everybody on the project either makes a contribution to or feels an impact from the requirements," he says. "Unfortunately, we have this giant tower-of-babble problem around the requirements area. I could read a single requirement to this audience, and someone would call it a business requirement, while someone else would call it a user requirement, or a product requirement, or a systems requirement, or a functional requirement. All of these different terms make it almost impossible to communicate effectively." The answer, he says, is to get all stakeholders involved in the requirements development process.

"It helps everyone to get a more common foundation, vocabulary, and general understanding of the different kinds of requirements," he says.

Wiegers' list of cosmic truths also includes:

• "Customer involvement is the most critical factor in achieving software quality." 
• "The customer is not always right, but the customer always has a point." 
• "Change happens." 
• "If it’s not in the requirements specifications, don’t expect to find it in the product." 
• "Even the best requirements document cannot replace human dialog." 
• "You are never going to have perfect requirements."

More of Wiegers' requirements engineering insights (as well as his favorite recipes) can be found at http://www.processimpact.com/index.shtml.