Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…

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 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'?