Some days, you wish you had telepathy. You just know that your development staff is holding back in some way, but you don’t know how to get them to communicate. Is the project in trouble, but they’re afraid to tell you?

Since your software development staff won’t tell you what they’re really thinking, I asked them to confide in us instead. I posed a single question to professional programmers and testers: If you could get your CIO to understand just one thing about software requirements, what would it be? From the answers, I collated the five things at the top of their minds. If you grok these concepts, you will win the respect and support of your programming department (prizes you’ll also earn for understanding the term "grok"), and you’ll optimize the chance of success for your next software project.

I must warn you that this will shock some developers. Most of them don’t expect you to have a clue.

1. The Inconvenient Checkbox: Understand the Role of Requirements

Many development projects are handicapped from the start. The requirements are vague and subject to interpretation, require intimate knowledge of the business to interpret correctly, and aren’t prioritized. "It’s a classic garbage-in, garbage-out situation," says James Pulley, director of professional services at PowerTest. "Poor requirements are provided to a development organization that either does not question them or receives hostile glares from the business community when clarification is sought. Items requiring insight or interpretation are interpreted one way by the requirement writer, a second way by development, possibly a third way by QA."

It’s critical to establish some sort of process for documenting software requirements—what one developer plaintively described as avoiding an ongoing guessing game. Yet, say many developers, managers often forget why they gathered the software requirements in the first place. QA tester Darrel Damon complains that some organizations act as though requirements are "an inconvenient checkbox that has to be gone through for legal purposes." In one project on which he worked, for example, management paid little attention to maintaining and updating the requirements. "It was as if the requirements checkbox had been checked, so we could move past requirements," he says. "When requirements did change, there was no formal notification to the rest of the team."

This was more than a political issue. During testing, Damon entered a defect report when he found a specific discrepancy between the application and the requirement. The business analyst said it wasn’t a defect; the application was right and the requirement document was wrong. "I argued that it was a defect regardless, because defects are not just in the app. I stood my ground and refused to close the defect. I finally got a meeting with the business owner; the requirement was right and the app was wrong. [The analyst’s] comment about it not being a defect because it was ’only a documentation issue in requirements’ spoke volumes about the value placed on requirements."