Surname 1

Student’s Name

Instructor

Course

Date

Reflection on Grant Garraway’s Talk

Getting the engineering design process right is pivotal to ensure that the end product is

not only useful but functional. The guest talk from Mr. Grant Garraway focused on how

engineers can get the design right by understanding the design lifecycle of systems. One part of

the talk that resonated with me was in the beginning where Garraway showed the effects of

getting the design wrong using a video clip from the movie, “Pentagon Wars”. From the satirical

clip, the stakeholders keep changing the requirements definition of the Bradley vehicle. Without

a clear requirements definition, they end up with a flawed military vehicle. The clip influenced

my approach towards engineering design, as I will ensure that the requirements of my design are

clear from the beginning, to prevent making abrupt changes on the ongoing design.

Garraway, in his talk, shows an explicit illustration of a design life cycle of technical

systems. The processes of the life cycle includes ten steps starting with the definition of

requirements by stakeholders. Other steps are conducting a requirements analysis, architectural

design, implementation, integration, verification, transition to operation, validation, operation

and maintenance, and finally disposal. The clear outline of the processes will act as a guideline

as to how I design my interactive fishing lure project. An interesting fact that I learnt from the

phase “definition of requirements by the stakeholders” is that the cost to repair requirements

errors increases by 200 times if takes until maintenance to find. For example, if the cost of
 Surname 2

repairing a requirement error discovered when conducting analyses is X, then the cost converts

to 200X if it not discovered until maintenance. Therefore, the later a requirement error is found,

the more expensive it becomes to correct it.

The importance of the requirements process model is undeniable. Garraway provided a

model that involves elicitation, analysis and negotiation, documentation, and validation.

Elicitation involves uncovering the requirements through consulting with stakeholders, going

through system documents, and conducting market studies. Analyzing and negotiating the

requirements with stakeholders is very critical in my view. In conjunction with the video clip on

Pentagon wars, failing to settle on specific requirements would lead to endless changes and

frustrations. Documentation helps to manage the requirements while validation ensures that they

fit the customers’ needs. Each good requirement shall at least have a subject, object, and

qualification. An example of a requirement from my interactive fishing lure project is, “The

interactive fishing Lure (subject) shall have a tension sensor (object) to inform the user that a fish

is hooked (qualification)”.

Garraway’s talk has impacted the way I will conduct my design from the requirements

definition to the moment I will test and demonstrate the design in operation. From Garraway, I

have learnt that I must not be ambiguous or use vague terms such as efficient or high

performance when explaining my design. I have also discovered that a design cannot be perfect

and I will, thus, avoid using wishful terms such as “please all users” or “100% reliable” as

advised by Garraway.