Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  IDEF0 vs. Use Case
Previous Previous
 
Next Next
New Post 4/9/2008 9:52 AM
Informative
User is offline vinny
66 posts
8th Level Poster


IDEF0 vs. Use Case 

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

 

 
New Post 4/9/2008 11:21 AM
User is offline Adrian M.
732 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 
Modified By ModernAnalyst.com  on 4/9/2008 2:39:57 PM)

 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!
 
New Post 4/9/2008 11:42 AM
User is offline vinny
66 posts
8th Level Poster


Re: IDEF0 vs. Use Case 

 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.

 
New Post 4/9/2008 12:50 PM
User is offline Adrian M.
732 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 

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!
 
New Post 4/10/2008 3:15 PM
User is offline Kimbo
442 posts
5th Level Poster


Re: IDEF0 vs. Use Case 

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  IDEF0 vs. Use Case

Community Blog - Latest Posts

Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points cleared w...
0 Responses
Jason White
Jason White
New technology is in trend every day and striving to make its mark to be the best. It is not optional to stay exceptional, technology has made lives easy and uncluttered in so many ways that cannot be comprehended. With the latest technologies in the headlines every day, it is Artificial intelligence that is leading the race and being incorporated ...
0 Responses
Digvijaybook
Digvijaybook
The role of a business analyst is to manufacture a piece of art; the piece of art varies depending upon the methodology and techniques being used. Business analyst serves the project all through the beginning until the end and comes up with different pieces of art. It all depends on the case, the business analyst gets involved from the beginning of...
0 Responses






Latest Articles

A Practical Guide to Transition from Waterfall to Agile
May 25, 2020
0 Comments
The transition from Waterfall to Agile is never easy – especially for a business analyst who must go through this journey. This document has com...
Copyright 2006-2020 by Modern Analyst Media LLC