Software Development Management, Part 2, Software Requirements
Compound Software Requirements, Software Requirements, Software Requirements and Specifications
In a previous Device Tip, I mentioned that in my experience, far and away the area with the most issues in software development is Software Requirements and Specifications. In previous Device Tips I discussed Requirements and Specifications in more detail, so I will not repeat them in this Device Tip. What this Device Tip will focus on is to parse potentially compound Software Requirements into discrete, more easily verifiable Requirements that follow the potential or likely design and/or implementation.
Compound Software Requirements are those that combine multiple individual Requirements into a single statement, such as “the Software shall detect a High Temperature alarm if the temperature is above 50C and shut off the heater and sound the audible alarm”. On the surface this is easily seen as (3) Requirements, but in fact implies (5) separate software functions:
- measure the temperature
- compare it to a limit
- if over the limit, declare an alarm state
- turn off the heater, and
- sound the audible alarm
It also suggests at least (2) other software functions:
- setting the temperature limit
- temporarily or permanently silencing the audible alarm
It is also likely that in the software design and/or implementation these (5) or (7) functions will be handled by different functions in the software. So it will be easier to test these functions separately rather than together.
So here’s the tip:
When developing Software Requirements, look for the following potential functions that software might perform with respect to a given overall set of actions
- set a limit
- measure a value
- compare a measured value to a limit
- if over or under a limit, transition to a new state
- when transitioning to a new state, perform some action (turn something ON or OFF, start or stop an action, etc.)
- provide an audible or visible enunciation of a particular condition or state
- allow specific audible or visible enunciation to be temporarily or permanently disabled
If separate Software Requirements are written for each of these more specific functions, verification will be significantly easier. Also, once the sub-functions are verified, if the software design and implementation is well partitioned to allow these sub-functions to be used by multiple higher level functions, verification of the sub-functions can be re-used as part of verification of other higher level functions that use those same sub-functions.
More Info On Software Requirments
Smaller, specific Requirements are often referred to as ‘atomic’ Requirements. Correspondingly, compound Requirements can be referred to as ‘molecular’ Requirements. Say you have a molecular Software Requirement:
“The Software shall detect a High Temperature alarm if the temperature is above the User-specified High Temperature Limit and shut off the heater and sound the audible alarm”.
The atomic Software Requirements would be:
- The Software shall allow the User to set a High Temperature Limit
- The Software shall measure the internal unit temperature
- The Software shall compare the measured internal unit temperature to the High Temperature Limit on each reading of the internal unit temperature
- The Software shall set a High Temperature state if the measured internal unit temperature is above the High Temperature Limit.
- The Software shall shut off the heater in the High Temperature state.
- The Software shall provide an audible alarm every second in the High Temperature state.
- The Software shall temporarily silence the audible High Temperature alarm for one minute after the Alarm Silence button is pressed.
Here are some of the benefits of specifying these Software Requirements atomically:
- The design and implementation of each atomic requirement is clear (read easier)
- Other molecular Software Requirements can be derived using some of these atomic Software Requirements (such as measuring the internal unit temperature)
- Other atomic Requirements (such as Hardware Requirements) can be derived (i.e. the Hardware shall allow the internal unit temperature to be measured)
- These atomic Software Requirements are able to be verified with clear and straightforward tests
- Once these atomic Software Requirements have been verified, associated molecular Software Requirements are much more likely to work correctly
- When molecular Software Requirements are not working correctly, troubleshooting will likely end up determining which atomic Software Requirement(s) are not working correctly, and then determining why so they can be corrected.
In the end, even the most complex requirements will end up being specified, designed, implemented and often verified atomically.
P.S.: once again, special thanks for Keith Breton of New Frontiers Software for his valuable contributions to this Device Tip including the term ‘atomic Software Requirements’. -BD