Mastering the embedded software design cycle
Each of these topic areas are unto themselves a vast reservoir of information for developing not just embedded software but software in general. The IEEE Computer Society has developed as part of their Certified Software Development Professional (CDSP) program a Software Engineering Body of Knowledge (SWEBOK) that includes a vast wealth of information on developing software including these five areas of the design cycle. Version 3 of the SWEBOK was released earlier this year and can be downloaded in a PDF format for free.
This article provides the briefest introduction to each of these areas of the design cycle. For more information beyond what it provides, check out the free five session Design News Continuing Education Course “Mastering the Embedded Software Design Cycle” that can be found in their course archive.
Some useful templates that the author has used and modified over the years for requirements specification and traceability, test case development and more can also be found here.
Gathering and properly documenting requirements is probably one of the critical steps of any development process. If a team doesn’t know what it is they are building then right off the bat they are destined for failure. Requirements can be defined in a number of ways but a good general definition is that a requirement is a property that must be exhibited by software to solve a particular problem. Just like anything in life, requirement are a bit more complicated than that definition because they can come in at two different flavors; functional and non-functional.
A functional requirement describes the behavior that software is to exhibit. What is meant by this is that a functional requirement is really a capability of the software. The ability to modulate a PWM signal, communicate on an I2C bus, dispense a warm slice of pizza, etc, are all functional requirements.
Non-functional requirements on the other hand are requirements that constrain the solution. They aren’t focused on a capability of the system but how that capability may be restrained. These types of requirements generally are oriented towards system performance, maintainability and so on and so forth. An example might be something like:
The system shall spend 70% of available computing time in sleep modeThere are many different ways to go about recording and maintaining requirements whether it is in a web based systems or a simple document. In either event, the use of a Software Requirements Specification (SRS) can be an extremely useful tool for documenting requirements. An SRS is used to state the requirements in technical terms that an engineering team would understand and not in language that the end client would necessarily be able to understand.