New products can be made from a myriad of different components, ranging from the humble screw to a complex circuit board with thousands of components soldered onto it. Alongside these physical components, modern electronics devices typically contain software run on microcontrollers or processors. While we can “see” how something like a circuit board can be made, the creation of software, often described as a bunch of ones and zeros, can seem a bit more ethereal. Functional and well characterised software is not made in isolation or in chaos but through a structured development process.

The process of creating software at i4PD starts with capturing requirements (what we want the software to do) and generating architecture concepts to design the software. This design is coded up (or implemented to use the more formal process language), and the individual components of the software are tested to make sure they work. Once the components are tested, they are integrated into the wider product system. All stages of this process are reviewed by other members of the team to maintain quality, and once we’re happy with the software that has been developed, it can be released to the client for them to use.

This release isn’t necessarily the final software package, it’s all part of an iterative process. This means our clients can get their hands on working software early and can test out functions with users. Along with the satisfaction seeing something working, it can also help the design process as requirements can be discovered and refined by playing with functional tools.

We don’t have to give each activity equal time during each iteration – early iterations may focus on requirements capture as we try to understand what the product needs to do, while later iterations can focus on testing the software works as intended. We can also vary the level of detail required for each of these activities dependent on the client needs. For quick proofs-of-concept we can focus on writing the code rather than documenting the design, leaving more time to explore the use of the device. For more complex products, such as medical devices, full design history files are created including test procedures to verify the design as part of the V-Model of product development (see image at the top of the page).

Over this series of articles we’ll look at each of these activities with a simple product, a “smart” dumbbell that counts the number of bicep curls performed by a user. During an exercise session, the “SmartBell” transfers the count to a phone app. For the purposes of discussing software, the product contains an accelerometer connected to a bluetooth module containing a programmable microcontroller.

Clear requirements are key to developing high-quality software and require an experienced development team to set good foundations. An ambiguous requirement is open to interpretation, making it difficult to design and test the software (see Part 3 for more on software testing). Ideally, each requirement should be written in a way so that it can be easily tested. Consider this requirement for our SmartBell:

The software should quickly and accurately measure how much exercise is being done

How quick is quick? What is the acceptable accuracy? How is exercise measured? What data is being used? Often these additional questions are obvious to the person stating the requirement, but to others these statements can lead to incorrect assumptions and poorly constructed software. For this example, it is easier to break up the original requirement into several requirements:

A bicep curl is detected from accelerometer data by a vertical movement of the SmartBell, followed by a downward movement

The software shall calculate the direction of movement of the SmartBell from the embedded accelerometer

The software shall count the number of repetitions of a bicep curl using the direction information from the accelerometer

The software shall correctly identify a bicep curl with a minimum true positive rate of 95%

The false positive rate of identifying a bicep curl shall not exceed 3%

The software shall identify a bicep curl in less than 0.25s of one being performed by a user

In this case, there are no ambiguities in what is given in the requirements and it is clear how they can be tested (note this is only a subset of the requirements for the SmartBell). Requirements can also be written in the form of a “User Story”, which can give a more natural description of a requirement.

It’s not always possible to list all the requirements at the beginning of a project. A prototype may need to be developed to test acceptable processing times. But clear requirements are vital to developing a successful product.

In the next article we’ll move on from working out what our software will do to actually making software. If you’ve got a new product to develop, book a call to speak to one of our experienced engineers who can help bring your ideas into reality.