I am new to the software design lifecycle and the various processes that it consists of. I was taught/told recently that units should not be included in the SDD because the software cannot "test" those requirements because units do not mean anything in the software domain.
An example of this could be..
"..shall…occur within 100ms" or
"..shall..be within 2.5 volts and 6.4 volts"
The argument is that the software when doing unit testing, cannot measure time, and therefore requirements in the SDD cannot have units. Similarily, if you are using an analog to digital converter (ADC), the software does not know about volts, it only knows the value the ADC has converted.
So the examples above should be changed to…
"..shall…occur within 40 counts" or
"..shall..be within 1304 and 2041"
Since this is a new area for me, I would like to know how different industries would handle the SDD (in a general sense) and if units should be included in SDDs. This may be automotive, or consumer markets.
My current industry is aerospace, so we follow DO-178.
Does the same answer still apply to more regulated industries such as Aerospace ?
Best Answer
First, I want to normalize on terms.
The ISO and IEEE standards refer to Software Requirements Specifications (SRS), Architecture Description, and Software Design Description (SDD), which may be in any format (databases, wikis, electronic documents, handwritten pages). An SRS identifies the information needs to consider when capturing requirements (functional and non-functional/quality attributes) for building or buying software. An architecture description defines viewpoints, frameworks, and architectural description languages for systems (which may or may not include software). An SDD contains representations of software design models and rationale for one or more stakeholders and guidance for the use of design languages.
DO-178 uses a different set of terminology. System requirements are the technical requirements for the system being built1. The system requirements are decomposed into the high-level requirements, which are a set of block-box requirements for the software. The high-level requirements are used to create the software architecture and the low-level requirements, which also inform each other. The architecture and low-level requirements capture design constraints, input and output definitions, data and control flows, resource management, and design rationale. The architecture and low-level requirements are used to create source code.
We also need to consider the characteristics of good requirements. Requirements need to be complete (the information is together in one place), unambiguous (concisely stated without excess words and subject to only one interpretation), and verifiable (the implementation of the requirement can be confirmed by inspection, demonstration, instrumentation, test, and/or analysis).
Now that we have defined some the key terms, we can look at the issue at hand: should software requirements contain units?
Generally speaking, yes, requirements should contain units. This is necessary to have requirements that are complete and unambiguous. These units provide information to designers and testing. For designers, they gain context of the system. It may inform the decisions regarding input and output, of both public and private interfaces. Testers also gain a clear understanding of what valid inputs are, at all levels, from system level to unit level.
In the ISO/IEEE world, in addition guidance associated with complete and unambiguous requirements in an SRS, an SDD often contains a data dictionary. A data dictionary will contain information about the source of data, the format the data comes in, and the usage. If the data is representing something that can be measured, things like valid ranges, units, and error ranges will often be specified in the data dictionary.
In the DO-178 world, the system and high-level requirements will almost always contain units. These units will map to the system, subsystem, and integration tests that are conducted. The best description of working with high-level requirements and low-level requirements that I've read was that high-level requirements are a description of what you are designing and implementing, while the low-level requirements provide specific instructions on how to design and implement. Because a key point of DO-178 is traceability from the system requirements all the way to the bytecode (especially at Levels A and B), your low level requirements will be less likely to contain units, but rather talk about methods, inputs, and outputs with respect to what different variables represent.
1This is from the organization's perspective, so an example of a system would be an air management system. From the perspective of the aircraft integrator or manufacturer, the air management system is a subsystem of the aircraft. To the organization making the air management system, it is a system with subsystems and components, some of which may be software.