Go have a look at the page on business requirements and see if you can offer some suggestions for improvement. We can discuss iseeas here if you want.
I think a starting point would be coming up with a better definition for what is a business requirement. It looks like the page uses the term as a catch all for many different types of requirements.
I like how the IIBA has defined the term in BABOK 2.0: "higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis."
This makes business requirements clearly different than stakeholder requirements and solution requirements.
From my experience the definitions used in the BABOK are not well socialized in many organizations, but I think they are valuable because it aligns the various types of requirements with different business analysis activities, and also allows for clear relationships to be built between different requirements, particularly 'cause/effect' type relationships (e.g. 'we need to have a CRM system because the current spreadsheet-based solution can't handle our growing customer volume, and our company's goal is to increase our customer count by 200% this year which will only make problems more acute).
Hi:
There is no - zero - nada one - logical reason to seperately have business requirements, stakeholder requirements, and solution requirements. This is a classic example of a forced, artificial partitioning that largely serves to retard analysis. There are essential requirements (i.e., unchanging, technology independent, business requirements) at various levels of abstraction - top most level to the very detailed level. There are esseential requirements implemented via software and essential requirements implemented manually.
The BABOK's purpose is not to make logical sense. It is to present commonly accepted practices. Problem: Business Analysis is still in it infancy; many commonly accepted practices are poor.
Tony
Hi Tony,
To me such definitions are not forced or artificial, but flow naturally from answering different questions:
- Business requirements help me answer 'why?'
- Stakeholder requirements help me answer 'what?'
- Solution requirements help me answer 'how?'
I catalogue requirements not just to analyze them but to keep track of which are currently met/not met, update them as the business evolves, package collections of them for specific projects or to communicate a subset to specfiic stakeholders, and answer questions from executives like 'So why are we spending money on project X anyway?'. Having a type categorization, along with proper relationships documented, helps me to do this easier. If I was performing analysis on a specific system, process or organization unit I would look at all of the requirements of all types that relate to the area in question.
To try and understand where you're coming from, how is using the term 'essential requirements' to describe a specific type of requirement any different than adding any other adjective in front of the word requirement? Do you believe that it's not necessary to differentiate between different types of requirements, or that there really aren't different types of requirements but just 'requirements'?
Hi Jarett,
I generally view business people telling me "how" type solution requirements as a red flag. There is always an underlying business requirement. They think they have worked out a solution and this is what they are proposing as a "requirement". Its my job as a business analyst to get behind the solution they think they need to find their "actual" requirement. What Tony calls an essential requirement.
Have to say I agree with Tony on this one for what that's worth.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: