Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.
Three main reasons for such discussions:
A common practice is to refer to objectives, or expected benefits, as 'business requirements.'
People commonly use the term 'requirements' to describe the features of the product, system, software expected to be created.
A widely held model claims that these two types of requirements differ only in their level of detail or abstraction — wherein 'business requirements' are high-level, frequently vague, and decompose into the detailed product, system, or software requirements.
To Goldsmith, Robin F, such are confusions that can be avoided by recognizing that business requirements are not objectives, but rather meet objectives (i.e., provide value) when satisfied. Business requirements whats do not decompose into product/system/software requirement hows. Rather, products and their requirements represent a response to business requirements — presumably, how to satisfy what. Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified). Business requirements are not limited to high-level existence, but need to be driven down to detail. Regardless of their level of detail, however, business requirements are always business deliverable whats that provide value when satisfied; driving them down to detail never turns business requirements into product requirements.
In system or software development projects, business requirements usually require authority from stakeholders. This typically leads to the creation or updating of a product, system, or software.