On Requirements

The idea is often along the lines of “the problem is this” and “we will solve it like this” – Marketing 101. When the customer does not have an engineering background, this may be all there is to proceed. There is however a gap between the customer’s idea (the dream) and what is achievable within budget and to a deadline (the product). This unspoken tension usually comes out when something unexpected happens, on either side. Both sides enter in good faith, often with an implicit understanding of what they expect to get out of the project. There is an implicit expectation that this is what happens:

It’s not unrealistic. We have an idea, we hand it off to the experts, we get a product back. Easy! From the engineering perspective, all avenues are open, all options are possible, and everything is on the table.

The reality is more like this:

The crucial step in the centre, generating the engineering requirement, is not carried out, or is implicit. The engineering requirement is crucial because it scopes the work and establishes boundaries. There is inevitably trade off in this process and nobody wants to see their idea compromised just to get a product out the door – after all, it’s a dream.

Regardless of whether or not the engineering requirement is explicit, the engineering process resembles this flow:

The problem with skipping the engineering requirement is it removes constraints on the expert work phase, the verification phase, and the validation phase. We don’t know how to describe the finished product so we don’t know that the work is complete. Without a clear picture of the end goal, the work can continue indefinitely. Eventually somebody loses patience, and the project collapses. Nobody chooses this to happen, but it’s a risk when the engineering requirements are minimised.

When engineering requirements have been skimped, there is typically little documentation on how the design works, or how it is supposed to work. This makes it difficult to rescue the project, because some time is spent crawling back inside the mind of the developer, who may not be available. In turn this may result in new understanding of how the product does not work, which in turn causes some expert work to be repeated or corrected.

Key to solving this conundrum is clearly defining expectations on both sides. Both sides must understand there will be trade-offs. Engineering may have to work with established technology, rather than something new, exciting, and untested. The product owner may have to compromise on features to meet a budget or deadline. After all, yes we can do anything, but time and budget are key factors in the business plan. By not spending time setting expectations ahead of project start, the risk is run that the project becomes increasingly uncontrolled.

Particularly in embedded software development, the technical implementation is often carried out by specialist developers who do not have full sight of the product. To get the best outcome from the specialist team, it is necessary to communicate as much of the product as possible to them. Reworking firmware, particularly late in the cycle, carries additional costs. When delivering the embedded engineering service, we want to deliver as efficiently as possible. Extra communication at early stages helps to head off larger costs later, when the engineering requirement has already been created.

IOT development can be particularly fraught, when multiple teams need to work together to deliver the product. Lightweight requirements can lead to multiple sets of assumptions. In the event those need to be reworked, time and costs can be severely impacted.