Business vs Functional Requirements: I don't care.

Either I’m getting very lazy or I’ve reached a new point of sophistication in my BA practice because I really don’t care that much about the difference between business and functional requirements anymore. Maybe I’m just sick of the fact that it’s almost a point of pride for people to have their own definition.

Not to mention that fact that half of the time the “business” requirements aren’t from the business they’re from customers or regulators, and that “functional requirement” documents include non-functional things like service-levels and look and feel.

Half the time I don't even consciously differentiate between business and functional requirements. I just elicit a bunch of requirements, get the business to sign off to confirm that it looks like we have a shared understanding, and then specify a solution separately.

For me that's the big separation between classes of documents that BA produce

* Elicited Requirements: Documents conversations and consensus with stakeholders, embodies a shared understanding of situation, with the BA's role being mainly a drawing out from stakeholders.

Elicited requirements could be business, functional, stakeholder, objectives, KPIs, NFRs, show tunes, user stories, wire-frames, or just whatever works best for all stakeholders to communicate.

This is a big mess of "business" and "functional" requirements.

* Specified Solution: Documents a single concrete solution that addresses the situation embodied in the elicitation stage, with the BA's role being to design a solution based on the elicited requirements.

In this model I end up collecting mostly "functional" requirements.

I grant this represents my background working as a system integrator. In a fixed-price environment you really want to manage scope by keeping all that vague text in the elicited requirements separate from the model.

This has always worked well for me, with the following provisos:

* Traceability between elicited reqs and the eventual solution is key. You need to show where you took into account all the things your stakeholders said.

* You still need to understand the difference between business and functional requirements on some level so you know where you can implement something differently from the user request (And note it is such in your traceability)

* I’d never talk like this to someone just starting out as a BA. I think when you’re starting out you need to be much pretty dogmatic about the difference between stakeholders expressed needs, and their underlying objectives to avoid becoming an over-paid stenographer.