How to Define Requirements through Business Analysis

Needs and requirements may look like they mean the same thing, but there’s a difference when it comes to business analysis: The need is the objective, and the requirement is the decision about whether to do something to achieve that objective. A need turns into a requirement when someone recognizes that having the unmet need is unacceptable and decides he requires the need to be met.

Requirements, when first identified, are really needs, wants, suggestions, or ideas — until the right person decides otherwise. Frequently, needs, wants, suggestions, and ideas are presented as requirements statements without the provider’s thinking about the needs, constraints, or implications of that decision; sometimes, he’s not even in the position to decide how or why the requirement is appropriate or necessary.

Decisions are made by someone for a reason. Capture and note which someone makes which decisions about specific requirements, and when.

As you’ve probably realized, the word requirement is a very vague term in the business analysis world. As a result, the official definition of a requirement listed in the BABOK Guide (as specified by the IIBA — the International Institute of Business Analysis) follows:

• “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” This point reflects the pivotal decision-making necessary in business.

• “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.” This part shifts the focus from the stakeholder to the solution.

• “A documented representation of a condition or capability as in 1 or 2.” This idea notes that the documentation about requirements is also called a requirement. That’s because documentation helps analysts, different stakeholders, or documentation consumers (the people reading and interpreting the documentation) understand the requirements for the solution along with any components they’re responsible for creating.

  Because creators of the solution components must adhere to the requirements while developing, the documentation itself becomes a requirement.

Requirements fall into different, layered categories. The primary categories include business requirements, stakeholder requirements, solution requirements, transition requirements, and technology requirements. Solution requirements include functional and nonfunctional requirements created either by hand or with technology (which has its own technical requirements). And when complete, the solutions are put into place by way of transition requirements.

Credit: Illustration by Wiley, Composition Services Graphics

Going straight from a business requirement directly to a detailed technical requirement isn’t possible. You must cascade through each layer or level of analysis as appropriate, cataloging and categorizing as you go.

You and your team aren’t just supposed to design any solution at the end of all this cascading through the levels; you’re supposed to use the requirements to design a successful solution. You must probe deeply enough to elicit all the necessary requirements; otherwise, you risk missing some requirements.

You can reuse documented requirements (and needs, for that matter) at the business and stakeholder (and sometimes the solution) levels! Reused requirements can save project teams and stakeholders time and money. You should organize and save your requirements from your projects (perhaps in an enterprise repository or centralized requirements-reference place) in case you want to use them again on another project.

Requirements that were once to-be requirements (for the future business environment) can become your as-is requirements (for the current business environment) and provide a new starting point for the next project.

Just one missing requirement can cause problems with the stakeholders and team members and can also affect the solution(s) you build. The solution may be lacking or costly, create ongoing quality or support concerns, suffer buggy or failing interfaces, put downstream systems in jeopardy, and result in systems that are (more) difficult to support, causing manual work-arounds or additional processes.

These challenges can hurt user and customer satisfaction and business outcomes, which may result in decreased sales and an impact to revenue.