Electrical Design Specialist
There are many things a hardware design engineer needs to consider when embarking on a new project. When I started out back in the mid 90’s as an applications engineer, I did not have much design experience and I was lucky to be able to learn the ropes without the pressure of having to deliver a product at the end. I was designing hardware interface adapters and software applications to talk to cameras as well as FPGA code for CCD sensor timing to support customers. I have noticed that many of us today are spread so thin that there is little time for mentoring and supporting the more junior staff. Often, we leave the inexperienced on their own, letting them learn on the job. My hope is that this series of articles will give you a jump on your learning curve. Please note that I write this from the view of a hardware designer, though many of the points I will make are applicable to other specialties within Engineering.
You may be reluctant reading this. There is a good chance you consider the topic of requirements boring, as most design Engineers I know want to dive into their design work right away. For many of us that is why we became Engineers in the first place. After you have read this article, I hope you may reconsider and value the importance of your product requirements and use them as an inspiration to create great products. Spending time upfront has the potential to save you a lot of time and money in the months ahead. When complete, the requirements should provide you with all the information you need to know about what it is you are being asked to develop. The how will be explored afterwards.
Whether you are employed or you created a start-up, have you ever asked yourself why your company is doing what it is doing? What does your company believe in? Or is everyone only there to make money? Understanding and communicating the “why” will inspire your employees, your colleagues, your customers, and most importantly YOU. People will follow you and purchase your products because they are aligned with your beliefs. I always drew a lot of motivation and excitement from understanding why I was designing a particular product, how it was going to be used in the field, and how it would benefit customers and consumers. I found this especially important on days when things did not go so smoothly.
Tip: Check out this TED talk. I found it to be very insightful and in fact inspiring. It points out that to think about what, how, and why in that order does not inspire and lacks connection (my words). Instead the reverse order of why, how, and what is what gets people excited. Simon Sinek gives several examples, Apple being an obvious one.
Make sure you can and are standing behind the product you are about to start designing. I can only hope your company allows its employees to not participate in a product development, when it goes against some of your personal values and your beliefs. I had the situation once where I was asked to participate in a military smart gun development. I have never been comfortable around guns. Even as a young man living in Germany, I chose an alternate civil service when the time came for me to do my military service, which was compulsory at the time. So, I simply said thanks, but no thanks. Luckily my manager responded kindly and was totally understanding.
A bit more food for thought
I have been reading these articles written by my colleague, Les Hirst, and I thought I would mention them here. They may evoke a different side of product development, more in the direction of sustainability, longevity, and beauty. If you like to think outside the box, have a look at them.
A Side Note
You may wonder what these last paragraphs have to do with requirements and I would agree that in the traditional sense of that topic, maybe only a little. But the more I think about it, the more I believe that asking myself some difficult questions early on is essential for my ability to stand behind the product I am investing much time, sweat, and tears into.
Back to the topic at hand…
The image depicts the different points discussed below and how all of them influence the requirements. Each point is driven by stakeholders that determine and define your requirements.
The first thing I find useful is to understand who my stakeholders are. A stakeholder is anyone that influences your requirements and with it the product you are about to design. The list can become quite long and it can be helpful to divide your list of stakeholders into primary and secondary to better understand their influence.
Here some examples of stakeholders:
Understand how your product will be used – intended and unintended. You may be designing your product for a specific use, which is (are) your intended use scenario(s). It is a good idea to review this and investigate whether there are potential unintended uses. By doing this you may choose to expand your list of intended uses or you may need to discourage users from using your product in an unintended way.
We all use cell phones – the intended use was surely to get us more connected, to simplify life. One of the unintended consequences is how much time it consumes every day and how habitual its use becomes to us. Another beep, another light goes off and I am picking up that phone. How many times do I see a couple at a restaurant both staring at their phones? They are not talking and I jokingly wonder if they are texting each other… (I know it is a sad joke). Knowing the unintended consequences can be important to understand the impact a product may have on its customers.
What market is your product designed for? Is it a mining, medical, military, aerospace, or may be a consumer product? Depending on the market you may have additional requirements for design and manufacturing. You may also require ISO certified facilities.
The market often dictates what the customer is paying for the product. This has a direct impact on your Bill of Materials and the Cost of Goods Sold, which includes any costs to produce the product (excluding indirect costs). Manufacturing and indirect costs such as distribution and shipping may also influence where you are planning to manufacture the product and at what volumes.
Where in the world is your product being sold? Different parts of the world have different requirements for imports and thus influence product testing as well as environmental and safety certifications. This will have an impact on your ability to sell and ship to these countries.
For the purpose of shipping, your design may also be influenced by requirements such as weight, shape, and size of the product and its packaging. In order to manage these aspects, the product may require partial assembly by the customer.
Environmental and Safety
Think early on about how safe your product is for users and the previously discussed intended and unintended use cases.
Mechanical and Industrial
Your product likely requires some sort of housing. No matter how simple or complex this housing is, all functional inputs and outputs (such as buttons, switches, displays, LEDs…) need to be specified to ensure your design can support it. If possible, understand what type of industrial design the marketing and product management folks are thinking about. You will also want to understand how humans or machines interact with your functional inputs and outputs.
Tip: In many cases the shape of your PCB and the location of components is driven by the mechanical and industrial design aspects of the product, not where it is necessarily convenient for your circuits.
Mechanical designers have their own set of requirements, often related to the materials they need to use, tolerancing the design for (mass) production, and so on. Your PCBA in essence becomes a mechanical component in your product once assembled.
Tip: Today’s tools are great in creating visual 3D models of the PCBA and letting the mechanical designers import them into their work. This minimizes risks for interference and assembly.
As a design engineer you are likely familiar with gathering and/or receiving any functional and performance requirements for the product you are to design. Make sure you understand how the product is supposed to function and as mentioned above how others interface to or with it. Also have a good understanding on how the product is required to perform and why.
I suggest you take time and study these requirements. Clarify any questions you may have and ensure that nothing is left up to chance. The better your requirements, the easier it becomes to design the product. If at any time in the design phase questions arise, ensure to get clear answers from your stakeholders and don’t forget to amend the requirements.
Tip: Spend time on checking and rechecking the requirements to see if anything was missed.
Failure Mode Effect Analysis (FMEA)
Make a decision early on whether you want apply an FMEA to your product design. It provides the opportunity to mitigate design risks early on, and lowers overall costs of development and production. Design FMEA (DFMEA) explores the possibility of product malfunctions, reduced product life, safety, and regulatory concerns.
If you choose not to do a DFMEA, consider identifying these types of risks in your product design informally and find ways to mitigate them early on. Think about and investigate what might go wrong. If, for instance, a customer can apply the wrong product input voltage and has the potential of creating a fire hazard, you may need to include in your requirements ways preventing that.
Note: Writing this I remember the 2016 Samsung Galaxy Note 7 cell phone recall, because the batteries could generate excessive heat causing fires and explosions. Not good…
Manufacturing and Supply Chain Management
Check with manufacturing, purchasing, suppliers, component engineering, … if they have any specific requirements for your design. Chances are they may want to provide you with information on what components or suppliers to avoid or where you might encounter prior known risks.
Tip: Many Contract Manufacturers (CMs) have readily available documentation outlining many of their design requirements.
Many design aspects require considerations that are best studied and discussed early on in product development, thus can and should be included in the product requirements. Leaving these discussions and the collection of information to a later date will have an impact on your architecture and your design as well as your ability to deliver product to market on time.
This article was originally published on HaraldSiefkan.com and has been reposted here with permission.