Hi Tony,

I agree - data flows have to be addressed in integration projects and use cases don't provide an answer.  Data flows are part of a solution's design however, so in my opinion such information actually belongs in a use case realisation, rather than within the body of a use case.  A use case realisation gives plenty of scope to describe the components of a solution and the interactions between those components.

Rob.

RUP includes the concept of a use case realisation, since developers would have a hard time trying to code directly from use cases.  A use case realisation is the end product of analysing your use cases.  Typically it would represent the important business entities, their behaviours and the interactions between them.  Use case realisations are often documented using UML class diagrams and interaction diagrams.  This analysis helps translate business requirements into a form that developers can go ahead and implement.

This article from IBM that sums it all up:  www.ibm.com/developerworks/rational/library/5383.html

Robert,

How do you keep your use cases like a "black box"?  I struggle with separating the functional requirements in the use cases from design.  For example, when I document a use case describing how a user interacts with the system to perform some function, I often feel like I am imposing design constraints on the interface, but I don't know how else to document it. 

Would you be able to provide an example of a simplified, "black box" use case you have written?

Thanks