Tony,
The decomposition is textual stuff decomposed into process, function, business rules, etc. These can be represented however you like. Even DFD's.
Kimbo
Kimbo,
You right, the BABOK is not a "how to"; its a meta-model. Its written at a meta level so that one could create various methodologies and still comply with the model. I still have a 1.6 version of the BABOK, which could be used to derive the older SDLC (waterfall) and the newer RUP methodologies.
warm regards,
K
K;
The BABOK is a behavioral specification (behavior of BA's) on how to create a behavioral specification (behavior of a system). While it is laregely not written to the detail behavioral level, the fact that it is organized around input/output diagrams means that it is very behavioral related.
(Note: The BABOK's use of input/output diagrams greatly adds to it's confusion. If, instead, it was organized around integrated input/output diagrams (i.e., Data Flow Diagrams, a vary rigorous way of documenting manual or automated behavior), then people would be able to systematically understand it.)
Tony
find that the most professional way is to write all the requirments in detailed uses cases as in the first option ,, but this approach would take a lot of time and efforts especially in the systems that have a lot of functionalities.
Ivaky:
As as a Data Flow Diagrammer, I have always been puzzled by those (the great majority) who, instead, recommend Use Cases. I mean the BABOK says that the real challenge in gathering behavoiral related requirements is not so much discovering the stand alone requirements, but the [essential] interrelationships between the requirements. Do you not agree that the essential interrelationships are the data flows? If not, what would you say are the essential interrelationships? And how do use cases guide a BA in discovering them?
I really am curious. After 20 years of BA experience, am I missing something fundamental here or what?
brought to you by enabling practitioners & organizations to achieve their goals using: