During product development, engineers are called on to provide a design solution to a particular problem. We are also asked to document the journey along the way for the purpose of being able to retrace our steps when issues arise. I once had an engineer tell me that it was not possible to document the knowledge in his head. While I agree that we may never be able to recreate the talent and intellect that created the solution, I believe that we can capture the design journey if we are willing to take the time.
In my experience, we have typically tried to capture the design journey through a disconnected set of documents which we try to finalize for a given design. While with good effort and meticulous attention to detail we may have gotten it documented, often times we struggle to put it to use. Retracing those steps is not easily achieved.
Today it has become easier to capture that journey through the use of digital engineering (DE) tools. The capabilities have evolved from a disconnected final set of documents to a database of interconnected information that can dynamically display information in different ways for different audiences, enabling a more practical way of utilizing the information to retrace the journey.
I wish to share the evolution of the design journey through an example as applied to requirements, as well as the management of action items/concerns. I will use a remote-controlled video drone as the system of interest for the example.
A Perfect Requirement?
A development project commonly starts with requirements. As we have all probably experienced, requirements are not always well written. The process of getting to a good requirement may be through a set of reviews where the requirement is continually rewritten until it is well-formed. While this achieves the goal of getting a well-written requirement, the journey to get to the final requirement is often lost.
Take for example, a case where marketing has delivered a requirement for the video drone system that says, “Needs to fold up into a travel bag.” While it indicates that the drone needs to fold, the specifics around the real needs are missing. This leads to a review comment or action item to work with marketing to establish a better understanding. The requirement at this point exists in one document and the review comment or action item may or may not exist in another document, depending on your process.
After conferring with marketing, the first version of the requirement might be rewritten into something like, “The video drone system shall be compact enough that the user can transport and use the system without limiting their ability to perform typical outdoor activities.” The previous requirement may be retained indirectly through version control or may not be retained at all.
It is likely that this requirement revision will be questioned again because “compact enough” and “typical activity” are not defined sufficiently. How do I know what the size should be? This concern or action item may be documented again in review comments or an action items list. Additional work would need to be done to further define this requirement. Marketing may have done a market analysis to determine the appropriate size.
The requirement would get refined again to take on a more technical specification like, “The video drone system shall have dimensions of less than 8.5 inches in length x 3.6 inches in width and 5.3 inches in height when stored for transport.” I would never call a requirement perfect, but this statement may be sufficient for describing the need and, therefore, be the end for this requirement’s journey. In that case, it is finally documented this way in the requirements specification.
The Problem Arises
Now consider a scenario where we are 18 months down the road, and six months of that has been in the production phase. The design team has moved on to the next project and is deep into that development. The organization comes back and says the chief complaint from the customer is that, “The system is too bulky to take with me.” This would lead to an investigation as to how we got this wrong. The purpose of the investigation is not to lay blame, but to ensure that we do not repeat the mistake and deliver an underperforming product again.
Without good traceability and document retention policies that cover not only requirements but also action item lists, review notes, and other related documents, finding the reasoning for this miss might be difficult. The team may be relying on information that was not captured in the documentation system or retained as part of the development documentation. It might not even have been captured except through e-mails and conversations. Recovery of the process is highly dependent on the organization’s management of the information.
The Evolution
While some organizations may be very good at information/knowledge management and traceability, not all organizations are, and in some cases the overhead associated with this task may be burdensome. I offer a different way of managing that information using the power of DE. I present the solution in the diagrams below.
Figure 1
Using the DE approach, you would retain the history of the requirement journey. In that approach, you would not rewrite your requirements. Rather, you would refine them with additional, derived requirements. Connection through derivation helps to maintain the history and evolution.
Within our DE model-based systems engineering tool GENESYS, the requirements are maintained through establishing the “refines/refined by” relationship. These relationships enable the creation of the diagram above that is descriptive of the evolution of the requirement.
Figure 2
Second, you would document the journey in a connected way. Within GENESYS, we can establish relationships of “generated by” and “results in” to establish a traceability to the source of a concern (orange block) or risk (red block) and the resulting change that occurred due to the concern or risk. This establishes the connectivity to tie in the rationale and reasoning for making changes.
Third, you would back up the decisions made relative to the concerns and the risk by establishing relationships of “documented by” to enable traceability to the work that helped make the decision. This may be documented either directly in GENESYS or through referenced hyperlinks to the actual source documents. Either way, you have a digitally connected traceability of the information.
Digitally Connected Traceability
The three steps that I have written about are all enabled by the concept of digitally connected traceability. The evolution represented here is the movement from non-digitally connected information to digitally connected information. While there are many ways to establish that connectivity, we should be looking for solutions that help us to evolve our capabilities and satisfy our needs. How do you want to evolve?
To learn more about optimally managing requirements, see Requirements Management and Traceability.
