Recently, my wife and I watched the multi-part television series on Albert Einstein, developed for the National Geographic Channel and directed by Ron Howard. Despite some of the criticism leveled at the effort, like compressing portions of the timeline and the screenplay’s inclusion of his first wife’s contribution to his work (which has never been proved), we were enthralled. Not only were we taken with the characters themselves, but also with the way the story line presented the ideas as his mind created them, via computer-generated moments which slowed down time and used atoms, planets, and even a speeding streetcar to demonstrate his theories. More than once, Einstein talked about how his theories might be validated and would have to be disproved, rather than proved. I thought to myself, “He’s talking about OQE—Objective Quality Evidence.”
The term Objective Quality Evidence is a term regularly used in the world of the Department of Defense, primarily in safety. Fifteen or so years ago, I prepared a briefing that discussed Objective Quality Evidence for a group whose project focused on shipboard weapons safety. You can bet I had a pile of spreadsheets in my arms! Objective Quality Evidence in those days required an army of people and a floor-to-ceiling stack of paper to create and construct.
Proving OQE today has greatly changed, but before I show you how to lose the paperwork, let’s look at what Objective Quality Evidence actually means.
The following three bullets present the dictionary definition of each of the OQE principles:
• Objective – not influenced by personal feelings or opinions in considering and representing facts
• Quality – the standard of something as measured against other things of a similar kind
• Evidence – the available body of facts or information indicating whether a belief or proposition is true or valid
According to PM Essentials—an online guide for project management professionals—Objective Quality Evidence is defined as:
Any statement of fact, either quantitative or qualitative, pertaining to the quality of a product or service based on observations, measurements, or tests which can be verified. (Evidence will be expressed in terms of specific quality requirements or characteristics. These characteristics are identified in drawings, specifications, and other documents which describe the item, process, or procedure.)
Looking back to that long-ago DOD briefing and other similar ones, I reflected that I was always asked, “Where did this set of requirements come from?” and “Did this new design include all the current functionality as well?”
For OQE review meetings, our team reviewed a library’s worth of documents developed during the design. As more questions were asked by members of the group receiving the briefing, a team member would reference a chapter and verse from a design artifact, or present the information on an overhead projector. Inevitably, a reference was missing from the group of documents. Toward the end would come a familiar closing question: “Can you show the traceability from the requirements through implementation in the design?”
That question cued my mind to follow model-based systems engineering (MBSE), showing the relationships among the data constructs used to implement the design. The standard answer was, “I’ll get back to you.”
Of course, I did respond to the question, and we did successfully complete the project. All of the data elements did exist, some in spreadsheets and some as text, each requiring manual research performed by a person fully versed and knowledgeable about the documents where the information resided. It wasn’t the most efficient method to provide the OQE! Today, we can perform that same task significantly more efficiently by applying methodology and technology.
My answer to the “missing reference” challenge? I implemented my design using a model-based system engineering tool.
Why? It gave me the ability to capture and organize all the data and allowed me to directly associate (link) design elements with the documents. The MBSE tool provided a schema (methodology) to link the data, and then provided diagrams and documentation derived from a single source repository.
So let’s look at Objective Quality Evidence again, this time using such a tool—CORE or GENESYS.
Looking at the diagram below, the requirements are augmented by an external Requirements Document, and supported by a source specification which establishes the basis for the performance, design, development, and test requirements. They are refined by decomposed requirements. The decomposed requirements specify a function and are the basis of a verification requirement. This enables a method which carefully gathers and facilitates the examining of the evidence, and provides all the available information to be combined into a logical answer, allowing me to respond to any questions about Objective Quality Evidence.
The use of CORE or GENESYS enables an explicit system specification grounded in the use of the System Definition Language (SDL), which is the foundation of the tool. The SDL is a formal, structured language which avoids the ambiguity inherent in using common English to define or specify a system. The precise meaning of each language concept is already fixed and documented. That enhances team communication and assures an unambiguous interpretation of specifications using this language. The data model repository is structured by the SDL which can be extended by the user, if needed. The SDL is an Element-Relationship-Attribute (ERA) language expressed in graphical structures with semantic meaning. The SDL is based on the following fundamental language concepts:
Elements (i.e., entities) correspond to nouns in English. Elements define objects and serve as the basic units in the system repository. The tools (CORE and GENESYS) group these elements into one of several classes (e.g., Requirement, Function, etc.) in the system repository. As an example, requirements may be sub-classified as either an originating requirement extracted from source documentation for a system, a refinement of a higher-level requirement, a derived characteristic of the system, one of its sub-components, or a design decision.
Relationships are similar to verbs. To be precise, a relation that defines a link between two entities corresponds to the mathematical definition of a binary relation. Relations are not commutative, each relationship having a definite subject and object. However, for each relationship, there is a complementary relationship that defines the link from the object to the subject. For example, when you allocate a Function entity to a Component entity (using the allocated to relation), GENESYS automatically creates the “performs” relation linking the entities in the reverse direction.
A few of the Relationships are:
• Augmented by – identifies text or external files that expand on the description of the element
• Basis of – identifies the elements needed to fulfill one or more originating requirements
• Documented by – identifies the source document which specifies and/or enhances the definition of this element.
• Refined by – identifies the children of this element
• Specifies – identifies those elements whose performance or whose characteristics are bounded by the requirement
Attributed Relationships (i.e., attributes on relationships) correspond to adverbs in English. The attributes of a relationship serve to define critical properties of the relationship. For instance, attributes of a “consumes” relationship would include the quantity being consumed.
So to reiterate, this tool supplies an engineer with all he or she needs to see and present the evidence succinctly and in one place, real-time. It eliminates the “I’ll get back to you” scenario on Objective Quality Evidence. As shown above, for each relationship, there is a complementary relationship that defines the link from the object to the subject. For example, when you allocate a Function entity to a Component entity (using the allocated to relation), GENESYS and CORE automatically create the “performs” relation linking the entities in the reverse direction.
Every engineering group has a slightly different approach, but they all appreciate an ordered, complete and clean presentation. CORE and GENESYS provide exactly that through their ERA-based structure. This model-based systems engineering program provides a clear view of how your company can first establish and then review Objective Quality Evidence while ensuring that the data produced is preserved.
Now that’s something even Einstein would approve of.
