Demystifying Business Requirements

In a previous article, we compared and contrasted the definition of a requirement, with a ‘story’, which is used in agile/scrum. In that article, we stated: “requirements and stories establish a clear understanding of customer needs in the context of desired functionality”.

What if we want to establish a clear understanding of a customer’s needs in the context of desired business functionality? The customer can be an internal or external customer, business functionality can be a business process (IT-enabled or otherwise).

Also recall the definition of a requirement: A requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”.

Let’s start with a new business process….an example would be to get a supplier-provided part to the warehouse, and then to the manufacturing shop floor:

It can be seen that a business requirement is:

“Procurement shall provide supplier parts to the warehouse on or before the order fulfillment date as determined by material planning, using suppliers selected by sourcing”

(It’s important to remember we’re designing a new business process in this example, not troubleshooting an existing one…)

Arguably, there are organizational design constraints embedded in this requirement, since the input organizations (material planning, sourcing) are defined. Regardless, this requirement statement can be validated by each department leader, and the architecture/design (how the requirement will be met) can be determined by asking the following fundamental questions:

• Is the output measurable (at the warehouse)? We will want to know the actual performance relative to the requirement (on or before the order fulfillment date).
• Is the supplier’s order fulfillment date mutually understood and agreed by both the supplier and material planning?
• Does sourcing acknowledge they are responsible for selecting suppliers that are able to fulfill orders as scheduled?
• Does material planning acknowledge they are responsible for order fulfillment dates that are accurate, realistic and unambiguous?
• Are the inputs measurable (supplier performance, material planning performance)?
• Who is accountable? How are resource constraints or skillsets in each of the departments effectively managed? What is the best reporting structure to enable this?
• How can the business requirement be met with a minimal amount cost?

It is also apparent some enterprise resource planning IT-system requirements and stories can be derived from the business requirement and detailed information flow processes.

This article demonstrates (1) how a business process comes first and (2) how business requirements can be developed based on internal/external customer needs and (3) how lower-level business, organizational, key performance indicators, and IT system requirements can be derived.

Well-written business requirements can proactively ensure an efficient business process and IT enablement.