2

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 ?

  • 1
    I don't see any problem with the former example. I have a feeling that you might be confusing software units with units of measurement. – Revenant Oct 6 '16 at 9:38
  • 3
    Any software that deals with physics had better address physical units. Those who don't have crashed spacecraft into Mars. Note that DO-178 does not apply to spacecraft flying to Mars. – David Hammen Oct 6 '16 at 17:07
  • If specific units of measure are critical to the software, then they need to be in the specification. There's no reason why you can't test that. Would you be willing to drive a car with software-controlled engine components that weren't tested to exact specifications? – Bryan Oakley Oct 6 '16 at 17:20
  • 1
    Given that much of the hardware hasn't even been finalized when software is being designed in most projects I've been on involving embedded and aerospace systems then it would be kind of hard to write the requirements how your colleague is claiming they should be written. The requirements shouldn't change because your program increased the CPU speed or switched to a different ADC chip. Also, your software better know about volts and milliseconds otherwise you'll have a lot more issues when that ADC goes obsolete and you're software is passing around 1502 for the voltage reading. – Dunk Oct 6 '16 at 22:22
5

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.

  • @efox29 I've edited this answer to address both a general case and the DO-178 case. Let me know if you think it needs additional information or clarification. – Thomas Owens Oct 6 '16 at 16:29
  • I think the answer is clear. I'll read it over a few times and I'll show my colleague. He may have some comments, which might make this answer even better if those questions are addressed. Give me about a week, and I'll mark this as the answer (unless someone else jumps in). – efox29 Oct 6 '16 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.