Impact of Bad Requirements in Software Development Projects

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

How to Detect Bad Requirements

Detecting bad software requirements can save a lot of time and headaches later in a software development project. Here are some key red flags to look out for in your requirements:

• Ambiguity: If the requirement is vague or open to multiple interpretations, it’s likely to cause confusion. Requirements should be clear and precise enough to create test cases.
• Incomplete Requirements: Missing details or parts of the requirement can lead to misunderstandings. Ensure every requirement is fully documented, including test cases.
• Inconsistencies: Conflicting requirements that contradict each other will inevitably cause problems. Consistency across all requirements is essential.
• Unrealistic Expectations: The requirements that are technically infeasible, overly complex, or unrealistic in terms of budget, time, or resources are problematic. During requirements elicitation, the needs should be checked by a technically capable person.
• Requirements Without Stakeholder Input: Requirements developed without consulting stakeholders often miss important aspects. Stakeholder involvement ensures that requirements align with their needs and expectations. As much as possible, the software development team should not make suppositions about the needs of the users.
• Overly Detailed Requirements: While details are important, overly detailed requirements can be restrictive and reduce flexibility. Aim for balance.
• No Clear Business Value: Every requirement should contribute to the overall business goals. If a requirement doesn’t add value, directly or indirectly, it should be reconsidered.
• Frequent Changes: Constantly changing requirements can indicate a lack of understanding or agreement on what is needed. Stable requirements are crucial for a successful project.

Additional resources on bad requirements

Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to Help Solve Them

Your bad requirements are costing you money

I still don’t have time to manage requirements: My project is later than ever