This article at CIO Online says that these 5 things are:
- The Inconvenient Checkbox: Understand the Role of Requirements. “But that’s the easy item. Most developers say their CIO understands the importance of requirements. It’s what happens after that where things get … interesting.”
- Don’t Throw It Over The Wall: The Right People Should Define the Requirements. Involve the stakeholders, not just at the beginning, but throughout the project. And they’re not the only ones — “If you don’t include us [developers and testers] on the time line generation, don’t expect us to meet the time line. If the general contractor on a building project doesn’t ask the brick mason or the electrician how much time they need, how do they expect to generate a realistic schedule? They can’t. If you don’t include developers and testers when you’re generating your time lines, don’t think you’ll hit them.”
- Superficially Complete: Define Requirements With “Enough” Detail. “So, how do you know how much detail is ‘enough’ for a software specification? There probably isn’t a single right answer. The savvy manager will recognize or create an appropriate corporate culture—which may mean asking developers and testers, during job interviews, ‘How detailed do you prefer application requirements to be?’ Because if a CIO thinks the requirements documentation should be one way and the development team wants it another way, friction is inevitable.”
- Working from Ignorance: Recognize that Requirements Change. “There is no cutoff point where requirements stop changing, believes developer Stefan Steurs, but many CIOs assume a point exists when everything is perfect and coding may commence. When developers, testers and users get involved in reviews, development, testing, prototyping, piloting and other activities, they feed the discovery process with new elements, some of which can be very disruptive.”
- Carpet Yanking: Pay Attention to the People on the Front Line. “Get out of the office. Talk to people. Manage by walking around. Find out whether the software requirements are being instantiated in the real world…But don’t pretend to listen if you aren’t going to take action.”