Author: Indrek Keskküla, an electronics engineer at Krakul
Indrek Keskküla is an Electronics Engineer at Krakul, and he is also a true fan of the field, as he keeps a blog where he shares his thoughts and tips about the electronics development process. We will be sharing some of his blog posts in English. If you would like to read his original blog in Estonian, visit his Electronics Design Blog. The second post is about the specification of a successful electronics development project. Enjoy!
The first step in the electronics development process is to create a specification. A specification is a document that describes the ordered electronics system from the customer’s point of view. The specification must be concrete. An ideal specification leaves no room for ambiguity and it should be in the best interest of all parties to make this document as accurate as possible.
It’s in the customer’s interest to ensure that they receive what has been ordered.
The engineer’s interest is to develop what the customer needs.
It’s important to understand that the customer is not necessarily someone from another company. It can also be a product owner or a responsible project manager at your firm.
From an engineer’s point of view, there are three ways to obtain a specification.
It’s preferred that the customer has considerable experience in ordering electronics design and will come to you with a finished specification. In this case, you can immediately start planning the project and estimate the amount of work that needs to be done. You can plan the workload of the development team, make detailed time sheets, and define clear work outputs as well as milestones. It’s usually favored by the client to get a fixed-budget project.
It’s great if the client agrees to a project where you help them write the specification. You get to know their needs in-depth and, in cooperation with the client’s team, you create the specification based on which you can make a fixed price offer. It’s beneficial for the client as they can request quotes from various development agencies.
Quite common is to have an arrangement where the specification is created during the work. It’s a shared and living document where the latest agreements are recorded as they arise. The project is started, the engineer identifies the place where a strategic technology choice needs to be made, discussions take place, the technical decision is made and it continues until the next decision point. Understandably, in such a case, it’s not possible to predict how much time and money it will take to complete the project. This approach is suitable for clients who don’t have a fixed budget, have a lot of time, and are still looking for the right solution to offer to the market.
NB! Make sure the client understands which approach they are choosing and what are the impacts on the project budget and schedule.
Electronics specification content
Requirements management is a science in itself and has been refined to a particularly high level in software organizations. It’s a system where every requirement has a documented source, importance metric, control mechanism, responsible person, verifier, and owner. If you end up working on a project where this kind of specification and requirements management is implemented, you usually don’t have to deal with it too much. Such projects often have more than two parties and separate roles, and people for requirements management.
What we are talking about here is a project where the agreement is bilateral – between you and the client. The purpose of the specification is to agree on what will be developed.
It makes sense to start with a diagram of the context of the electronic system. This is an illustration displaying the device in its ecosystem. What other devices does it interface with and how? Does it have buttons, speakers, screens, antennas? How are they interfaced? Where does the power come from?
Example below
By developing this blueprint together with the customer, you can create confidence that all the interfaces that the product needs are mapped. This creates a common understanding of what the product features are.
In this process, the engineer needs to ask questions. The quality of the questions depends on how much experience you have had with different development projects. There isn’t a certain methodology that is guaranteed to help you ask better questions. The advice would be don’t be afraid to look stupid and ask anything that seems suspicious. Don’t rush into assessments and don’t be scared to question the client’s ideas if they seem illogical to you. The purpose of these questions is to ensure a common understanding of the customer’s needs and the reasons behind them. Throughout the process, you would need to remain modest because the customer probably knows their business better than you do. If the client’s vision and yours don’t match, and your arguments don’t convince the client, let go of your idea and implement the client’s wish. Just don’t forget to document the decision carefully.
If the context is clear, take a look at each interface separately and write down its exact technical requirements. Describe all the electrical connections, their connector types, and signal locations within the connector. Then mark down the important parameters of each signal or set of signals (e.g. interface with Arduino), standards, and other things that may be related to the interface (bit rate, voltage levels, the position of termination resistor, open-collector vs. push-pull, etc.).
For example, a product must have three switches. Is it enough to put 3 surface-mount push buttons on the board, or must an industrial designer be involved to choose the right technology? If we have identified one unknown – what will the device look like, what will be the physical feedback of the button press, and what kind of a click it will be? How much pressure there will be?
The best way to eliminate the unknown is to experiment. Build a prototype and test it. Through simulation or guesswork, it’s difficult to decide how strong the display backlight must be or what the PWM frequency must be so that the flickering of the lamp is not perceptible.
Software features should also be discussed during specification creation. In the hardware specification zone, software requirements are not usually discussed, but work on specifying software functions should be done in parallel. Software requirements can become hardware requirements and vice versa. It’s possible to find ways to optimize the product by transferring some functions from hardware to software and vice versa. Remind the rest of the team and hold meetings if no one else does.
After all the electrical side has been described, we move on to the mechanical side. Are there requirements for the shape of the PCB, mounting methods, and mechanical loads? Are there environmental requirements for vibration resistance, temperatures, and IP class? At the same time, it is necessary to agree on how compliance with the requirements will be checked. It’s possible that this part cannot go into great depth, because part of the project is also the creation of industrial design.
What is described here is certainly not exhaustive. The specification may also include requirements for manufacturability, testability in production, repairability, and product life. In addition, it can include requirements for your organization. That you have an ISO 9001 certificate of conformity. Or how quickly you have to react to a production stoppage, a quality problem, or a request to analyze a broken device during the warranty period.
Remember that not everything described here may be relevant and necessary to your project. Keep in mind the principle – everything important for the project must be discussed.
Specification document
All the information described and created in the previous chapter must be written down. Make a separate chapter for each interface or function, and describe each requirement separately. Adding a number to each item makes it easier to refer to and preserve the history of the document.
Here is an example:
4. Electrical requirements
4.1 PWM outputs
4.1.1 The nominal frequency is 200Hz
4.1.2 The filling factor must be adjustable in 1% steps from 0-100%.
4.1.3 The maximum output current is 0.5A
4.1.4 The maximum output power is 6W
4.1.5 The output must be short-circuit proof
4.1.6 The output short-circuit must not disturb the operation of the rest of the device
4.1.7 The short-circuit protection must not operate at a current lower than 1A
4.1.8 The standard output load is a 6W 12V GU5.3 LED light bulb
And so on for each interface and function until everything important is written down. You can just use one of your favorite word-processing tools. Even a simple product specification can be rather long.
In conclusion
At some point during the project, the specification must be approved by the client and you. It would be great to sign the specification document, but the confirmation given in the email conversation is also suitable. It must be controllable. It becomes the basis on which project planning can be done. It’s part of the agreement, what the client gets and what he pays for, and where the line runs in the project, where your responsibility begins and ends. Specific work tasks, work outputs, and transfer points arise.
The purpose of the specification is to achieve the greatest possible common understanding of the client’s expectations for the project together with the client. It’s in the mutual interest of the engineer and the client that the expectations for the project are clearly understood. If there is a gap between the customer’s wish and your creation, there can be arguments. Regardless of how such disputes end, the relationship with the client and your reputation as a professional have been damaged. The first step to take against such a situation is to create a specification.
Contact:
press@krakul.eu
