Flaws found in requirements practice

Techniques for defining requirements at the beginning of a software development project are used by surprisingly few organisations, says US specialist Karl Wiegers.

Techniques for defining requirements at the beginning of a software development project are used by surprisingly few organisations, says US specialist Karl Wiegers.

Wiegers, principal consultant with Oregon-based Process Impact, gave a keynote address on requirements management to this week’s Software Developers Conference 2001, organised by Software Education Associates of Wellington and Sydney.

Wiegers says that techniques for defining requirements at the beginning of a software development project have been known and substantially unchanged for about three years, but surprisingly few companies developing complex software use the techniques to any great extent. Even something as straightforward as automated version control to avoid confusion between different versions of the requirements specification is little used, he says.

It clearly makes sense to keep all the requirements definitions and the links to material such as use-cases (outlines of what a particular class of user will do with the application) that generated them in a database in structured form. “But there are still a lot of [development teams] that rely on paper documentation.

“I’ve always wondered why that is, and I’ve not arrived at a satisfactory answer,” he says. “I think maybe it’s just arrogance; people say ‘I'm a good programmer, I find my own bugs, I don’t need these tools’. I don’t understand these people. When I’m developing, I need all the tools I can get.”

While the techniques have stayed the same for years, the tools for assisting structured management of requirements information have greatly improved, he says. Yet some developers ignore the tools completely and others buy them, but never use them. Another typical reaction, he says, is “if these tools are so great, why haven’t I heard about them?”

While the tools greatly ease such matters as version control, they are not the complete answer. “Don’t mistake a tool for a process,” he says; the process of good requirements management must be set up separately.

And it needs some people with different skill sets from those of many software developers. “The skills of interviewing and asking probing questions,” for example, to dig out the users’ true requirements behind the facile statements.

Small organisations, more common in New Zealand, may not be able to afford the time and the cost of tools to use all the techniques he outlined in his address; they may have to pick and choose, he acknowledges. “You should use the techniques appropriate to your situation, appreciating the risks.”

But having a permanent record of requirements, use-cases and decisions taken is a key principle for operations of all sizes. You may think that because there is a development team of only five that you communicate very well by word of mouth, he says, but there will inevitably be problems when someone leaves and problems for people joining and coming new to the project if there is insufficient written record.

Top 10 development traps

In his keynote address to the Software Developers’ Conference, Karl Wiegers outlined his top 10 “software development traps”. When he asked his audience how many people had experienced them, a large proportion of the audience admitted to suffering at least four or five.

The top 10 traps, according to Wiegers, are:

  • The project’s vision and scope are never clearly defined
  • Customers are too busy to spend time working with developers on requirements
  • Customer surrogates (managers or marketing) claim to speak for the users, but they really don’t
  • Users claim all requirements are critical and do not prioritise them
  • Developers encounter ambiguities and missing information during coding, and they have to guess
  • Customers sign off on the requirements, then change them continuously
  • The scope incresases as requirements changes are accepted, but the schedule slips because more resources are not provided
  • Requested requirements changes get lost and the status of a change request is not known
  • Functionality is requested and built, but never used
  • The specification is satisfied, but the customer is not.

Join the newsletter!

Error: Please check your email address.

More about Software EducationSoftware Education Associates

Show Comments
[]