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.