Hi Tony,

In my response I didn't mean to imply that for larger scale projects use cases are the best way to model the "AS-IS" of an organization. 

If I was forced to pick only one tool I would choose a process flow diagram, probably using BPMN (Business Process Modeling Notation) to model it.  Nothing better to model business processes than a business process diagram.

If I was allowed to use two tools then I would definitely add the Business Entity Model because before even talking about how data flows within a system I would want to define the actual data to ensure that everybody knows what we are talking about.

Then I would create data flow diagrams which shows how data (as defined by the Business Entity Model) flows among processes.  I agree with you that an ERD would not be needed at this point - thanks for correct me on this one.

- Adrian

Craig:

I am personally very familiar with one of the engineering managers who tried to use a Method-H-like approach to cature the as-is (of how this large this large software\electrical engineering company develops software).   This guy is leading a charge to move the developers away from ad-hoc requirements specification to more formal requirements documentation. Very few others within this company have the proper focus to successfully use any  formal as-is modeling technique.   And yet I can not use his documentation in my task of larger scale integration.   It is just to incomplete, nebulous, and wrong. 

It is not his fault.   I do not believe it is not humanly possible to come up with an integrated understanding of the inputs and outputs for a large series of interacting functions by basically looking at inputs and outputs of single functions in isolation.   

Tony