CC Blog Design Solutions

Eliciting Software Requirements for Embedded Systems

FIGURE 1 React Native logo.
Written by Bob Japenga

Part 1: Conventional Methods

In the first of this two-part series, Bob looks at some methods that he has used over the past 50 years for discovering the requirements of a particular embedded system or piece of software. Drawing on his vast experience in determining and writing down requirements, he provides several different ways to help identify the requirements.


  • How can I identify software requirements for an embedded system?
  • What is React Native?
  • Why should I plan ahead for software requirements of an embedded system, when developing?
  • React Native
  • React Native

I am a firm believer in writing software specifications. More than 20 years ago, I penned a white paper and published it on the website of our company (which designed embedded systems software and hardware). The paper was about how to write a software requirements specification [1]. By far, it is the most widely cited document in both industry and academia on our website, and it has been translated into several languages. Writing down clear software requirements is so important to me that, though retired, I still write requirements documentation for software that I am writing on my own.

Most recently, I have been writing a cloud driven mobile app running on both iOS and Android systems using React Native (Figure 1), an open-source UI software framework created by Meta Platforms, Inc. It has a simple backend written in HTML5, JavaScript and PHP. (I know this is old school, but it was what I knew.) The backend simplified the filling in of the JSON data, which drives almost everything in the app. Even the simple backend had a spec.

FIGURE 1
React Native logo.
FIGURE 1
React Native logo.

But once I implemented it and started testing it, I discovered that a major feature was missing that I had not specified. To my embarrassment, I had not spec’d a way to load an existing field for editing. Had I thought of this requirement in advance, I would have structured the data and the software slightly differently. But here I was, a week or so from releasing it to some beta testers, and I really needed to fill this glaring hole. Pressed to get the project released for testing, I shoehorned the feature in, rather than restructuring the design to better accommodate this feature. Needless to say, that shoehorn caused an embarrassing bug when I first ran a demo of the backend.

This is a well-known story in the life of embedded systems design. If we have not thought through the requirements up front, we may find it costly to add it later. It is a well-known fact that fixing a bug gets more expensive later in the life cycle of a project [2], assuming it costs $1 to fix a bug during the requirements phase (as illustrated in Figure 2). But adding an unexpected feature can be much more expensive to add later, if it wasn’t planned for in the beginning. In many respects, this is a major problem with one-person shows. We just cannot think through all of the possible requirements and scenarios for the project.

FIGURE 2
Life cycle cost of software defects, assuming it costs $1 to fix a bug during the requirements phase [2].
FIGURE 2
Life cycle cost of software defects, assuming it costs $1 to fix a bug during the requirements phase [2].

This month, I want to talk about the conventional ways of eliciting the software requirements for the embedded systems we have used in our business. In Part 2, I will address the problems with the conventional approach and propose an alternate way of eliciting requirements.

WAYS TO ELICIT REQUIREMENTS

What do I mean by “eliciting requirements.” This is different from “illicit” requirements, though it sounds similar! Simply put, this is the process of discovering the requirements of a particular system or piece of software. Table 1 provides a list of some of the ways that we have used for eliciting requirements. Let’s look at each technique more closely.

TABLE 1
Techniques for eliciting software requirements.
TABLE 1
Techniques for eliciting software requirements.

Brainstorming: Every two weeks, our company held a brainstorming meeting during lunch (Figure 3). It was voluntary, but since we provided lunch, everyone always came. Over the years, we used these for developing product ideas and also for requirement elicitation.

FIGURE 3
Brainstorming meetings are helpful for compiling all possible requirements, regardless of their feasibility.
FIGURE 3
Brainstorming meetings are helpful for compiling all possible requirements, regardless of their feasibility.

In a rapid-fire process, we tried to come up with as many requirements as we could think of (whether they were desirable or not). The basic rule was that any idea was treated with respect and not dismissed. Having many creative individuals and some impractical-thinking ones, I often had a hard time not violating that rule. Thankfully, the team was never afraid to correct me when I tried to squash an incredibly impractical idea.

Few good requirements came out of these times when we were dealing with a brand-new product. But brainstorming the requirement of a new feature often proved fruitful.

Reverse Engineering: One time we were contracted to design the hardware and software for a medical product. It was a portable oxygen concentrator that pumped outside air through a sieve bed and extracted pure oxygen. Our customer was a startup with an interest in breaking into an existing and established market. They saw a product niche at a price point they thought they could meet, but had no idea what the specification should be for such a product. They had purchased the patent rights of an unsuccessful company and brought in the company’s product for analysis.

Our job was to elicit the requirements from an operational point of view. How long was each cycle? What settings did it allow the customer to change? And so on. We also examined it from a systems perspective. How many horsepower was the pump they were using? What materials did they use in their sieve bed. How many filters did they use?

Since we were trying to make a successful version of a working but unsuccessful product, reverse engineering proved to be an excellent way to elicit the requirements.

Interviews: Often, it is not possible to get a group together, and we need to conduct interviews with individuals, instead (Figure 4). In 2008, a CEO (the only employee at the time) and his investor came to us with an idea. I cannot remember if it was on a napkin—but there was not much to it. Over the next month or so, we conducted a lot of phone interviews with him to figure out what exactly he wanted. Over the many years of our relationship with him, we conducted countless interviews with him to nail down new systems and new requirements. Eventually, he sold the company of solar power monitoring for a lot of money. After that, we continued to conduct a host of interviews with his replacement. We probably saw the two of them less than a half a dozen times in the course of our 12-year relationship.

FIGURE 4
Interviews with individual users or experts can be conducted face-to-face or over the phone to help determine requirements.
FIGURE 4
Interviews with individual users or experts can be conducted face-to-face or over the phone to help determine requirements.

With another customer for whom we designed the hardware and software for an LVAD system (a left ventricular assist device for people with end-stage heart failure), we never saw him face to face. All requirements were gleaned through interviews. You can successfully elicit the requirements of complex systems just through interviews.`

The key to using interviews successfully is to record the minutes of all of them. If really significant, record the interview. You will be glad you did, should there be any downstream confusion as to what was said. At a minimum, the record should include decisions made, trade-offs discussed, and action items.

Focus Groups: Testing has always been an interest of mine, and when we couldn’t find the tool to test a product, we would make one of our own. We were a small development team, and often created products for millions of users. We always felt like our testing was inadequate.

In the recent app I am developing, I found a condition where once every 100 or so times that you stopped and started the playback of audio really fast, it would start two streams of audio. This is the kind of problem that is hard to identify and test. What if it only happened once every 10,000 times? I would never have found it. But with 100,000 customers it will happen too often. We wanted to design a tool that could pound away on a touch screen or keyboard thousands of times, fast and variably. We called it “Thumper” after the character in Bambi.

We felt we needed to get the experience of other engineers (the market target), so we held a series of informal focus groups. By informal, I mean that we didn’t follow all the focus group guidelines at the time. (The guidelines actually have changed and are now more in-line with what we did). Each session had three or four attendees We provided each of them with a preliminary specification and user manual. Overall, we only added two new requirements, but we felt the exercise was worth it. We would never have come up with those new requirements on our own

Prototyping: I will talk more in Part 2 about using prototyping to elicit requirements, but let me mention one unusual way to use prototyping that we employed in the past. After utilizing a “real” real-time operating system for the first 50,000 units, we converted a fleet of systems to Linux (before real-time extensions became part of the kernel). We had a requirement to read bar codes on ID badges swiped through the device. The timing requirements were such that we could not be sure how fast the swiping would be (based on how quickly an individual was swiping the badge), and whether Linux could keep up with it. So we provisionally put a dedicated PIC microcontroller in-line with the input; this gave us a backup, in case the Linux OS was unable to keep up and occasionally dropped swipes. Once Linux proved it didn’t drop swipes, the provisional PIC was dropped from the device.

Surveys: Many good survey tools can be useful for identifying the requirements when a large number of people can contribute usefully to elicit the requirements. Great care must be put into forming the questions. You will be contacting a lot of people (generally) through this method, and the information flow is usually only one direction. Avoid “yes” and “no” questions.

Workshops: In 1978, the company I worked for had designed two complete, separate devices that did exactly the same thing—controlling a machine that formed glass bottles (Figure 5). One device was entirely with 7400 TTL logic, and the other used mini-computers. One was sold exclusively in the US, and the other was sold throughout the rest of the world. It was decided to create a specification for a new microprocessor-based system that would be sold worldwide.

FIGURE 5
T-600 for sale in August, 2023. The requirements for this bottle-making machine, which was first produced in 1981, were developed via workshops held throughout the world.
FIGURE 5
T-600 for sale in August, 2023. The requirements for this bottle-making machine, which was first produced in 1981, were developed via workshops held throughout the world.

About every 4 months over the course of about 2 years, we held 3-day workshops around the globe, with engineers and marketing folks. Every detail of the system was hammered out in a requirements specification out of those meetings.

Released in 1981, these systems continue to make glass bottles well in the 21st century [3]. I am convinced that the key to the success and longevity of this product was the time we spent working through the details of the requirements with three different engineering teams (with different languages) from three different countries.

Interface Analysis: Increasingly in my experience, the systems we designed interfaced with other smart devices (with software inside). Obviously, that was not an issue in the 1970s. Often now, however, most of the requirements do not revolve around the user interface, but rather, around the devices our device interfaces with. A thorough understanding and analysis of these interfaces is often the backbone of any requirements specification.

Patent Search: Theoretically, a patent should disclose enough information so that you can replicate the device from what is written. Reverse engineering this information can uncover a treasure trove of requirements that can help you specify your device. But it can also do so in a way that will not infringe upon the patent. Today, patent searches are free and done easily and quickly [4]. We are a long way from when I used to go to the library in New York and plow through microfiche—time consuming and costly. Only slightly better was going to a local library and using CompuServe. Now, all US and many foreign patents are available on the Internet. If you are not using this to glean requirements for your project, you are missing out.

Stakeholder Analysis: In 2008, I organized a team to determine the new use of a piece of property our church owned. One of the men on the team was a VP at Lego. He kept saying that we needed to identify all the stakeholders involved. I had no idea what he was talking about. Basically, in eliciting the requirements for your next project, this technique involves identifying everyone who has a stake or interest in the project and determining how they want the device to work.

Re-use of Existing Requirements: The simplest method of eliciting requirements is to say, “The same as [XXX] with these differences…” In my 50 years of designing embedded systems, we did this countless times. Of the many successful systems we designed, there were many spin-offs, sometimes with our own products, and sometimes with other people’s products.

CONCLUSION

One suggestion concerning documentation: Write your requirements documents with success in mind. Assume that there will be a sequel or spin-off. If you are using a Microsoft Word document to document your specification, make liberal use of the Word equivalent of variable names—where the widget name can be changed in one place and replaced everywhere—where formulas can be embedded so that the specification can be easily scaled, larger or smaller, faster or slower.

These are just some of the ways to elicit requirements for your next project. Now that you have a grasp of what the requirements are, for heaven’s sake, write them down! In Part 2, we will look at some problems in using these methods, and propose an alternative that will be useful in some scenarios. Of course, only in thin slices. 

REFERENCES
[1] “How to Write a Software Requirements Specification” https://microtoolsinc.com/papers/how-srs/
[2]  https://www.functionize.com/blog/the-cost-of-finding-bugs-later-in-the-sdlc A good article about the cost to fix a bug late in the software life cycle. Figure 2 data is from this article.
Note: The most obscure place this white paper was referenced was in July, 2023 in an article in Homeland Security Today, entitled, “Meeting the Challenges of Ukraine’s Recovery – Business as Usual? Absolutely Not!” https://www.hstoday.us/industry/industry-news/perspective-meeting-the-challenges-of-ukraines-recovery-business-as-usual-absolutely-not/
[3]  The website www.GlassMachines.com shows used computer controls for sale that we specified in these workshops in the late 70’s, 43 years after they were first deployed! https://www.glassmachines.com/emhart_t_600_v_lan_timing_system_t_600_ets_cimog_epro_for_is_machine_glass_forming_machine-5147.html
[4] United States Patent and Trademark Office – https://www.uspto.gov/ If you don’t know how to search patents, the USPTO’s 38-minute tutorial is well worth watching.

SOURCES
Risk Assessment Framework (RAF). International Journal of Advanced Research in Computer Science. Vol. 01. Pandey, S. K. and Mustafa, K. 2010. pp. 423-432. http://www.ijarcs.info/index.php/Ijarcs/article/view/131

RESOURCES
React Native | reactnative.dev

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2023 #401 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.


Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
+ posts

Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org

Supporting Companies

Upcoming Events


Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

Eliciting Software Requirements for Embedded Systems

by Bob Japenga time to read: 10 min