No one seems to want to answer my question about what does a taxonomy of requirements give us in terms of better defining systems for stakeholders. I still think its analysis for the sake of it. Haven't read the BABOK. Suppose I should get around to it one day.

When I list textual requirements I group them based on some logical grouping that applies specifically for that project. If I told my stakeholders that here are their stakeholder requirements and here are some solution requirements. The first thing they'd do is ask "what are you defining solution for, you're a BA?". Perhaps your solution requirements are non-functionals under another name?

Convince an old cynic that this is worthwhile. I'm all ears?

Kimbo

Kimbo,

I agree that using a taxonomy for requirements just for the sake of it is silly.  Analysts need to apply judgement based on their experience. However, I do see value of the business analyst thinking about differnt categories of requirements even if they don't (and probably shouldn't to avoid confusion) share this categorization with the business stakeholders explicitly.

Each logical group of stakeholders, typically grouped by business division, channel, etc., may have differing and conflicting requirements.  The business analyst needs to understand this and enter the requirements elicitation process with this in mind. 

Also, we have all experienced the situation where you are elicititing requirements only to ask ourselves, how does this support the overall business goals of the organization. Not that every requirement has to, but they shouldn't conflict with high level business goals.

You can argue that this all starts with stakeholder analysis.  Who will you be eliciting requirements from? How are the different groups inter-related? What are possible points of contention? Etc.

For seasoned business analysts this is often second nature.  You do all of this intuitively without thinking about it, which is fine.  It works.  For less seasoned analysts, breaking the task of eliciting requirements into smaller chunks based on Enterprise requirements, Customer requirements, Stakeholder group A requirements, Stakeholder group B Requirements, etc., can be a helpful process for arriving at a final list. 

Of course, in the end, you should  have a single set of consolidated, non-conflicting requirements. No need to bucket them at this stage in my opinion.