Kimbo,
Guru? Gettoutahere!
Anyway...I'm not sure how what you are saying is disgagreeing as I would also say that process steps can be functions (if they are reuseable in the way I described). The example you give all fit both the process step and function categories. Once upon a time people like me thought that one day solutions would be built using "lego" software: you would "snap" functions together to make solutions and one "lego brick" (ie function) in a solution could be part not only many processes but many solutions.
So that's how much of a guru I am - and by the way just to ram that point home: I also said in the early 90's when the internet was just getting widespread that it was a fad just like CB radio!!! D'oh!
Back to functions - so I think we are fundamentally saying the same thing unless you are saying that all atomic level process steps are functions (which I would say was desirable in the logo solutions world and unlikely in the real world although possible). Not a very big difference between us in any case?
Guy
Any idea where a function hierarchy, as opposed to use cases, would fit in?
Functional hierarchies don't really fit in these days - I have never had to use one in anger: all they tell you is that Function A comprises Function B AND Function C. Nothing about sequence, conditional flows etc. All you get is the knowledge that a function can be made up of 2 or more sub functions (which may be used independently to the parent function in some processes).
Can't really see a use for them myself and like I say I have never needed to use them.
Can I ask why are you interested in functions?
Guy,
Thought you'd like the guru comment :-)
Sounds like we do mostly agree. Depends on what you call a function really. I believe a funciton can be manual or system based, so I think all activities on a process map are functions.
Now about your lego thang, I think rather than reusing functions we can reuse processes. Of course its already being done out there. Reuse of the functions within the process is a corollory of process reuse. So your lego thing has legs if you'll excuse the mangled metaphor.
One last comment. We're talking about functions and Tony hasn't jumped in to instruct us about DFDs. Maybe he's on holidays :-)
Kimbo
Hello Guy and thanks for your suggestions.
I've been looking at packages that can be used to model business/system requirements. Oracle Designer (see link) allows process modelling and function hierarchy modelling, I was unsure why these alternatives are provided, when they would be used, if they are meant to be used in parallel, and how (if at all) they cross-refer to each other - presumably they are both there for a reason and I wanted to get an understanding of common practice re how they are used.
http://www.oracle.com/technology/products/designer/demos.htm
Ah, I see: I used Oracle Designer 2000 back when dinosaurs ruled the Earth (well, 1996). This goes back to my point that functions as I understand them had their roots in programming and programmers like me like reusable code and that is what a function gives you.
Oracle Designer did (and I assume does) generate code and database schemas from analysis deliverables from the tools it provides via wizards. So process models result in code and data models in database schemas (my oversimplification but you get the idea). Identifying functions in that context might help Oracle designer write code...?
I can't say I ever remember using function hierarchies in Oracle Designer 2000 either so my advice would remain: unless you have a defined requirement for constructing them (the hierarchies) don't bother as process decomposition gives the same information and whole lot more (such as process/sequence dependency rules).
BTW: you say you are looking at tools to model business requirements - are you are only looking for those that can generate solutions in an Oracle environment? Otherwise there are plenty other (arguably better certainly cheaper) options out there...
brought to you by enabling practitioners & organizations to achieve their goals using: