 |
|
|
|
I typically model processes using the IDEF0 method. Is there a reason why I'd use the Use Case approach, with which I'm now ten minutes familiar, rather than IDEF0? IDEF0 allows me to specify actions and the people who are involved in those action, as does Use Case, and also allows me to specify controls on an action. So what's the advantage?
TIA,
vinny
|
|
|
|
 | |
|
|
|
| vinny wrote
I typically model processes using the IDEF0 method. Is there a reason why I'd use the Use Case approach, with which I'm now ten minutes familiar, rather than IDEF0? IDEF0 allows me to specify actions and the people who are involved in those action, as does Use Case, and also allows me to specify controls on an action. So what's the advantage?
TIA,
vinny |
Hi Vinny,
In our profession, there is not just one method for doing one thing. A senior and well seasoned analyst should use the best tool for the job - though it is not always very easy to determine which one is the best tool. My advice to you is "if it works don't break it". If the IDEF0 method works for you and your organization don't change it.
It would be probably fairly hard to model with Use Cases alone the same types of things that you can model with IDEF0. So why the hype about use cases, should you use them? Use Cases were created to provide an alternate way of specifying functional requirements and they became very popular for many reasons. However, something else started happing at the same time, since many folks were able to grasp the concept of use cases they began using use cases for all types of other purposes. For some applications they work but not for others.
For your specific need, use cases are not a good tool for modeling processes - it's possible to hack it, but why?
To be fair, there are other reasons to switch out of IDEF0 even if it does work for you. For example, remember all those systems written in FORTRAN? They still work and, if you wanted, you could probably create new systems using FORTRAN and they would probably work just as well as one written in Java. So why not stay with FORTRAN? It all has to do with supply and demand. The job market does not have a high demand for FORTRAN programmers but it does for Java developers.
Same goes for analysis methods and techniques... While IDEF0 is still being used and you can probably use for some time, there probably isn't much demand in the job market for those types of skills. So, as an analyst, you might consider expanding your knowledge to include some of the newer modeling methods. In your case, I would suggest BPMN (Business Process Modeling Notation).
Here's why:
- BPMN is at the forefront of business modeling,
- It is a well structured and well defined graphical notation,
- It is being widely used for new Business Process Management (BPM) projects,
- Most of the leading business process modeling tools support BPMN,
- There's defined transformation rules and mappings between BPMN and process metadata formats such as BPEL,
- BPMN has been adopted by the OMG as an official standard,
- There's a demand in the job market for people with BPMN experience.
For more info on BPMN check out bpmn.org
Hope this helps!
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
|
| adrian wrote
| vinny wrote
I typically model processes using the IDEF0 method. Is there a reason why I'd use the Use Case approach, with which I'm now ten minutes familiar, rather than IDEF0? IDEF0 allows me to specify actions and the people who are involved in those action, as does Use Case, and also allows me to specify controls on an action. So what's the advantage?
TIA,
vinny
|
Hi Vinny,
In our profession, there is not just one method of doing one thing. A senior and well seasoned analyst should use the best tool for the job - thought it is not always very easy to determine which one is the best tool. My advice to you is "if it works don't break it". If the IDEF0 method works for you and your organization don't change it.
It would be probably fairly hard to model with Use Cases alone the same types of things that you can model with Use Cases. So why the hype about use cases, should you use them? Use Cases were created to provide an alternate way of specifying functional requirements and they became very popular for many reasons. However, something else started happing at the same time, since many folks were able to grasp the concept of use cases they began using use cases to all types of other purposes. For some applications they work but not for others.
For your specific need, use cases are not a good tool for modeling processes - it's possible to hack it, but why?
To be fair, there are other reasons to switch out of IDEF0 even if it does for work you. For example, remember all those systems written in FORTRAN? They still work and, if you wanted, you could probably create new systems using FORTRAN and they would probably work just as well as one written in Java. So why not stay with FORTRAN? It all has to do with supply and demand. The job market does not have a high demand for FORTRAN programmers but it does for Java developers.
Same goes for analysis methods and techniques... While IDEF0 is still being used and you can probably use for some time, there probably isn't much demand in the job market for those types of skills. So, as an analyst, you might consider expanding your knowledge to include some of the newer modeling methods. In your case, I would suggest BPMN (Business Process Modeling Notation).
Here's why:
- BPMN is at the forefront of business modeling,
- It is a well structured and well defined graphical notation,
- It is being widely used for new Business Process Management (BPM) projects,
- Most of the leading business process modeling tools support BPMN,
- There's defined transformation rules and mappings between BPMN and process metadata formats such as BPEL,
- BPMN has been adopted by the OMG as an official standard,
- There's a demand in the job market for people with BPMN experience.
For more info on BPMN check out bpmn.org
Hope this helps!
- Adrian
|
Holy cow, what a wealth of information! Thanks, Adrian, for taking the time to compose such an elaborate response!
I've been doing the business requirements thing for a few years now, but I've never been introduced to any actual methods. So, fairly recently, I did some research and I came across IDEF0. It is far better suited for modeling current and target processes than regular flowcharts. Plus it's an IEEE standard, which I found to be attractive. I just came across Use Case today and it appeared on the surface to be similar.
I'd be lying if I said that I wasn't trying to beef up that resume (trying to move toward the BA route from my current Programmer/Analyst path), so being aware that IDEF0 is 'old' and not a skill in high demand anymore is very helpful.
I'll start researching BPMN right away.
Thanks so much again, Adrian. |
|
|
|
| |
|
|
|
Hi Vinny,
You are very welcome! Since you are new to the business analysis world then, in addition to BPMN which is good for business processes, also focus on UML (Unified Modeling Language). UML is often used to model the realization of Use Cases and functional requirements. As part of UML focus on the following types of diagrams:
- Class Diagram
- Sequence Diagram
- Activity Diagram (similar to BPMN but BPMN is much better)
- Use Case Diagram
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
|
Hi Guys,
Fact is that UML is the industry standard, not IDEFO. IDEFO is definitely old hat. UML activiity diagrams are good for process. So what Adrian said may be true but its bad advice. You need portable skills in this industry. UML is extremely portable. You might find some old coders around somewhere who understand IDEFO but most people don't.
Kimbo |
|
|
|
| |