Regardless of your company’s industry, customized software is crucial to digital transformation. However, developing non-trivial software, whether by an internal team or external service providers, carries significant financial risks. The Standish Group’s CHAOS Report has examined thousands of software projects over many years and found that only around 31% of these projects were successful. Of these, only half delivered high-added value for users.

This comprehensive study identified unclear requirements, frequent requirement changes, and a lack of collaboration with users as the main reasons for unexpectedly high costs. When the budget is exhausted, this often leads to the project abandon the project. The result: the project fails, and much money is irretrievably lost.

Investing in good requirements pays off

Although the importance of good requirements is well known, requirements management is often neglected. But why? Good requirements come with a cost. Conducting several-day workshops with internal and external experts for the initial requirements analysis is just the beginning. In agile projects, the teams refine and add to the requirements daily during the project.

Not having professional requirements management saves money in the short term, but this means accepting a high risk of failure in the long run.

Planning before implementation

Before software product development begins, it is easy to adapt requirements. The requirements analysis makes it possible to have concrete discussions with other project participants and to learn from each other. Participants discover ideas to document and test, thus creating a concrete plan. During the project, the plan is the basis for changes. Of course, no plan has survived its first contact with reality, but careful planning is still essential.

The later in the the project, the more expensive the changes

The requirements analysis at the start of the project sets the course for success or failure. Neglecting can result in high costs later in the project because requirements change drastically or many new requirements emerge. Developers have to rewrite existing code, and the client pays twice.

A model provides concrete figures

A simple model can quantify the concrete effects of poor requirements.

The Sprint Calculator from wobe-systems GmbH calculates the costs for software projects based on nine input values. By experimenting with the input values, you can get a feel for the effects of poor requirements, for example. The model has often proved worthwhile because it directs the discussion from opinions to concrete figures.

Input variables at a glance

The model describes the project with only nine input variables:

Backlog SP: The number of story points (SP) in the backlog measures the project’s scope. If this value is too abstract, the estimated person-days (PD) can also be used here.

Velocity SP/D/D: This value determines how many Story Points a developer processes daily. If PDs are used instead of Story Points, the value here is 1.

Developers: This value indicates the team size of people directly contributing to the processing of SPs.

Dept to Halt: The technical debt (Dept) concept is introduced here. Technical debt is a defect in the inner quality of a technical product. During implementation, technical debt arises for a variety of reasons.

To eliminate technical debt is essential because it directly impacts the speed of implementation and changes. Story Points quantify the amount of work required for this. Ignoring technical debt leads to the accumulation of more technical debt, which slows the project’s progress progresses. It can even come to a complete standstill (halt) in extreme cases. The value indicates the technical debt in SPs, bringing the project to a halt.

Debt Reduction Rate %: The value indicates the percentage of time developers spend on reducing technical debt.

White Noise %: Developer disruptions and distractions not part of the project work can be called white noise. The value indicates the percentage of time spent on non-project tasks.

Quality Level %: Humans could be better, and especially in software development, no one delivers 100% perfect code from the start. The more complex a task is, the more frequently the code is revised. The value indicates the percentage of the SPs processed that cause renewed effort as technical debt.

Requirement Quality %: The quality of the requirements as a percentage determines how many SPs end up back in the backlog as new requirements or as change requests about the processed tasks. With a requirement quality of 70%, 30% of the processed SPs end up back in the backlog.

Costs (€): The value indicates the costs for person days (PT). It is required to determine the total costs of the project.

A simplification of reality

“All models are wrong, but some are useful.”
George Box, British statistician and author of the book “Empirical Model-Building and Response Surfaces” (1987)

Of course, reality is much more complex than the model. For example, the model ignores delays caused by personnel changes in the team. However, the simplification makes the model easy to understand, which is helpful when discussing the results.

As a result, the model provides the personnel costs for developers and the project duration in weeks. To calculate the project’s duration, person-days are divided by the number of developers and five working days.

Effects on requirements

An example project is estimated to have 400 story points to be implemented. The developers deliver 90% quality and spend 15% of their time reducing technical debt. The value of “Dept to Halt” is estimated at 100 PT, and one person per day costs 900 €. We work with a team of 4 people.

The figure shows how the project’s cost changes depending on the quality of the requirements.

The sprint calculator model shows a potential saving of € 72,000.00 if the quality of the requirements increases by just 10% from 70% to 80%. The model also shows an exponential cost rise if the requirements are worse.

These figures make it easier to decide in favor of professional requirements management. However, anyone who decides against it is betting on an unknown quantity about the quality of requirements, which can seriously impact a project.

Conclusion

Requirements are the key to project success. A simple model illustrates that even a slight improvement in the requirements for a project worth half a million euros can mean considerable savings in the upper five-digit range. The time to market launch is also shortened, and profitable use of the software by the customer is possible earlier.

A significant improvement of the requirements in the project is possible at a fraction of the cost of poor requirements. There is, therefore, no rational reason not to take this care. Requirements management at the beginning of a project lays the foundation for a good solution architecture. The initial requirements documentation provides the context for refinements and improvements during the project. This context reduces misunderstandings that lead to ever-changing requirements. In the best-case scenario, a software project is successful and needs adaptation to new circumstances. An already functioning requirements management system can then be continued. This approach saves time and money in all project phases. Of course, the quality of the product also benefits from good requirements management.

The costs of bad requirements in software projects