The Tower of Babel, Esperanto, and Creating a Common Second Language
Product complexity is defined in many ways. You may be familiar with the story of the Tower of Babel. Although the biblical meaning of it has to do with human arrogance, I will use it here in a slightly different context – mainly how the consequences of lacking a common second language are enormous when managing complexity.
Then came the late nineteenth-century movement toward creating a universal language known as Esperanto. Knowing what we know today perhaps L. L. Zamenhof should have focused on English instead but the context remains the same – that the benefits of having a common second language are huge when managing complex situations and processes.
What does this have to do with intelligent requirements? Well, the complexity of today’s smart and interconnected products can no longer be managed with simple text-based requirements. It must be managed with intelligent requirements able to reflect various authoring methodologies, content complexities, and design states. A complex requirement without intelligence may lead to misinterpretation given the multiplicity of audiences: stakeholder needs, business goals, regulatory compliance, technology options, interaction with the surrounding systems, design exploration choices, domain-specific implementations, testing, system integration verification, manufacturing, and others. And each of these audiences has a “language” of their own, often referred to as a requirement type, where each type requires a different methodology for capturing content, metadata, and traceability. This is a “Tower of Babel situation” (multiplicity of types) which at the same time must allow the enterprise and its suppliers to interpret the meaning of these requirements in the same exact way – by using a common language. Therefore, requirements must be intelligent as opposed to complex – as defined below.
That is a real challenge for today’s requirements management tools which are mostly stand-alone and based on simple text definitions. That was perfectly sufficient for simpler designs, but when faced with the challenge of today’s product complexities these tools struggle without the ability to:
- Seamlessly integrate multiple requirements methodologies
- Allow for the definition of custom requirement types
- Automatically enforce conformance to a requirement type
- Coexist and connect with other requirement authoring tools
- Enable collaborative authoring and revision of complex requirement sets
- Automatically maintain traceability throughout product design, manufacturing, deployment, and maintenance product lifecycle
There is another way in which product complexity complicates the management of requirements. It’s the increasing reliance on Model-based Systems Engineering (MBSE) and on simulation. This is extremely important because these technologies simultaneously define (optimization and flow-down) and consume (test and verification) requirements at every stage of the design lifecycle. On one hand, system models must reflect stakeholder needs, and on the other hand they must guide the other engineering domains with requirements that flow-down from the model. Similarly, simulation is first used to derive basic requirements during design exploration and is subsequently used to make sure that detailed designs meet those requirements. And to do that efficiently across all requirement types and engineering domains the requirements management environment must be able to satisfy all the needs listed above.
And what about an automatic enforcement of an intelligent requirement type (see bullets 1-3 above)? Let’s look at a sample requirement definition workflow that accomplishes that:
Now, let’s consider how semantics managed as part of the above flow plays a critical role in ensuring the correct interpretation of intelligent requirement types. Types that are like the Tower of Babel languages! When all is done the semantics of the content elements are retained as part of an intelligent requirement allowing the information to be algorithmically interpreted. That algorithm may be part of a beforementioned simulation process specifying inputs during design space exploration or during a virtual design test. This also allows the system to algorithmically present the information through separation of the content from the presentation if needed. The process eliminates misunderstandings between teams and removes ambiguity between human and machine interpretation because it results in a common second language - an Esperanto if you will.
As an additional key benefit, an intelligent requirement allows its content elements to be traceable via the digital thread. Here is an example of a graphical presentation of an intelligent requirement; it’s connected to a related simulation process, and the underlying details of a design (see last bullet above):
In summary, an “intelligent requirement” does not imply some sort of artificial intelligence is embedded in a requirement. It means that a requirement contains much more than simple text, allowing it to be intelligently and uniformly interpreted by people and processes based on type, metadata, content structure with elements, and relationships. It also means that authoring tool guides the user to consistently define these details per requirement type.
If you agree that intelligent requirements are the right approach to the challenges of today’s requirements management I encourage you to find out more about the Aras low-code platform and its Requirements Engineering application because it was architected to handle just that. This may help you better understand how this advanced technology can benefit your organization, and how to influence your company’s thinking regarding digital thread and the pervasive traceability of intelligent requirements across an entire product lifecycle.
On a personal note, I can truly relate to the value and imperfections of a common second language and the resulting misunderstandings. When I came to the US from Poland as a teenager, I remember mixing words between languages like saying “glass” instead of “ice” in high school chemistry to the great amusement of my classmates. Thank you, mom, for insisting I study French instead of English at a young age! My English language skills have hopefully improved over the years but even today I often see my grandkids (and my colleagues at work) roll their eyes as I occasionally come up with a particularly innovative albeit unorthodox fusion of languages whenever a specific English word escapes me. Oh well, deal with it using intelligent requirements I say!
Interested in learning more about the benefits of using intelligent requirements? Check out our latest eBook, "Requirements Engineering: Defining Problems-Enabling Solutions."
