Product Development: Decomposition of System Design Requirements
Now let us take a look at the decomposition of system design requirements keeping in mind that not all requirements are equally important, and you cannot worry about everything at the same time. Requirements are tiered, and you have to make sure that you have a good handle on the higher tier considerations before you really address the lower tier ones. This constitutes a prioritization of importance. The methodology consists of you sitting down and listing considerations for your product that are applicable and prioritizing them. Not everything can be equally important! If you are working on a wearable maybe size and weight are the top tier requirements. Grouping requirements into tiers ensures that you have a good view of the relative importance among them, so that you can make decisions. You cannot make decisions if you do not understand the different levels of importance of the considerations of your design and that goes directly to the tradeoff analysis that that will be part of the design phase. The decomposition of system design requirements also helps with determining the makeup of the design team in terms of size and mixture of expertise. It also puts your customer in a good position to make good decisions. At the end of the day is the customers project, it is their decision but you as an engineer and as a professional have a responsibility, it is your job to provide good information so that your customer can make the best decision possible. That has huge ethical implications and that is what we are supposed to do. Because of the complexity of modern system, systems engineering has found applicability on all types of domains. The application of this disciplined process also allows to delay commitments that are both of technological and financial natures. If you delay expenses, because of the time value of money, the more you delay your expenses, that is economically good as long as the overall timeline does not get affected negatively. So, we are talking about spending more time specifying upfront, then swiftly executing and spending money later because you know exactly what you have to do. This also implies that as the product life cycle progresses, the system specific knowledge necessity decreases, and the domain specific knowledge necessity increases. Then you can manage changes via configuration management. And to close with an example, think of all the thought that has to be put upfront to allow for devices to update the firmware over the air, the way phones get updated today. It wasn’t always like that. Not long ago, phones had to be tethered to a computer to get updated. Indeed, the complexity of systems is increasing rapidly. And this is more than a good case to use systems engineering practices.