One of the advantages being a facilitator for business analysis professionals is that I get to see real-world concerns from working BAs every day…and I get to figure out creative ways to answer their questions. Recently, a student and I were were discussing levels of requirements, and what makes up a business requirement. Just because the requirements comes from the business, doesn’t make it a business requirement.
It was during this discussion on business requirements a student asked about requirements to use SAP or Oracle or a certain type of system as a business requirement. The student expressed concern about the requirement coming from the business was one they had to account for in the business requirements document. The actual requirement was something to the effect of “the business requested we use SAP to log payments” Technically, according to the Business Analysis Body Of Knowledge (BABOK), a business requirement is defined as “…higher-level statements of the goals, objectives, or needs of the enterprise…” Based on this definition, the business defining SAP as a requirement does not fit. It is not a goal or objective. The need comes in the reason behind the request to use SAP. It could be the business wants all payments on a central platform because they are experiencing duplicate (and error-filled) data and want to reduce it. But SAP becomes a solution and where it’s really categorized is as a constraint. It’s a limitation imposed upon the solution you create within business analysis to solve the problem or achieve an objective.
I used an example from IKEA to illustrate. There’s a big sign in the store that says the “…designers create the price tag first.” Why? The thought is they constrain the solution to fit into that price target. Their business goal is make the furniture affordable. The price tag constrains the solutions to fit within a certain budget. So IKEA says, “We need to increase our sales of outdoor furniture” as an objective (they will further put metrics to make the objective SMART, but that’s for another blog). The first thing they do is figure out the profitability surrounding an outdoor chair, and then create the price tag. By constraining the price, the designer has to work within the boundaries of the price, and while he/she may want to use the finest Swedish wicker on the chair, that design choice is too costly to fit within the constraint given at the beginning.
So whether it’s a price tag handed over to you, or a limitation on the design, the business may be handing you constraints along the way to which you have to react. While you can certainly question the constraint to understand the motivation or reasons behind it, just understand that a Requirement from the Business is not necessarily a Business Requirement.
- A Requirement from the Business May Not Be a Business Requirement - May 13, 2013
- My Time is Up! Time to Re-certify my CBAP! - April 8, 2013
- “Yeah…but so what?” - March 11, 2013
- When Did Process Improvement Start? - March 5, 2013
- Email: Help or Hindrance? - January 29, 2013
- Good BAs Define Requirements for Orange Juice - September 4, 2012
- Why Use Business Analysis Templates at All? - August 20, 2012
- When is Analysis Complete? When You’re Finished! - June 18, 2012
- Attack of the Conflicting Business Rules - May 17, 2012
- Interface Analysis – it’s not just an afterthought - March 26, 2012