Three common mistakes in requirements engineering

Whether in phase-gate or Agile development processes, shaping a great product necessitates dealing with requirements.

Once upon a time, in a phase-gate far, far away, product managers, project managers, and engineering managers were spending hours and hours on arguing about the requirements and specifications that should go into “contract documents”.

These documents were a verifiably big deal. They were often cobbled together by mixing knowledge, wishes, and plain fantasies. They were only “released” infrequently — after all, each release relied on way too much ado and scrutiny by team members and steering board members alike. And, what was in the documents was often used to hold everyone accountable to matters discussed to death between different business functions, and rarely with the customers and the suppliers.

Requirements work using this transactional, adversarial approach was arduous and painful. It was making bureaucrats happy, and customers rarely so. Not rarely, this approach turned into a source of blaming and frustration, especially when requirements changed predictably unpredictably during the project.

Not anymore

In more recent years, and with the rising complexity of product systems and supply chain footprints, companies have increasingly experimented with different ways of dealing with requirements, a.k.a., “Requirements Engineering and Management” (let’s call it “RE/RM”). RE/RM has come to be not simply a couple of stale deliverables in a process, but a workstream underlying any kind of development and launch endeavor.

Some companies have pursued better RE/RM by emphasizing the capture of requirements in the form of user stories, in the name of Agile. Others have introduced RE/RM in the form of processes and lingo, e.g., by copying the automotive industry. Yet others have shoehorned RE/RM into the organization by enforcing the use of software tools. Only the fewest have found a way to bridge the Agile and the traditional steering-focused worlds with an appropriate use of methods and tools.

Judging by the many such ways of putting RE/RM into practice, one would think that upgrading RE/RM capabilities is a piece of cake. However, this would be an illusion. Simply installing the latest and fanciest software suite doesn’t automatically change people’s minds on how to engineer and manage requirements collaboratively or to balance research/analysis, experience, and intuition. Creating new steering mechanisms to evaluate and release requirements written with much effort doesn’t automatically make decision-making on project progress more reliable. And, making work attributable to single persons and progress on requirements measurable doesn’t automatically improve team performance.

In theory, better RE/RM would help overcome such issues, even if, perhaps, not automatically. In practice, companies putting better RE/RM into practice are prone to making certain mistakes over and over again. Here are three common mistakes.

Mistake 1: RE/RM as a purely technical instrument

Following hot on the heels of “implementing” good ideas (such as Deft), one typical and very understandable mistake is to consider RE/RM as a purely technical instrument; a mere tool to be used on demand and without any further significance for the project beyond “doing RE/RM” to fulfill a deliverable and call it a day.

RE/RM is, for example, sometimes interpreted as if it were exclusively something for the project manager or the product manager, and only during the limited time span un which a specific role (usually, the product manager) finds time to work on requirements. What’s worse, some companies even create an entirely new functional silo: that of the “requirements engineer”.

Yet, this functional fixation would mean that other roles, (such as development and test engineers) are only responsible for the fulfillment of a contract. This, even though they aren’t external to the team and can therefore avoid incurring the costs of monitoring and enforcing a contract, something usually reserved for work with, e.g., suppliers. Vice versa, a single-function focus disconnects other, allegedly RE/RM-unrelated roles from the common goal of the project. It also takes away shared responsibility for the development and launch of a commercially successful product.

However, RE/RM is not simply a tool wielded by one or more specific roles within a team and whenever the clock strikes “requirements time”. RE/RM can serve as the backbone of a project.

Much has been written about Lean and “flow” in product development; the fewest would consider RE/RM to be an instrument to help achieve that Holy Grail state of work. Even so: RE/RM is better seen as a helpful way of establishing or implying a “takt time” of information exchange on requirements among all project team members. Agile methodologies already treat RE/RM as such: for example, in sprints. Similarly, it’s possible for a team running a bog-standard phase-gate without sprints to put RE/RM into practice as a takt-giver. For example, a team can make an informal review of the current state of requirements every two weeks, and a formal one every four weeks. Such recurring knowledge-sharing and debating events enable everyone involved to have the same shared understanding of progress and bottlenecks.

After all, the most common error of simplification is to think that only function X, e.g. Engineering, should apply and live RE/RM — perhaps as a means of holding a specific function accountable for delivering on, e.g., the target specifications. However, where would that leave other roles, such as the project manager, the product manager, the supply engineer, the quality manager? They would remain outside of the common understanding of requirements and their consequences on the project and the product — both during the development project and after product launch.

Or, the reverse: suppose that a product manager formulates his insights in the proper language, i.e., “shall”, “should”, “will” (or, for non-lawyers, “must-have”, “nice-to-have”, and “provisionally”). Suppose also that, e.g., the development engineers are not aligned on the understanding of:

how (and why) these requirements are prioritized,
how these requirements are interrelated, or
how they impact the technical feasibility and the value proposition of the product.

How could the extra effort by the product manager to put requirements in perfectly unambiguous language lead to better results than without RE/RM at all, when those who need to “play ball” are simply receivers of “product manager legalese” and executors of work packages?

As such, reaping RE/RM’s full benefits within a project team requires establishing RE/RM as the background “pulse” of projects felt by all team members across all functions and locations.

Mistake 2: RE/RM as an aid for front-loading decisions instead of knowledge

The second, far greater, epistemological error is simply a classic example of wishful thinking. Once requirements have been formulated and discussed following initial efforts to front-load knowledge, someone anxious (either in the project or in the steering team) simply says: “OK, let us now freeze the requirements”.

What’s worse: the typical linear phase-gate process, in fact, enforces this “freezing” nonsense by making gate releases contingent upon such a “freezing” of, e.g., the business case, then the requirements and concept, then the specifications, etc.

Regardless of how this “freezing” is supposed to work metaphysically, the world continues turning, regardless of whether we “freeze” or not. Competitors come in unexpected, markets’ macroeconomics shift, a technology isn’t as mature as we thought it was, a supplier can’t achieve the target quality, etc. Change is the only certainty.

Therefore, if we are going to be brutally honest: the act of releasing a requirements or specifications document at its core simply means that this document is increasingly becoming outdated. Doing so with much scrutiny and fanfare simply puts a patina of importance on a practice that is, at its core, not as beneficial as expected — especially if the focus on releasing requirements isn’t accompanied by the readiness to change them whenever deemed appropriate.

This is equally true when using “contract documents” (such as “Lastenheft” and “Pflichtenheft” in German-speaking engineering cultures, corresponding to MRD and PRD, respectively), as when using an RE/RM database.

I see this willingness and propensity to “freeze” as much as possible and as early as possible as a great hidden danger of RE/RM. It makes people think that the only thing missing after “freezing” is some project team members’ inability or unwillingness to just go ahead and “implement”. Or, that the only thing preventing a team to “freeze” is the fault of people engaged in upstream processes. For example, that people on the technical side of the endeavor just have to start turning the product manager’s pretend-perfect requirements into actual solution, so that the team can soon reach the goal quickly and be done with it. Or, that people in market research should deliver the customer insights and statistics that validate the product manager’s hopes, so that the team can go ahead and receive a “go” from the steering board.

Such linearity is quite unrealistic. In fact, for everyone experienced in development and willing to openly speak about it, this linearity is utterly naive. What’s more, it’s unconducive to experimentation, which seems to be key for innovation.

That’s why, within the larger scope of increasing optionality (and thus agility), teams that know better than to think wishfully switch to set-based instead of point-based approaches. In other words, they prefer parameter variations in sets of different solutions as active risk management and learning; not pursuing a single parameter set more closely until it either works or doesn’t, in a binary, high-risk, waterfall way.

My advice for any company putting RE/RM into practice, therefore, is: in trainings and project coaching constantly point out wake-up calls, such as:

RE/RM does not automatically lead to the right requirements simply because they are stored neatly in the database of a software tool.
RE/RM does not remove the need to work together in the team; if anything, it makes it even stronger.
RE/RM does not relieve the team from the responsibility of proper risk management, e.g. in the form of creating contingency plans in the form of multiple design variants.

Otherwise, biased hypotheses and blatantly unfounded assumptions could be legitimized as knowledge. Alternatively, under time pressure, not-quite-correct requirements could be assumed to be stable — even though they might be only outliers that someone assumed based on a predecessor or competing product, or elicited once upon a time (whether systematically or not), and which perhaps are no longer valid or even relevant for this product or market.

Mistake 3: RE/RM as a data management exercise

Finally, a mistake of a rather bureaucratic nature, and akin to a technology push: RE/RM is often disguised as an exercise in data management, as a structured way of filling in the blanks in databases. This means that RE/RM is sometimes introduced by enforcing the use of sophisticated, complicated and expensive software tools. Yet, these quite possibly satisfy their vendors more than they satisfy the company’s own business goals.

RE/RM supports project work by helping a team manage its knowledge of requirements — or lack thereof. It provides a basis for discussion and an internally-consistent store of knowledge. If, however, it is considered to simply be a data management exercise (even worse, when it is outsourced!), it only provides narrow, function-specific advantages; for example, it serves (or becomes abused) as a control instrument for quality targets, supply aspects, product cost or manufacturing specifications.

When the focus is placed on software tools rather than on the knowledge that the team could draw from the collaborative nature of RE/RM work, too little value is achieved compared to what would be possible with reasonable effort for RE/RM. In the worst case, bureaucratic use of RE/RM causes a worse result than a classical “contractual documents” approach. After all, it diverts attention away from what really matters in a systematic manner that, e.g., enables perfectionists to feign attention to detail, at the cost of the entire project.

What to do instead

RE/RM, when put into practice appropriately, is a straightforward way to “agilize” even the most legacy of product development of approaches, by providing a “takt time” for a project team, even without incurring the methodological cost of, e.g., Scrum.

There are many advantages to appropriate RE/RM. It helps project team members (and even suppliers) to “stay on the ball” regarding ongoing work on requirements, specifications, and tests. It helps the technical and marketing side to identify important trade-offs and work around them. It helps the product manager to map the current state of knowledge regarding customers, as well as the probability of customers’ needs to become fulfilled by the project team’s efforts. It also helps the engineers to map the current state of progress in achieving target specifications by successfully completing tests.

RE/RM can help a project team to delight customers reliably and efficiently. But only if the team doesn’t treat RE/RM as a single-function technical instrument, as an enabler of wishful thinking, or as an excuse for buying the latest and greatest fancy software tools.

Pretty commonsensical for business-minded people, wouldn’t you agree?