When considering an optical system development process, it’s imperative to grasp the importance of the System Engineering backbone that follows this process and leads it through the different stages.
One of the System Engineering tools that serves this purpose is the Spec (Specification Document).
In our experience, optical systems development, begins with the system engineering task of creating a System Spec. This effort might be overlooked, and many start-ups try to cut this short and often find themselves in a dead valley. This step is a must if you indeed want to create a systematic process leading to a successful product.
In this post we unfold this process and take you through it considering the following points:
Optical Spec formation starting point
What development question this process covers
The output of the Spec formation process
Detailed step-by-step explanation of the process
Risk management: what may happen if you miss a step
Applicable Tips: what can help you with Spec formation
Optical Spec formation starting point
The common approach of entrepreneurs is to start with a user need, a problem, a use-case, something that is user centric. We believe that this approach is the right start that can get you to a successful product. Entrepreneurs also quite intuitively understand that the base of a start-up is to have an innovative idea or a concept of how to approach or solve this problem. The difficulty starts when they need to produce the solution or develop the product systematically.
They understand they need a Spec and don’t know how to create it.
We find ourselves filling this gap for many of our customers, and we step in and bring our engineering experience with us. We start with the fundamental effort to understand and learn the problem. We covered the “problem space” in our article that gives overview of the entire Development Process.
Here are just a few points that open the door to the Spec formation:
The Spec basis is a user story or a problem
The idea for the solution or concept may be created before the Spec formation, but it really doesn’t need to be ready or finalized. The Spec will help to create the solution
Experienced system engineers can lead this process with confidence, bringing the tools with them. Building your tools as you go will always take more time
Your bottleneck is always time, investing in the planning and Spec formation actually saves time in development stages
Keep in mind, that often your deliverables serve as support to get more funds to the next stage
What development question this process covers
Why do we need this process? A process is always a tool that’s based on past experience and lessons learned, that helps to work faster, more efficiently and with less errors and gaps that will “catch us later”.
So, the question this process aims to answer is:
What’s the optimal spec?
In other words, what’s the optimal working point where the desired functions are covered but without too much margin, without over-complex design, without paying more than we have to.
The output of the process
The Spec Formation process goal is to formulate a Spec and optimize the key design requirements. So, the deliverables of this process:
The Engineering Spec Document, which is an important asset
The Engineering Spec Requirements will guide the design and focus the engineering effort
We see the Spec as a design tool, that lives together with the design and is updated, changed, and finalized along with the design maturity. There are many design decisions in the process, trade-offs between different parameters, some constraints come in, some compromises are made, cutting functionalities to meet deadlines and milestones... The development process is a living organism and so is the Spec.
Optical Spec Formation Process: step-by-step
The Spec Formation Process Flowchart that we created over time and experience is shown below.
Each block covers a step or a task. The blocks are connected in a logical flow and in order to get to the end, sometimes several iterations are required.
Let’s now take a closer look and follow the flow step-by-step:
Step1 - Input: Define use case
The use case must be very clear and detailed in order to focus the development effort.
Step2: Translate use case functions to engineering parameters
In this step we list all the parameters that need to be in the Spec, so that all the use case functions are covered. This stage requires a deep engineering understanding in the field and a lot of experience.
Step3: Create preliminary Spec with list of all parameters
In this step we try to put quantitative requirements for all the parameters based on past knowledge and best understanding of the use case. In places where there is an uncertainty regarding the actual requirement – we leave TBR (To-Be-Reviewed), so we can come to this parameter later. In case we don’t have a quantitative reference at all - we leave a TBD (To-Be-Defined), to highlight greater knowledge gap to be closed later on.
Step4: Identify Key parameters that drive the design
Not all the parameters are equally important in the early design stage. We must narrow the list to a limited number of key parameters that have the greatest impact and drive the design. Each case will produce a different list of key parameters even for the same type of system. Some key parameters are connected to constraints and will impact the system architecture, technology used, and, of course, the design itself.
Step5: Validate the requirements for key parameters
Since the key parameters drive the design, their requirements need to go through a validation process, where we get evidence, a use-case driven evaluation of the requirement, not just shooting a requirement from the top of our heads. This process ensures that system design will optimally cover the requirements without over-complexity. The validation can be done using different tools, some alternatives are detailed in Steps 6-8.
Step6: Theoretical calculations
Theoretical calculations can be used to validate the key parameters requirements. In some cases, this could be enough, and no additional effort is needed.
Step7: Benchmark products testing
Sometimes using benchmark product for the specific use case in hand and then measuring the key parameter can be used as a more practical and useful validation process.
Step8: Building Validation test setup
The highest complexity and effort example of key parameter validation is actually building a validation test setup. We use off-the-shelf elements, evaluation samples from technologies companies we work with, optical and mechanical parts that we have in our lab, 3D printed parts, holders and more in order to build a working validation setup in extra short time frame.
This task utilized our vast experience, connections with technologies companies and eco-system that we built over the years.
Step9: Use case function testing
After using the validation tools in Steps6-8 we close the loop by actual use case function evaluation. Sometime this process requires several iterations to optimize the numerical requirement. Only by closing this loop we can be confident that the requirement is validated and optimized.
Step10: Evaluate impact on other Spec parameters
It’s important to remember that many parameters have mutual correlation and dependency and changing one could also impact another. So, when updating a key parameter requirement another review and update of the Spec is needed to cover the trade-offs and evaluate constraints.
Step11 - Output: Spec Optimized
The output of this process is a more optimized Spec with respect to the specific use case and functions. The key parameters requirements are validated based on actual testing and measurements, and the risk of design over-complexity is minimized.
Risk Management Tool
We can also view the Spec Formation process as a risk mitigation tool.
Each process step aims to close a risk along the process. So, we want to highlight what can happen when we skip this step or when this risk is realized.
Step1 - Input: Define use case
Without a clear use case definition, this entire process may be too generic, and the end result will be generic, thus not optimized.
Step2: Translate use case functions to engineering parameters
Not all the functions are covered by design. If we skip a function – there is a big chance that it won’t be covered by the design,
Step3: Create preliminary spec with list of all parameters and requirements
The Spec doesn’t cover all design parameters, or if we don’t create requirements guidelines for parameters from past knowledge, then more effort will be needed in requirements validation. The fewer gaps that we have in Spec, the more effective the effort is.
Step4: Identify Key parameters that drive the design
Focusing on key design parameters minimized the validation effort. If we don’t work on a focused short key parameters list – more resources will be invested in this step, and the gain will not be worth the investment, as most chances that many parameters will be changed along the way.
Step5: Validate the requirements for key parameters
The key design parameters requirements are not validated. This means that the requirements are not optimal: they either fall short of covering the functions required or leave too much margin, leading to over-complexity in the design.
Step6: Theoretical calculations
Step7: Benchmark products testing
Step8: Building Validation test setup
Use the easiest / fastest option to validate the requirement. Steps 6-7-8 are all different options of requirement validation processes. Each parameter should be validated in the most cost-efficient and time-efficient way.
Step9: Use case function testing
Key requirement conformance to the use case functionality is not assured. This means the loop is not closed and the intended functionality is not used to drive the design efforts.
Step10: Evaluate impact on other Spec parameters
Impact on other spec parameters is not considered. We may miss the parameters’ mutual correlation and dependency; this creates risks in the subsequent design stages.
Step11 - Output: Spec Optimized
Spec is not optimized. This means that the design will not fit optimally the use case functions. This can cause design iterations and re-design from scratch in the worst case. In the end many start-ups close exactly for this reason – wasted efforts, resources, time, money.
Applicable Tips: What can help with Spec formation
Are you currently facing the challenge of spec formation in your project?
Don’t want to waste precious resources to learn from your mistakes?
Here is an opportunity for us to step in, learn your status and highlight exactly where you are. We can guide you through the Spec Formation Process, we’ve done this for many customers and each time we learn how to do this more effectively and stay focused.
We can help you to get on track and regain full control over your project schedule and resource management.
Contact us to schedule a meeting to learn more…
Comments