From lechner@cs.uml.edu Sun Apr 9 21:08:56 2006 From: Bob Lechner Subject: Essential Analysis (the case for Data Flows over Use Cases) To: sfrye@cs.uml.edu (Scot Frye), ralmonte@cs.uml.edu (Almonte), 05f524 RJLRef: $PH/06s524/DFDvsUseCase060409.txt Forwarded message: > From re-online-bounces@it.uts.edu.au Sun Apr 9 08:48:04 2006 > From: Tony Markos > Subject: Essential Analysis (Was: Re: [re-online] RE ROI estimates) > To: Requirements Engineering Online Discussion Forum > Tony Markatos wrote: > > Why did Use Cases fail in this larger-scale > requirements analysis effort? I have seen this > situation before. The problem is obvious: Use Cases > failed to make "holes" in [a requirements analyst's] > understanding of functional requirements glaringly > obvious. > > Davor responded: > > I have had similar experiences with Use Cases with > respect to what you are mentioning, and what I'm > really interested in is identifying why they leave > these "holes" in! > > Tony Markatos responds: > > That is, in my humble opinion, the the most essential > question in requirements engineering today! (Funny > though how few are even focused on this issue - > really.) > > Some years ago, I took the Yourdon course in > Structured Systems Analysis. The very first thing the > instructor talked about was the fact that previous > functional analysis techniques utilized what I call > the old "connect-the-boxes" approach (this approach is > as old as systems analysis). > > As that instructor explain, in the old > "connect-the-boxes" approach, the requirements analyst > FIRST draws functional boxes and THEN he/she tries to > figure out how all the boxes interconnect. > > That instructor then further explained that what the > requirements analyst is actually doing in this > situation is putting his/her limited (flawed) > understanding down on paper and then is trying to > force fit really to match that flawed understanding. > > Use Cases are classic example of the old > "connect-the-boxes" approach. > > Result of a "connect-the-boxes-approach": Discovery > (i.e., requirements elicitation) is derailed - the > analyst sees what he/she wants to see (i.e, what > he/she already knows) and, in a major way, evades > looking for what he/she does not know (i.e., missing > essential functional requirements). > > To better visualize the problem with the old > "connect-the-boxes" approach, compare that approach > with proper use of Data Flow Diagrams. (I must > emphasize the word "proper"; many DFD'rs actually try > to "connect the boxes" - largely negating the > effectiveness of their DFDs.) > > With proper use of DFDs, within the scope of the > system, the analyst FIRST draws some data flows. When > those data flows naturally split or combine THEN > he/she identifies a function. The big difference: > The analysis technique itself actually prods the > analyst to identify functionality. With a Data Flow > Diagram approach, in the ideal, the analyst's (flawed) > understanding does not even "come into play". > > Of course one can say that ideals and reality seldom > match. However, the differences between an (as Tom > DeMarco called it) "interview the data" approach and a > "connect-the-boxes" approach are so profound, that > even a half-hearted attempt to follow the data flows > results is a big improvement over a strictly > "connect-the-boxes" approach. > > Davor wrote: > > ...The main reason I see for not being able to provide > this "big picture" is that use cases are providing > only "snapshots" ..... > > Tony Markatos responds: > > Exactly. As Tom DeMarco wrote: The data flows provide > the litmus test of [proper integration]. To the > degree that we move away from formal identification of > the data flows - and Use Cases do not ID data flows - > we move away from checking the completeness of our > analysis. > > Davor wrote: > > As such they do not provide even complete description > of each system process. This lack of integration > is what I feel leaves all these "holes" in - you do > not see any issues that arise when all of these use > cases get *integrated* to provide a full specification > of the system (minus all the stuff that has to be > filled in that does not exist in the UCs due to the > invisibility to the actors, at least when we are > working with Cockburn's UCs). So, I strongly feel that > UCs are an excellent *elicitation* technique, very > useful for customers and communication purposes, but > fail short when > it comes to providing necessary stuff for an > analyst/architect in term of providing a full, > integrated, picture of the system - i.e., clear > overall *specification* of the system. So, I feel much > more has to be done on top of just discovering and > specifying UCs before jumping into such activities as > OOA and similar, which are most often done exactly in > this fashion. >