How To Write Technical Specification Of An Embedded Product

Many engineers loose time and effort because they don’t have a clear technical specification of their product. They start with the design and keep adjusting as they discover more. They end up redoing part of the design because old architecture does not hold good for the new requirements. This is a huge waste of time, effort and cost.

Let me share what you should do before starting any design activity. A detailed technical design requirement specification document should be created. Start with a running shared document (Google doc or Google sheet) where all team members can collaborate and contribute to the spec.

Next question is, what all, a technical requirement specification document should contain?

Product spec should cover the main things like the purpose of the product, block diagram, main features, environmental conditions, manufacturing requirements, etc.

Technical specifications should also cover the specifics required for a particular product design.

Technical Specification should have the following details:

1. Purpose of the design/product

What is the purpose or idea behind this product? What is the problem is it solving?

This information helps team members get a perspective and then, they can start thinking about how to design.

2. Block diagram

Start with a rough block diagram (hand-sketch) of the product to define different sub-blocks and keep refining as the discussion progresses. This is important to have a good high-level overview of the project.

How to write technical specification of an embedded product 1 — Example Block Diagram of a temperature humidity data logger

3. Prerequisite Design Requirements

3a. Environmental Conditions

Understand the environmental conditions in which the product will operate. Some of the questions this section should answer are:

What will be the operating & storage temperature range (eg: 0 – 50 Degree C)?
What is the operating humidity range (eg: 5 – 95 RH%)?
The level of vibration the product may face
What will be the type of installation, is it indoor or an outdoor?
What is mount type like DIN rail mount, wall mount, pole mount, will be kept on the table?
Is the environment corrosive (chemical fumes, gases, etc)?
Is waterproofing required?
Is the product need to operate near the Sea?

This will not only influence the circuit but also the enclosure design.

3b. Compliances Required

Understand the need for various compliances like FCC, CE, UL, IEC, FDA, explosion-proof, corrosion-proof, fireproof, IP rating (IP67, IP68), etc.

3c. Target BOM cost

Target BOM cost gives the necessary direction to the design engineer for selecting various components, PCB technology to be used. Like, smaller PCB will cost less, mounting components on both sides of the PCB will cost more time and cost in the production but reduces the PCB size, etc. You can read more in this article about how to reduce the cost of your embedded design.

3d. Expected Production Volume

For high volume production, consider making a design that is faster to produce. Like, use all machine solderable SMD components, penalizing the design. If possible, eliminate any manual process during production.

Use automated PCBA inspection and functional testing (this may need some design changes to allow fully automated testing).

3e. Product Availability

Engineers should know the availability/expected life of the product. If it is for 1 or 2 years, they might not need to give special attention to the component’s EOL and alternates. But, if the product will be available for 5 years or more, It is important to consider long term availability while selecting various. As you not only want to sell the product for 5 or more years but few more years to handle service/repairs.

3f. Warranty

Information about the warranty is useful to understand the reliability needs. This helps design engineers to take special care while selecting components and designing circuitry. Design for a warranty of 1 year and 10 years could be entirely different.

4. Main Features

4a. Hardware

Hardware spec will mainly cover all the detailed requirements related to various features as given in the block diagram. Some of the example specs could be as mentioned below:

It should have WiFi connectivity.
It should have a display which the user can see from 5 feet.
Easy interface to configure via a keypad(4×4).
One LED to state power ON, another to show if GPRS is active or not.
It should have one RS232, two RS485 interfaces.
It should have 4x Digital Inputs, all should be 24V compatible.
It should have two relays to control external equipment.
It should be powered by 5V DC input.
The whole product should not consume more than 5W peak and 2W typical.

4b. Hardware Protections

List all the protections required in various parts of the hardware. For example, DC input voltage should have over-voltage, over current, surge protection. All IO interfaces should have ESD protection. Industrial Interfaces like RS232, RS485 should have Surge protection, isolation based on the requirement.

Basically, think about how the product can fail from a hardware point of view? Define all protections to make sure the product works reliably for a longer period.

Read this article for more details on critical circuit protections for an embedded design.

4c. Firmware

Create a high-level flowchart and discuss with the team the high-level code execution plan.
It is good to create the structure of the code keeping modularity and reuse in mind.
For an LCD, define the screen layouts.
For the communication interface, define a clear command-response packet structure.
Analyze if an RTOS is required?
Is power management critical, necessary hardware is in place?

4d. Field Upgradable Firmware

Project timelines are always tight and limited time is available for testing. Also, it is quite impractical to test all field conditions, so there might be a need to fix a bug or provide a feature update to improve the user experience when the product is already in the field.

How are you going to handle it?

If the product is already having a connectivity interface like BLE, WiFi, GPRS, etc. it will be easy to create the firmware upgrade mechanism.

If wireless connectivity is not available, engineers should create the firmware upgrade mechanism over wired interfaces like a USB drive or over interfaces like USB/RS232/RS485, etc.

Upgrade mechanism should be easy to use by service and support staff. Also in any scenario, there should not be a need to open the product enclosure and do the software upgrade.

4e. Software (PC/Mobile)

Is there a need for PC based configuration software, how the user will use it, which all OS it should support?
If there is a mobile app required, which all Mobile OS it should support?
Define functional details and screens.

4f. User experience

Today, it’s not just the features & reliability of the product but the entire user experience which is driving the sales.

List down user experience needs. Make a list of features that will improve the whole user experience while operating the product.

Some Medical or Pharmaceutical use-cases might need minimal or no human touch. This is to avoid spreading infection or contamination.

4g. Enclosure

It will be good to start visualizing how the product will look like. How many PCBs it will have, how they will interconnect, etc.

It is good to create hand-sketches and discuss different ideas with the team. Always keep users need in mind while designing the enclosure. You should also consider creating 3D models and fit all the components inside to analyze if it goes well from the ease of manufacturing, repair and user experience point of view.

Enclosure design will also be driven by environmental conditions, compliance requirements & thermal management needs.

5. Production

5a. Manufacturing (DFM)

This section should answer if the design is manufacturable?

Various considerations from the manufacturing point of view w.r.t to the available manufacturing ecosystem should be listed as design inputs to the engineers.

5b. Validation & Production Testing

More testing you do better you know the reliability of the product.

A proper test plan need to be created both for the validation and for the production testing. A proper plan will help designers ensure that the product is easy to test in both scenarios.

For example, providing necessary access to test points & interfaces for design validation. Any additional firmware changes required to enable the testing.

In high volume production, testing time is very important. Design the product in such a way that all test points are accessible and the automated test setup takes the least amount of time to set up and test the product with maximum coverage.

6. Field Failure Strategy

It is impossible to design a circuit that doesn’t fail, so better to think about the scenarios in which the product could fail and then how to handle them.

Do you want the user to ship back the product when it fails?

In this scenario, you would want to make sure the design is so rugged. If the product failure is more, it will impact the user’s confidence, brand value. The turnaround time should also be very low when there is repair required.

Or you are going to have nearby service centers? This ultimately adds up to the cost of the product because you need to maintain service centers and all the costs associated with it.

Ultimately, you need to decide if the product/board is going to be repairable or not. This information is useful for design engineers when designing the product and taking various decisions that will influence the reliability and repairability of the product.

7. Documentation & Support

The documentation of the product is very important. This provides user necessary information which enables them to compare products vs their requirements.

They can understand the features of the product before making a purchase decision. Bad documentation of the product is drive no or very limited sales.

Once you have sold the product, the customer also needs to know how to use the product in the easiest and effective way.

How easy and intuitive your product’s user interface is, will define how much support will be required. Depending on the requirement you may need to create how-to articles, videos, etc. or even a one-to-one support channel to help the customers.

Documentation and support could be the most important differentiation in many complex use cases, especially when your product is a raw material to the final product.

Conclusion: It is not easy to create a detailed technical specification of an embedded product when you don’t have much experience in the design or you are a startup with no defined processes yet. But, a well defined technical specification not only gives clarity to the design engineer but saves a huge amount of time and effort otherwise would go waste.

I hope this article gives you enough inputs about which all points should be included in your product’s technical specification template document.

Download Free Template

If you need the technical specification template in an Xls format, I will send it to you over email. Use the form below. Check your SPAM folder if you don’t get the email in few minutes.

Free Template Document