Business requirements

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Business requirements" – news · newspapers · books · scholar · JSTOR (February 2012) (Learn how and when to remove this message)

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:

1. A common practice is to refer to objectives, or expected benefits, as 'business requirements.' ^[1]
2. People commonly use the term 'requirements' to describe the features of the product, system, software expected to be created.
3. 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.^[2]

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. The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business requirements which are sometimes considered constraints. These could include necessary performance, security, or safety aspects that apply at a business level.

Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on process or activity of accurately accessing planning and development of the requirements, rather than on how to achieve it; this is usually delegated to a Systems Requirements Specification or Document (SRS or SRD), or other variation such as a Functional Specification Document. Confusion can arise between a BRD and a SRD when the distinction between business requirements and system requirements is disregarded. Consequently, many BRDs actually describe requirements of a product, system, or software.