“What is the biggest challenge in projects?“
I asked that question during a coffee break at the 2022 MathWorks Automotive Conference in Stuttgart; I will share the answer I got in a minute.
But first, what do you think the biggest challenge in embedded software development projects is? Quite often, we think that the biggest challenge might be one of:
- A lack of time, because development cycles have been becoming shorter and shorter. And this definitely is a big challenge, but it can be effectively addressed by efficient workflow and automation processes.
- Money. Of course, you need to spend a lot of money in your projects, and you need to keep an eye on the available resources to stay within the defined budget, but this is still not the biggest issue.
- A shortage of skilled workers, which can lead to projects being delayed.
But none of them is the elephant in the room. The surprising answer I got at the conference was:
“missing requirements“
Missing requirements are the main reasons why projects fail and run out of budget and time. If what to develop is unclear, then too much additional effort is needed while the project is running to find that out and fix it.
But why does this happen?
I think the answer is quite simple here. We love to create instead of thinking about how to create!
And in the Embedded Software world, tools like Simulink and Stateflow make it easy to start creating without any documented requirements. We can immediately press the “Play” button to observe the behavior in a simulation, or even perform rapid prototyping with dedicated hardware tools like a dSPACE MicroAutoBox. This means that, when the time comes to think about requirements, oftentimes they’re viewed as just a documentation of what’s already been done, rather than as a guideline for what to do, before doing it; I’ve even seen projects where the submitted requirements document was just a PDF full of screenshots from Simulink!
And I know that mentality is tempting. Even for my little (electronic and 3D-printing) projects at home, I just start with a rough idea and then, without enough preparation, I
- gather the required components,
- solder the parts on a board,
- design enclosures with Fusion 360 or OnShape,
- print them on my 3D printer,
- write some code to tie everything together
I just want to turn my idea into a reality as soon as possible. But for larger and safety-critical projects, is it really a good idea to neglect or skip the requirements engineering phase?
What does research and science say about this phenomenon?
The short answer is that this problem has been well known for over 40 years. Back in the early 1980s, Barry W. Boehm researched why software development projects fail. This gave rise to the Constructive Cost Model (COCOMO). Then, in the early 2000s, the Constructive Systems Engineering Cost Model (COSYSMO) was developed from COCOMO by Ricardo Valerdi and Boehm at the University of Southern California Center for Software Engineering.
Long story short: The highest effort multiplier ratio (EMR) is allocated to requirements understanding and this has not changed until today. I even claim that due to today’s project conditions, such as shorter release cycles and a higher demand on cost efficiency, this factor is even higher. A wrong understanding of the requirements and the resulting additional efforts have a more serious impact on the success of the projects today than they did even in the past.
But why do we still have missing or low quality requirements when we know how detrimental this is?
I think the main reason is the action-over-planning bias. I can promote my project much better to management and customers if I can demonstrate something early on. Due to the already mentioned general conditions in the projects, the action-over-planning behavior is further privileged by management. It gives the impression that someone has recognized a problem and also has a solution ready. This is a dangerous pitfall in projects; there have already been several inglorious examples of this in the automotive industry.
How to address this biggest challenge in projects?
I think we can agree that we do not have a tool problem here. There are a lot of good requirements management tools on the market. As I pointed out before, the mindset in projects needs to be changed! We must overcome the “action-over-planning bias.”
Maybe managers should reward project leaders and members for focusing on good requirements and spending time on developing them. The consensus in the research on this topic and the experience of many projects proves that good and complete requirements are a necessary prerequisite for a successful project.
Maybe employees should show that the mistakes of past projects could have been avoided by better requirements management, and that the action-over-planning bias causes a lot of problems for the complex products we develop today.
Also have a look at the article Why and How to Improve Requirements, where Bernd Holzmüller (ITK Engineering) and I describe the origins of quality issues in requirements.
So far so good, but how is that supposed to work in agile projects?
Great!
One argument for why requirements are as they are today, is that we cannot provide detailed requirements in an agile project and that this would violate the Manifesto for Agile Software Development. Doesn’t it say “Working software over comprehensive documentation”?
Well, I think, we should clarify this argument. The requirements situation in many projects, especially on the unit but even on the component level, is often far from “comprehensive documentation”. 😉
I remember a project where the specification was a bound book that described all the requirements to the smallest detail. This is what is meant by comprehensive documentation, and it’s too suffocating to allow for effective development and testing. In contrast, though, it is also clear that it’s impossible to develop or test against requirements that are missing altogether.
And one more short note: Please, please do not mix up detailed design requirements with functional requirements. Of course, you can write a test case that implements the same algorithm that the model/code does as described in the detailed design. However, this test case just shows that the test tool calculates the same result as the model/code, and therefore is just a back-to-back test. However, it does not answer the question of whether the functional behavior has been fulfilled.
Agile software development is not about developing against moving targets- it is about talking and setting the requirements for a specific part of the software right before the development starts. The goal of the Sprint Planning is that each project participant is clear about what is to be developed in the next Sprint period, ambiguities are resolved, and there is a common understanding of what has been developed and tested at the end of the period.
Conclusion
Incomplete and missing requirements are part of today’s projects. We have also learned that this is the highest project risk and that this is a problem of business culture. Also, agile development does not solve this issue. We shouldn’t ignore this knowledge for another four decades, but instead should start implementing change today.
