Last updated on January 2nd, 2019 at 06:30 pm
It seems like everywhere, everyone bandies-about the phrase “business requirements.” Yet, if one pays attention, one might get the idea that the phrase is applied in any and every context wherein the speaker wants to apply some level of mandate to his or her “wishes” without actually appearing selfish.
Case in point: we often hear technical people referring to the need to implement functionality or solutions provided by their technology as “meeting business requirements.” As in “Using this server is a business requirement.”
But isn’t functionality a solution? How can solutions be the same as business requirements?
Business Requirements Defined
Business Requirements are requirements on the business, not requirements for a [technical] solution used by the business. Business Requirements are what must be delivered/achieved to provide value.
Business requirements originate externally, and are imposed upon a business by the customer; Business Requirements reflect what the customer pays to have accomplished. (Or are mandates from government.) They are NOT defined nor developed within the business.
They originate externally and are mandates to the receiving organization. Business Requirements are the high-level vehicle by which organizations are tasked, and are the basis for the organization’s mission. Examples of Business Requirements are: laws, regulations, environmental and political mandates, and last but not least, customer needs (in which, are buried the customer “requirements.”)
Money follows the Business requirements, and is allocated as compensation for accomplishing the requirements; or saying this the other way around, implementing requirements costs money, and is paid for by the customer. (Even if the requirements did not originated with the customer.)
Then There Are Design Requirements
SO…then what are the requirements that are developed within the organization? The ones that directly drive selection of solutions?
These are Design Requirements; also known as process or functional requirements.
Design Requirements originate internally with the business-line (or business process) owners charged with delivering value based on the Business Requirements. Design Requirements are the intermediate step that translates Business Requirements into functional solutions. (Note: “functional solutions,” not “technical solutions.”)
Design Requirements specify (or mandate) what people, process and information must do (together) to accomplish the Business Requirements. That is, the Design Requirements “connect the dots” between the Business Requirements and what people will do with information, and how they’ll do it, to meet those Business Requirements.
These requirements are the next level of abstraction underneath the Business Requirements, and serve to implement each Business Requirement: One or more Design Requirements implement each Business Requirement.
Design Requirements originate internally with the business-line owners as an intermediate step to design how the organization will meet the Business Requirements. The Design Requirements typically result in an organization’s goal and objectives; that is, the goal and objective are a statement resulting from the Design Requirements.
Then, when the people, process, and information solutions are designed, we can think about how we might add efficiency with technology.
But that’s another post…