The starting point of a system design is always challenging. Whenever we start thinking of a system design we, as technical leads or system engineers, tend to dive straight into the solution. This is our passion, our comfort zone, that’s what we’re here for so to speak. However, there is a crucial stage that precedes the system design and that is forming the system requirements, or in simpler words, understanding what the system must do and translate it to technical terms and into technical requirements – understanding what the Minimal Viable Product (MVP) is but in technical terms of course. The first piece of the puzzle.
Now, a number of you may ask “What is he talking about? We always start the process of system requirements with a well phrased MVP and a set of customer requirements; how is the procedure described here anyhow relevant to us?”. Well, first and foremost, good on you! I am sure there are still such workflows where the product and marketing set everything in advance right at the start of the project and all we are left with is the technical implementation. I have personally participated in only one such a case. Let’s face it, on the one hand these are quite rare cases, and even then, you probably had to do some work, and then on the other hand you need to know how to deliver even when things are not exactly text book perfect.
If we look at the process of requirement forming into main subjects, we can divide it roughly into 3 parts and they are not necessarily in chronological order: identifying the stakeholders for the product, defining the MVP and listing all the system requirements.
As a quick note here, for an exception for this post: the identification process of the product’s stakeholders is somewhat of an art. But we’ll leave that to another post. We will assume for the purpose of this discussion that we have clearly identified all the stakeholders in the proposed product, and in order to keep this post shorter than a Stephen King novel as our example we will have only 3 random stakeholders: Product to represent the end client, Supply Chain and SW team (yes, yes, SW are considered stakeholders when it comes to system engineering).
There are usually two types of requirement paths for a system: top-down requirements and bottom-up requirements. The nature of these two types is totally different and accordingly each type poses different challenges in the understanding of the system requirements.
These two types will be explored below through a simple case example, in which the end result of both types will be a set of requirements for a microscope, but with very different paths to reach that end result.
Top-Down (The classic path): Turning Product\Marketing Requirements into System Requirements
The top-down requirements originate in a product, a customer or a market need for example “a scanning microscope for biological labs”. This is the classic path, where the product managers and\or the marketing managers sit down with the clients, identify their needs and usually sum it up with a few phrases as above and the project kicks off. A day later they (we) would gather all the technical R&D team and tell them “Yay!!! We’re going to build a new microscope.”
Of course, after the initial enthusiasm for the new project settles down, we realize that we have no clue what we have to do.
At this point we start understanding the ins and outs of our end client’s needs through the Product reps. Let’s take again our example. A biological lab may deal with cell research with a typical size of 50-100um, while other specimens of viruses end with typical size of sub 1um. A lot of biological experiments involve fluorescence, do we need this feature inherent in our microscope? Cell research may require handling of transparent specimens, maybe phase-contrast or similar capabilities are in order, slots for changeable filters and so on. What may be the physical dimensions the microscope? What electrical connections are permitted? This is the stage where we, as technical leads, must help the Product reps by suggesting every possible feature we know and verify with them how these features are ordered in the priority lists.
This phase is usually very interesting for both the Product reps and for us system engineers. This is when we discover what technologies may be used, what technical advantages we could bring to the table, while getting a better understanding of the client, the market and everything in between.
I will take this issue up in full in another post, but for now if we could narrow down the main topics to cover with the Product reps these would be:
- MVP (in terms of features)
- Potential clients and markets
- Countries to be supported
- Target BOM price
- Lifetime of the product
- Support and maintenance target costs
Moving Forward Towards Deeper Understanding
Right! So, we have our “must haves” with Product our first stakeholder, as per our example, again very limited only to keep the example simple, but with the emphasis over the optical requirements:
- Minimum required resolution of 25um
- Specimen size (FOV) of 30mm x 30mm
- Specimen height of 500um
- Live image
- Desktop product
- Target BOM price 25K$US
Once we have this initial list of requirements, we take it to the rest of the technical R&D team. At that particular point our optics expert will make a little survey and realize that off-the-shelf objectives that may cope with the resolution and FOV requirements are limited to around 8mm X 8mm in such objectives, so motorized stage for XY scanning is probably a must. In addition, all these objectives have a Depth Of Field (DOF) of around 100um on a good day (take a look at this example). If we sum it up, we would need some kind of a depth scanning microscope with a motorized stage for focus movements, or any other optical trick for that task. All of these if we want to avoid a long and expensive customization process of course.
Here is where our second stakeholder, Supply chain, comes into play. We have a hard limit for the target BOM agreed upon with Product. Taking into account only the objective and a potential motorized stage has consumed the entire budget. Supply chain reps will probably ask what yearly quantities are we planning for this product, and start negotiating with the potential vendors to find a technically suitable solution with the given budget. They may even suggest going for a custom-made solution, within the negotiation with the different vendors. It’s our job as tech leads to support them. We have the whole technical picture in front of us, with the understanding of the trade-offs that can be made to support all the stakeholders and all system requirements. In addition, according to the same optical experts, a live image requires a very high frame rate of FPS = 40f/sec to withstand a reasonable latency for a full resolution image, due to the limited DOF of the available objectives.
Here is where our third stakeholder, SW team, comes into play. To provide the aforementioned latency for the expected calculations and image processing required, we either have to use a very high performance hardware alongside a camera pixel resolution of 5Mpix or more, like this one for example, or we must lower our pixel resolution, which has a huge technical impact over the system design. Furthermore, we got a requirement from SW that significantly impacts the BOM of the system.
We need to negotiate all technical limitation from all stakeholders
In other words, different limitations from different stakeholders coincide and we have to mediate between all of them. Coming up with the technicalities derived from Product requirements is usually not the main challenge (don’t get me wrong, it is indeed a challenge). The main challenge for the initial phase of system design is to make sure all the stakeholders agree with our technical interpretation and its impact over their side of the court.
So now begins another stage of exploration led by the tech leads and system engineers, this time with each subset of stakeholders with coinciding requirements, where we have to communicate the gaps for the team; must have firm and knowledgeable attendance in these “negotiations” as we are the only ones in this stage that are familiar with the full technical trade-offs picture.
So, in our example, we may end up with a slightly different list than the one we started with, for example the live image requirement will be dropped, the sample size will change or the target BOM may have been changed to something a bit more realistic for such a system like 100K$US (Product will have to amend our target market, so this is the least likely scenario in our specific example).
Now, one may say that the process above is already a part of the design, and in a lot of cases I would probably agree with this note, however, in that preliminary “design” process we get aligned with the most important technical features and characteristics for our soon-to-be product.
Only when we have this list can we indeed start the real process of technical system design.
A quick note in passing; in some very technical fields in the industry the market and the clients are fully technical, from which can be deduced that the Product requirements are also technical. In these cases, the translation of the Product requirements is usually nonexistent and we are left only with the negotiations with all the other stakeholders. These cases are easier for us, on the one hand because one aspect of our system requirements formulation was handed to us on a silver platter, but on the other hand there is less to no room for negotiation over the Product requirements since the Product reps are already set on exactly what the client needs.
Bottom-Up: Turning Technology into System Requirements
The bottom-up requirements usually originate in a technology or a feature that seeks the right product or market, for example “we have an optical element with a 1u optical resolution”. Let’s consider our situation for just a moment. We have a hammer, and now we go searching for nails.
The route to system requirements in this case is less straightforward than the top-down path.
There are two different technology origins: – evolution and revolution.
Evolution means our portfolio already includes optical elements or even microscopes and this technology is the next generation. For our example, we already manufacture and market microscopes with a 100u resolution and the 1u is the natural evolution of the same technology of products.
Revolution means we have a technology that is either completely outside the company’s portfolio or something that is a game changer for the market. In our example let’s imagine we came up with the 1u resolution element when the only thing we would have manufactured beforehand was flat windows for precision optics. I am not going to cover the revolution route in this post, simply because it is irrelevant since in these revolutionary cases our requirement lists and stakeholders’ lists may shift very frequently such that no organized and ordered process would really be close to covering such a case. Keep in mind though that the success of a revolutionary technology will usually be dependent on how much its initiator believes in it and how stubborn its creator is.
Back to the evolutionary track. Our first talk of course would be with the Product and Marketing teams. They are the ones who closely interact with the clients. They would be able to quite quickly tell if this is the thing the client has been talking about in his wish list, or, from another angle, if the competition is planning any similar kind of such an evolution. The easiest scenario of course would be one of these two. At this point of the requirement alignment process, it turns into a top-down flow, as we can identify the product path and we have a definite way to identify our product requirements and stakeholders.
If we have taken the on-the-roadmap route the beauty is that we will get a very similar list of system requirements as we did in our top-down example:
- Minimum required resolution of 1um
- Specimen size (Field of View – FOV) of 30mm x 30mm
- Specimen height of 500um
- Desktop product
- Target Bill of Materials (BOM) price 125K$US
At this point we are back to technical negotiations very much like the top-down path I have described earlier however, in this case the weights of the different teams are changed. If in the top-down case the Product reps were the heavy weights then in the bottom-up case their weight goes down to medium at this particular stage of the project, but worry not, towards the end of the development process the Product goes back to be a leading factor.
Once again, we have our list and we can start the process of system design.
Obviously, the more difficult case in the bottom-up scenario is when there is no apparent path between the marketing roadmap and our beautiful tech. Our situation then is not much different than the revolutionary route, apart from the fact that the tech we have at hand is at least in the field of business of our company. To be frank it would call for an extensive market search, and if we in the technical team would not push for it to happen this tech would be buried.
The Importance of Accurate System Requirements
I have been rambling on for quite a bit about how important the initial system requirements are however I have not mention why. Why is it so important to have an agreed upon requirements in the beginning of the project, when we know for a fact that these may well change in the upcoming months of development?
The answer lies in 3 main topics:
- Develop the right product: when we are aligned with all the stakeholders of the product from the start, we reduce to a minimum the risk of developing the wrong product. I know that sounds crazy, but sometimes development projects do not end up with the right product for the time of release. Take Google glass for example.
- Get aligned on features’ priorities: knowing which features have the highest priority and over which features no compromises/reductions can be made keeps the system design within defined limits. That way the route to be taken for reaching the right product is usually shorter. We do not waste high efforts over features which eventually may be omitted from the final product.
- Keep the product development on schedule and on budget: yes, what can we do! We always have a tight schedule and very often a somewhat tight budget as well. A better technical understanding and clearer system requirements will make this task of keeping the schedule and budget risks to a minimum significantly easier.
I hope that after reading this post you have a better understanding of how important it is to align what the system must do with all the relevant stakeholders before jumping into system design, and mainly to note for yourself to get it done thoroughly.