Tuesday, August 18, 2009

Types & Levels

I've struggled to reconcile two of my favorite frameworks for talking about requirements for a while now, and I think I've finally got the idea settled in my mind. Basically I'm using BABOK 2.0 defs for , My classifications are

  • BABOK 2.0 requirement classifications
    • Business
    • Stakeholder
    • Solution Functional, which are further broken into:
      • Behavioural
      • Process
      • Information
      • Interaction
    • Solution Non-Functional, and
    • Transition.
  • Bruce Silver's Three Levels of Process
    • Prescriptive
    • Descriptive
    • Executive

For ages I was just using the Silver levels as a sort of Zachmann levelling for processes (proper ones, not the hand-waving level-0 processes), then I started using them to describe the other Behavioural, Information, and Interaction requirements as well, now I'm realising that I should be applying them to all the requirement types in one big matrix, and once I do that I can start putting actual the names of actual artefacts in the intersections between them.

Now it gets interesting, what's a Prescriptive vs. Descriptive Business Requirement? How are behavioural and process artefacts different on the descriptive level? etc. This is getting into definitional debate land that I don't really care about but it's a nice way to get a list of things on one page.

So what use is that? Well, it's the menu items you order off at the beginning of the project for what you intend to produce. It's a major input to requirements plant. It allows you to define what you want to collect (e.g. Stakeholder Requirements), what level you want to collect it at (e.g. Prescriptive), and the intersection between these defines an appropriate the artefact (e.g. Use Cases).

If you decided that full use cases are too much work, or unsuitable you can pop up to the Descriptive level and see that for Behavioral requirements, maybe some User Stories are the go. I doubt I'll ever use this in practice, it's way too complicated and involved, and only BAs who think about method more than they should will like it, but at least I have a coherent internal view I can use myself.

Now if only I could get the same clarity around business rules..

No comments:

Post a Comment