As a systems engineer I would be modestly
irritated that my teams did not follow parameters that were set forward as part
of the design process. To best convert a marketing concept into a real life
system, wish lists dreamed up by high level management (or high level
requirements) must be broken down into more design specific instructions
(Lowen, 2013). Design teams depend on these decomposed instructions (or low
level requirements) to develop the UAV (Lowen, 2013). In a requirements based
design process, special care is taken to drive a high level description of the
design through to the implementation details (Lowen, 2013). In essence, this
high level requirement is transformed into a list bulleting what is needed on a
technical level to carry out the exact system feature (Lowen, 2013). When we
began to exam this particular UAV it should be noted that the design team
failed to hit the checks in the box when they began going over budget. One of
the big flaws in this design was exactly that, the budget, naturally having the
marketing team hype up something and not being able to deliver on that is
costly. Things that we have to consider in this design is what the customer
wanted, they wanted a system that could fly correctly, and secondly that the
system would spray correctly. These considerations become top priority or “high
level requirements,” and because the teams have failed to realize this at the
lower level we now have a system that risks being unsafe and cuts into the fuel
margin.
This brings me up to how things should have
been conducted leading to a much different result. The main focus should be on
decision management. While there are many other important roles that come to be
a factor in systems engineering, in this instance, the “Great Decider” role
plays perhaps the most critical. As the lead systems engineer I would have
implemented design objectives. The first step is to develop objectives and
measures using interviews and focus groups with subject matter experts (SMEs)
and stakeholders ("Decision Management"). For systems engineering
trade-off analyses, stakeholder value often includes competing objectives of
performance, development schedule, unit cost, support costs, and growth potential("Decision
Management"). For corporate decisions, shareholder value would also be
added to this list ("Decision Management"). For performance, a
functional decomposition can help generate a thorough set of potential
objectives ("Decision Management"). For each objective, a measure must be defined to assess the
value of each alternative for that objective. A measure (attribute, criterion,
and metric) must be unambiguous, comprehensive, direct, operational, and
understandable ("Decision Management"). Once we have established our value based
objectives it would then be time to start coming up with designs that would fit
those parameters along with alternative designs that could work. After all of those
details have been ironed out, we would have a set of possible designs with one
of the systems meeting more requirements than the others.
As the great decider I would have the
opportunity to choose the design that best met our customer’s request. Rather
than come up with a design that was costly and tried to cut corners by using
commercially off the shelf products, we could have seen the reward in designing
a custom built UAV to meet customer requirements. So for the next generation
enhanced version of this UAV it may be more costly because of its custom
nature, but it would certainly get the job done without much in the way of
being overweight. As newer technology became available, or once the system was
realized for its useful potential, products that were customized then could
become a viable commercially off the shelf product.
References
Decision
Management. (2015, June 16). Retrieved August 23, 2015, from
http://sebokwiki.org/wiki/Decision_Management
Lowen, H. (2013).
Requirements-based UAV Design Process Explained. Retrieved August 23, 2015,
from http://www.micropilot.com/pdf/requirements-based-uav.pdf
