Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  IDEF0 vs. Use Case
Previous Previous
 
Next Next
New Post 4/11/2008 7:55 AM
Online now... Adrian M.
726 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 

Hi Kimbo,

You are absolutely correct, using IDEF0 is like programming in COBOL (I made a similar analogy to FORTRAN).  And you are correct also that UML is the most popular modeling language/notation.  But we should also remember that IDEF0 "used to" be popular at one point - so what happened?  UML came along it became popular - arguably because it was better.

So, unless we think that UML is perfect, we should be open to the idea that there could be newer modeling standards which, in some cases, work better than UML.  I am a frequent user of UML diagrams especially Use Case Models, Class Diagrams, Sequence Diagrams, and even Activity Diagrams.  However, for business process modeling I like to use BPMN (a newer notation) which, I believe, is much better suited for this task.  Even the OMG, standards body for UML, chose to add BPMN to it's list of standards even though, many argue, Activity Diagram could do as good of a job.  Take a look at the BPMN specification  - you might be surprised by what you find.

Best regards,

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 4/11/2008 11:07 AM
User is offline Chuck Patrick
1 posts
No Ranking


Re: IDEF0 vs. Use Case 

Hi, fellow BAs,

I've followed this dialog with interest and have a few points for you to consider:

The religious wars between methodologies and techniques don't have to be regarded as zero sum games. The techniques mentioned in the thread have strengths and weaknesses and can actually be used in concert quite effectively.  For example, I typically use IDEF0 on a project to construct an enterprise-wide business process model down a couple of levels of decomposition.  The business orientation of the IDEF0 model lends itself to review and revision by business professionals who can learn to love the simple IDEF0 syntax and semantics, but may be put off by the technical complexity of UML, for instance. Depending on the objectives of the project, such as automating the client's procurement process through work flow software, I may drive the process model down in a selected area to better understand the interfaces between the procurement process and other financial and logistics processes. At this point, dropping into UML or BPMN or developing detailed swim lane diagrams may be the way to go. The preferred techniques to use can be identified by considering the skills of the developers and the complexity of the business process, among other factors. A major advantage of the enterprise model is for new business generation--understanding how the process initially focused on relates to the rest of the client's business and where to go next. This is a win-win situation with a client who is serious on long-term systemic improvement. You can give good advice on how to proceed with the next project and have an understandable architecture with which to discuss options with the client.

A second point to consider is the tendency to equate IDEF0 to "old technology". To me, this is analogous to dismissing calculus as "an old way of working with numbers". Importantly, IDEF0 is a way of thinking and communicating, not a technology. I believe it has gone somewhat out of vogue because no one who really understands the profound philosophy underlying its design is active in training new business analysts. I happen to have worked at SofTech, the originator of IDEF0 in its initial form of SADT--Structured Analysis and Design Technique--for seven years and appreciate the richness and power that can be realized through its proper application.

A third point to consider is that the bigger game to play lies above the realm of specific methodologies and techniques to choose from. It lies in the larger strategies for helping a client transform--incrementally or aggressively--its business enterprise through better application of information technology and business process management. Such a strategy is Enterprise Architecture, which encompasses a broad range of architectural concepts and underlying methodologies and techniques. When you take on this bigger picture approach, it becomes evident that you need to understand how to mix and match your tools because no single tool will suffice for doing the whole job.  There is tremendous potential for people who can grasp the whole picture and construct the resources that are needed to do the job properly.

Regards,

Chuck Patrick

 
New Post 4/11/2008 11:52 AM
Online now... Adrian M.
726 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 

Hi Chuck,

I have a one word response to your post: "Amen!".

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 4/12/2008 4:23 AM
User is offline Kimbo
438 posts
5th Level Poster


Re: IDEF0 vs. Use Case 
Modified By Adrian M.  on 4/12/2008 10:13:05 AM)

Yeah, well said Chuck.

I actually don't use either activity or IDEFO to model process. I'm currently using a tool that uses an approach based on, I think, Martin of EA fame. The tool is called holocentric (www.holocentric.com). I'm just a customer, not associated with them. It has the whole of business approach that I like and that you were alluding too, I think.

Perhaps we should call a halt to the religious wars as you say Chuck. I do love a good argument though.

Kimbo

 

 
New Post 4/12/2008 4:58 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: IDEF0 vs. Use Case 

Reading through the latest posts in this set, I started to get the feeling that someone was going to say "can't we all just get along?",  but it hasn't happened and may be a bit unfair to imply.

But, I will reiterate a few things:

1) BA's should learn/use UML (and I mean other than use cases) because its popular? because the other kids are doing it? I still prefer to use what works best.

2) Use Cases may be an integral part of UML, but I guess that's because UML needs them, but you can use Use Cases very effectively for Requirements without the rest of UML. So when someone says they are using UML for Requirements, I would ask, "you mean you are using Use Cases?"

And that''s pretty much all I have to say on this...


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

Community Blog - Latest Posts

Samuel02
Samuel02
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses
BPM_online
BPM_online
Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be fo...
0 Responses
Heta Raval
Heta Raval
In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and wi...
0 Responses




Latest Articles

What’s Missing from Agile?
Oct 20, 2019
0 Comments
John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information te...
Copyright 2006-2019 by Modern Analyst Media LLC