organization that has commissioned the software, to correct shortcomings of existing software, to control a device, and many more. The functioning of users,business processes, and devices is typically complex. By extension, therefore,the equirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.
An essential property of all software requirements is that they be verifiable. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on the call center may necessitate the development of simulation software. Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.
Product and Process Requirements
A distinction can be drawn between product parameters and process parameters. Product parameters are requirements on software to be developed (for example,
“The software shall verify that a student meets all prerequisites before he or she registers for a course.”).A process parameter is essentially a constraint on the
development of the software (for example, “The software shall be written in Ada.”). These are sometimes known as process requirements.
Some software requirements generate implicit process requirements. The choice of verification technique is one example. Another might be the use of particularly
rigorous analysis techniques (such as formal specification methods) to reduce faults which can lead to inadequate reliability. Process requirements may also be imposed
directly by the development organization, their customer,or a third party such as a safety regulator [Kot00; Som97].
Functional and Nonfunctional Requirements
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as
capabilities.Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.
They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability
requirements, or one of many other types of software requirements. These topics are also discussed in the Software Quality KA. [Kot00; Som97].
Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system,
information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture. [Som05]