including the environment the system must operate in, also influence the requirementsspecification.Once the system is conceptually broken up into a set of interacting elements, theprocess of requirements decomposition (or derivation) begins. Some of the higher-levelrequirements will be implemented in whole by a particular element. Otherrequirements will be partitioned between several components. The process ofrequirements decomposition continues as the system is further sub-divided, until thelowest practical level is reached. The stopping point for requirement decomposition willvary across systems. For systems with complex electronic devices, a separaterequirements document for the complex electronics is preferred. In reality, only themost critical devices have requirements separate from a higher-level assembly.Requirements can also be classified by the role they play in the system. Thisclassification will vary, depending on the organization or project. The following list ofrequirements types is commonly used in many government organizations.
requirements describe the capabilities of the product or system (whatthe system must do).
requirements describe how well the product or system mustperform a function. Performance requirements complement the functionalrequirements, and these are sometimes combined into single requirements.
requirements specify how the system will interact or interoperate withan adjacent system.
Safety, Quality, Reliability, Maintainability, etc. (the “ilities”)
this set of
requirements relate to overarching system questions, such as “how long will itwork without breaking” and “can it hurt me”. Some “ility”
requirements can bedecomposed into specific functional and performance requirements. Othersessentially put constraints on the design, implementation, manufacturing, orproduction processes.
requirements are a limitation that a product or system must staywithin.