Back in the day, we used to talk about functional decomposition. To me there are two phases in defining a system where we still do this. The first is where we go from a set of textual requirements gathered from our business stakeholders i.e. the system shall .... type statements.
Requirements give us a textual definition of "what" we want. Our first decomposition is then to look at these requirements and work out what processes, functions, rules, etc we need to realise these requirements. This is sometimes called detailed business requirements or functional requirements. I use business use cases at this level. At this point we are still dealing in the 'what' we want. It is not design.
The next decomposition is to look at 'what' we want and define 'how' we want it to work - design a solution to our requirements. At this point we are into defining screens, reports, interfaces, etc. These are the thing that end up being developed.
I think the essence of being a BA is being good at these two decompositions. It is what the 'A' in BA stands for! This is how we earn our money. The rest is just bells and whistles. I'm being simplistic but being a BA is really a pretty simple thing and we tend to complicate it unnecessarily I think. Get good at doing these two things and I guarantee you'll have success as a BA.
Kimbo
It is what the 'A' in BA stands for! This is how we earn our money. The rest is just bells and whistles. I'm being simplistic but being a BA is really a pretty simple thing and we tend to complicate it unnecessarily I think. Get good at doing these two things and I guarantee you'll have success as a BA.
Hear! Hear! Cant agree more. Its seems that our profession is being complicated unnecessarily!
Here is a rather awkward analogy.
If you want to loose weight all you have to do is exercise really strenuously for 10-15 minutes to SWITCH ON your metabolism; and once your metabolism is on, you'll burn fat. (of course you have to eat less than you burn) Yet, most GYMs and personal trainers will let you exercise for 30-45 minutes. Why? They cant justify charging for 10 minutes only!It seems that we are becoming BAs with lots of methods, techniques, cerificates etc. I'm beginning to think the AGILE mob has some merit!
warm regards,
K
Hi Kimbo,
This is a great 'system'. I would be interested in reading --
Thanks, Sloan
Hi Sloan,
Reading between the lines, I think your questions are really about how to take the techniques in the BABoK and apply them to modelling a system. Am I right?
That seems to be the major flaw in the BABoK. The BABoK is really like the user guide that goes through all the screens and stuff in detail but omits the "how to" type information that allows you to put it all together into something useful. "How to" guides are much harder to write of course.
Anyway, I can't really answer that in a sentence or two. Been thinking of writing an eBook. Is that something you'd be interested in?
Happy to answer specific questions you may have of course.
Kimbo:
Come back from the dark side! Decomposition - especially more than one or two levels down - using Use Cases (business or not). Auuggggjhhh!!
Tony
brought to you by enabling practitioners & organizations to achieve their goals using: