The Impact of Poor Requirements in Software Development

Good requirements are the foundation of software development projects. It is more important to “do the right thing” than to “do things right”. The book “So You Want To Be A Scrum Master?” discusses the impact of poor requirements in software development and why people are the main issue.

Poor requirements are often blamed for poor work.

Poor requirements are often blamed for late work.

Poor requirements are often blamed for people building the wrong thing.

However, the requirement didn’t wake up one day and decide to ruin your sprint or project. At no point during any failed process is the requirement at fault. It’s inanimate. It doesn’t exist. It’s just a model. It’s got no feelings.

We’ve worked hard to make sure that shady requirements are less of a problem. How? By making people aware that the requirements are not the problem – people are.

People write requirements. Software exists to solve problems or enhance abilities. The solutions to the problems (etc.) are usually defined as requirements. These requirements then flow through your business and the final product emerges.

At no point during this life-cycle is the problem anything to do with the requirement. It’s all to do with the people. You. The team. Everyone involved.

Why?

• People define the requirements
• People review the requirements
• People agree the requirements
• Some people don’t question the requirements
• People build the requirements, test them and ship them
• People accept the requirements
• People build their companies and departments around the flow of requirements – sometimes incorrectly. This re-enforces the potential dysfunction and pushes bad work further through the system.
• Some people ignore the requirements
• Some managers don’t empower their team to challenge requirements
• Some people put hitting a deadline above getting the software right

It’s the people (and the system they work in) that causes the effects.

The people are part of the problem. But that’s good news. Because once you know that people are part of the problem, then these same people are also part of the solution.

Source: So You Want To Be A Scrum Master?, Helen Lisowski, Rob Lambert, Martyn Frank, Raji Bhamidipati, Steven Mackenzie, and Keith OSullivan, https://leanpub.com/beascrummaster