Business requirements are derived from the needs of the business; a good business analyst will recognize that they’re the things that must be in place to benefit the business or enterprise as a whole. They characterize and quantify outcomes desired for the business, and document what business the business decides to be in, what products the business will offer, or what markets the business will expand into or exit.
At a project level, business requirements also include the reasons and objectives for the project, as well as the success measures and metrics that the project team will be held accountable to. All these requirements should be stated from a business perspective — that is, not specific to any one stakeholder but rather from the overall business view.
Stakeholders often offer much more than just business requirements even if that’s all you’re eliciting from them. They may also provide stakeholder requirements, solution ideas, solution requirements, technology suggestions, and transition needs, so your challenge is being able to successfully peel apart that onion and identify which category each statement really belongs to.
Distinguishing between an idea or suggestion and a truly decided-upon requirement that the team or solution will be held to support is especially important.
This overload is the primary source for scope creep (when projects inch out of their previously determined boundaries). Stakeholders frequently see opportunity in every new development effort and may load up on “requirements” that they just “must have,” though those opportunities may fall outside the scope of the project objectives. You may need to capture all these requirements but then defer their consideration to a later time.
