Converting Software Requirements to Code

March 25, 2024

{ PART 2 of Software for Non-software Founders }

Taking a software product or component to market can be a complex process, but when done right can lead to not just a good product, but a lovable product. In Part 1 of this series, we looked at the overall software development process and how we work out what a piece of software should do. 

In this article, we’ll continue the journey of the “SmartBell”, a dumbbell that counts the number of repetitions, and find out how we transform our software requirements into real code.

Software design

We’ve captured what the product should do in the requirements phase, the next step is to work out how the software is going to work. Even if no design has been written down before writing code, a developer usually has a one in mind. Of course, writing down the design can help formulate ideas and gives team members the opportunity to review and critique the design. A well-documented design is good practice and the more complex the software, or if multiple teams are involved, the more important documentation becomes.

In software, we can still think of the overall architecture of the code we’re about to write, much in the same that a physical product designer would work out what sub-parts a product is made up of. We can identify the different modules that make up the software and how they interact each other. More detail can then be added on how each module operates.

For our SmartBell, our product is made up of two software packages: the software on the microcontroller, and the phone application. At the design stage we would decide what languages the two pieces of software would be written in, and any tools and libraries that may be used in their development. We also need to determine how the two packages talk to each other. It’s not enough to say the SmartBell and the phone app will communicate over Bluetooth, there may be commands sent from the phone that the microcontroller on the product needs to respond to, or data may need to be formatted in a particular way (this may have been stated as some requirement earlier on). This all needs to be designed.

Drilling down into the design of the microcontroller source code, we want to determine how it will get and process the data from the accelerometer, and how it will handle communications over Bluetooth. There are many approaches to documenting software design, from explicitly writing out the design in words, to graphical designs like sequence and state diagrams. 

example of a state diagram
Figure 1. An example state diagram for a button press.
Example of a sequence diagram
Figure 2. An example sequence diagram for a firmware update

From design to usable software

Once we’ve worked out what the software should do, we can (finally) start writing code. Software tends to be written in “high-level” languages, such as C or Python, but an additional compiling stage is required to get this code into a machine-readable language. Software is typically developed within an IDE (integrated development environment), a tool that allows engineers to develop software, compile code, and upload it to a device. Most microcontroller and processor manufacturers have IDEs for their products, minimising the time spent on setting up programming environment for the processor we’re working with.


Austin of i4PD working at his laptop on software

More advanced IDEs allow you test your software, which is a vital, yet often overlooked, part of developing high-quality code. Debugging in IDEs helps you to see how the code is running on the device and pinpoint lines of code which are causing problems.

Can you check this for me? 

After writing any code it’s always  important to get someone to look over it (this is the case for any area of product design). Code reviews can take many forms, from a traditional meeting of a team who look over the code and discuss, to using online tools where reviewers can leave comments on code in a similar manner to an online forum discussion. Tools like GitHub provide useful tools for code reviews, alongside being a source code repository.

In part 3, we’ll move onto getting our code into the real world and see how we can check it actually works. If you’ve got a new product or idea you would like to develop, book a call to speak to one of our experienced engineers who can help bring your ideas into reality.

Posted in: ,

Latest News

Showcasing Medical Technology, Design and Manufacturing
Software Testing and Launch
Converting Software Requirements to Code

In this series of articles we’ll talk about how software is “made” and show how i4PD can help you with your software projects. This first article describes how to capture your software requirements.

It all starts with a conversation.
Let's make something amazing together.

We'd love to hear from you.
Book a Meeting

Leverage our #DesignInsights to shape your development.

Subscribe for our webinars, articles and reports.
Subscribe Now
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram