Eliciting Software Requirements for Embedded Systems Part 2

Part 2: An Agile Approach

In the second of this two-part series on eliciting software requirements for embedded systems, Bob looks at the Agile software development process. He discusses some problems in using the methods discussed in Part 1 of the series, and proposes an alternative that will be useful for the elicitation of requirements for embedded systems in certain scenarios—in particular, adding requirements late in projects.

Several years ago, my company MicroTools, a design and development business for embedded systems, developed the hardware and software for a wearable oxygen concentrator. These are used to provide supplemental oxygen to individuals with COPD, congestive heart failure, and other conditions. We had previously developed the hardware and software for a portable (but not wearable) version. Low cost was a critical requirement for this new product.

Early on, a requirement was proposed to interface to a pulse oximeter (Figure 1), which would read the user’s blood oxygen (O₂) levels and adjust the flow accordingly. The range of oximeter interfaces was significant. At the time, no other device did this. The lowest recurring cost was to interface with the raw sensor, and then license the proprietary and patented software to interface with the sensor. The highest recurring cost would be to interface with a complete oximeter and obtain the O₂ readings over a serial interface.

At the requirements stage, we needed to decide whether we wanted this feature and if so, which method? If we didn’t have this detail nailed right up front, should we provision on the board the three types of interfaces (serial, USB, and proprietary)? Should we provision for the extra memory needed to implement that proprietary library (which was four times the size of our previous device’s memory consumption)? Should we provision for the connector to the pulse oximeter in the plastic housing?

I hope you can see the problems the hardware and software designer faced. Imagine the product manager adding this requirement after the plastic molds had been designed. Adding it late in the life-cycle would have been disastrous.

Are there other ideas from Agile that can help us develop better embedded devices more quickly? Let’s first look at Agile.

WHAT IS AGILE?

The Agile software methodology is used for managing projects and developing software. There are several different frameworks within Agile. Companies adopt and adapt the frameworks that work best for them. Since it was primarily developed for the IT world, some have attempted to apply Agile to embedded systems development. Often contrasted with the “Waterfall” model for the software development life cycle (Figure 2), this methodology has quickly gained acceptance across a wide body of disciplines. In fact, some claim that one or more of the Agile frameworks is used by 71% of US companies [1]. But is it applicable to the development of embedded software systems requirements?

First, let me define the “Waterfall” methodology, which is what I used for most of my career. Shown simplistically in Figure 2, one starts with eliciting the requirements, then proceeds to create a design. Next, the design is implemented in code. Finally, the code is tested and verified. Once released, the final phase is maintaining what was released. Usually there is some overlap between these phases, where some implementing happens before the design is complete. Also, some verification can take place before the implementation is complete, and so forth.

Two other methodologies that my company used were developed prior to the Agile methodology. These are the Spiral methodology (Figure 3) and the Prototyping methodology (Figure 4). You can think of the Spiral framework as the Waterfall repeated a number of times: Define; Design; Implement; Verify; Rinse, and Repeat. We used the Spiral methodology when the customer was unsure of the requirements. We usually broke the project into three or four phases (spirals), with a release to the customer at the end of each circle.

In contrast, the Prototyping methodology is an attempt to get a prototype into the customer’s hands as quickly as possible.

For example, in 2008, my company was hired to create a smart electric meter. The previous designers had been fumbling and bumbling for over a year with nothing to show. Using off-the-shelf parts, we put together a working prototype within 2 months.

That prototype was modified and released to production, even though we knew we were leaving money on the table with the off-the-shelf parts. Within weeks of the release of the prototype, we moved into the phase of designing out all the off-the-shelf parts, while keeping the software the same. This methodology created a highly successful product for the customer.

Agile methodologies were developed at the end of the last millennium from various iterative and incremental methodologies too numerous to mention. The Agile approach attempts to deliver the software in useful increments. The expectation is that by continuous verification of the requirements, the design, and the implementation, the end result will be obtained more quickly and with better quality.

Agile was popularized by the 2001 Agile Manifesto (Table 1) that came out of a meeting of 17 developers who were proponents of different iterative and incremental methodologies [2]. The principles behind this are defined in Table 2.

HOW DOES AGILE STACK UP NOW?

What is the status of Agile more than 20 years later? I love that the mediated Wikipedia puts it this way:

“While there is much anecdotal evidence that adopting agile practices and values improves the effectiveness of software professionals, teams and organizations, the empirical evidence is mixed and hard to find.” [3]

I love that it’s from Wikipedia, because if there were some empirical evidence of Agile’s improved effectiveness, an Agile evangelist would have modified Wikipedia and put in the link. In the words of Jack Ganssle, who publishes the Embedded Muse to over 40,000 embedded designers:

“Many of the practices are brilliant. Some are daft, at least in the context of writing embedded firmware.” [4]

In embedded systems, some requirements cannot be tested until you have released a production board with production hardware. Cell modem testing is like that, when testing either to requirements for Verizon, AT&T, or PTCRB (the certification forum by select North American cellular operators) [5].

In discussing software methodologies, we have to keep in mind something I have paraphrased from Fred Brooks in his book, The Mythical Man-Month [6]: “There are no silver bullets in software methodologies.” They are all, in my opinion, equally problematic.

CAN AGILE HELP US IN REQUIREMENTS ELICITATION?

All right already, Bob. You said that Agile could help us better elicit software requirements. So, how can Agile help us in requirement elicitation? I contend that the idea of incremental development of software is brilliant. I am not as convinced about how many incremental releases to the customer we can tolerate in the embedded world, nor do I believe that we can create a methodology that would allow requirement changes late in an embedded project. I can see how it works in IT and web development. I use it all the time in web development. From the very start, I am doing incremental releases more than once a week. And the concept of a range of viability of the product requirements is also extremely valuable in requirement elicitation. However, incremental requirements elicitation is deadly. I still believe that you must define up front all the requirements that you know of, or the embedded designer is hamstrung.

What I really like from the Agile methodology is the idea of defining the requirements for a minimal viable product (MVP). But I take it a step further—not just one MVP, and not just viability. I would rank them by cost and risk.

I like the idea of prioritizing the requirements under a series of tiers, from the minimal viable product to the completely desired product. I believe this is worthwhile and very helpful to the software designer. In other words, get all the possible requirements up front, using the techniques I discussed in Part 1 of this article series (“Part 1: Conventional Methods,” Circuit Cellar 401, December 2023) [7]. Get all the stakeholders to rate them in terms of viability for the project, risk in development, and cost in dollars and schedule. Then, as a team, create a development plan for designing, implementing, and testing these. Table 3 shows how this prioritization was used in one little project of mine.

Looking at Table 3, you can see how by ranking the Viability (“Is this minimally needed?”), Risk, and Cost, you can learn a lot. For example, the item “Cloud Configurable by the User” may not be risky or cost a lot, so we can implement it later. But meanwhile, designing the software while knowing that this requirement exists is essential for efficiency. It would be costly not to have that defined upfront. “Synch Text with the Audio” is nice to have, but isn’t absolutely necessary, and it is costly. So let’s take it out of the specs.

From the designer’s standpoint, we need to implement the highest risk requirements first. Agile’s push to create a relentless stream of releases will encourage leaving the hardest for last. In my case, I knew that the remote control was the most risky of all my tasks, so I should have implemented it first. Thank you Agile development for helping me improve my software development methodology!

CONCLUSION

I suspect that Agile methodology will continue to work well in some environments. But we need to be wary of using all of it in embedded software development. That said, the idea of specifying a Minimum Viable Product and rating each requirement for viability, risk, and cost can create a better project plan and better project implementation.

My next article will be the first in a series, “An Embedded Software Designer Dips His Toes into App Design”—only his toes, because this is in thin slices! In this series, I will discuss the advantages of Flutter [8] and React Native [9] versus creating Android and iOS native apps. 

RESOURCES
MicroTools Inc | microtoolsinc.com

REFERENCES
[1] Sixteen Amazing Agile Statistics 2023: What Companies Use Agile Methodology: https://www.zippia.com/advice/agile-statistics/
[2] The Agile Manifesto: https://agilemanifesto.org
[3] Wikipedia article on “Agile Software Development:” https://en.wikipedia.org/wiki/Agile_software_development
[4] I strongly recommend that you subscribe to the Embedded Muse (hardware and software tips about building embedded systems): http://www.ganssle.com/tem-subunsub.html
[5] For more about PTCRB, see the agency in charge of this testing: https://www.ptcrb.com/
[6] A “must read” for all software engineers: Frederick Brooks, Jr. 1995. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional. https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959
[7] Bob Japenga, “Eliciting Software Requirements for Embedded Systems: Part 1: Conventional Methods.” Circuit Cellar 401, December 2023.
[8] Check out what you can do with Flutter—an open source framework by Google for building natively compiled, multi-platform applications from a single codebase: https://flutter.dev/
[9] React Native—a JavaScript library for building user interfaces. Learn one tool chain and run anywhere (Web, Android and iOS): https://reactnative.dev/

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • FEBRUARY 2024 #403 – Get a PDF of the issue

Sponsor this Article