[re-online] Data Flow Diagrams vs UML Functional AnalysisTech niques

Finnie, Scott Scott.Finnie at BSkyB.com
Mon May 2 16:39:35 EST 2005


James, Tony,

Many thanks for your replies.  I should clarify my point - I was not
attempting to devalue DFDs or question their use, my question was
specifically with the following statement in Tony's original post:

  > Class diagrams are not capable of prodding the analyst to complete
his/her understanding of system scope.

My point was simply that time invested understanding the structure of the
domain is highly likely to be profitable.  In my experience, the discovery
process is iterative:

 . Users / Customers will initially focus on the principal functions they
need the system to perform (=>initial input 
   to functional model)
 . Discerning the data implied in those descriptions enables the initial
construction of a logical domain model.  This in 
   turn enables me to ask more informed questions about required
functionality hitherto unstated.  Those questions lead 
   to refinement of the functional view, and so on iteratively.

Note there's an important difference in use between the two; the functional
view is the primary vehicle for discussion with the customer, the structural
view a tool to help me get the former right.  So, for me at least, a domain
model _is_ a fundamental prod in helping me discern system scope.  (I agree
Tony that an ERD walkthrough is in general less useful than a DFD
walkthrough).

Regards,
Scott.



> -----Original Message-----
> From: re-online-bounces at it.uts.edu.au 
> [mailto:re-online-bounces at it.uts.edu.au] On Behalf Of James Robertson
> Sent: 13 April 2005 19:47
> To: Requirements Engineering Online Discussion Forum; Tony Markos
> Subject: Re: [re-online] Data Flow Diagrams vs UML Functional 
> AnalysisTech niques
> 
> Scott and Tony, 
> 
> Let me jump in an augment Tony's argument. He needs no help 
> from me but there is something missing I think clarifies the point.
> 
> Any system is composed of process and data. One cannot exist 
> without the other so both are important to us. But consider 
> their nature. A unit of data, by its nature, cannot describe 
> which processes act upon it. However, a unit of functionality 
> must describe the data it uses by the outputs it produces. 
> The context model, which Tony correctly states as the only 
> formal scope definition tool, is a function model that shows 
> only one function, but all the inputs and outputs.
> 
> By precisely defining the inputs and outputs, you define 
> precisely the functionality that work area uses. By inference 
> you also define the data stored within the work area. There 
> is no other diagram that can do that.
> 
> A model of stored data cannot say precisely what 
> functionality is within scope. It can suggest it, but my 
> experience is that important functionality is always missed 
> or assumed.
> 
> The context model has one other advantage: it is 
> technologically neutral in that it does not suggest the limit 
> of the intended system, but is usually (and correctly) drawn 
> to scope out the business or work area into which the new 
> system is to be installed. This is important. Unless the 
> requirements analyst studies the work and the people doing 
> the work, there is little chance he will deliver the most 
> appropriate system to help with that work.
> 
> Regards,
> 
> James Robertson
> 
> > Scott:
> > 
> > The only formal system scope definition tool that I am 
> aware of is a 
> > Context Diagram - which is a special kind of Data Flow 
> Diagram.  Scope 
> > definition needs to be among the first things done, and, especially 
> > for larger systems, it needs to be done in as formal a manner as 
> > possible.  Else alot of time is going to be wasted. I have 
> seen this 
> > happen more than once.
> > 
> > And, typically, as we often need to create a Context Diagram by 
> > summarizing from a regular DFD, DFDs, at least higher-level DFDs, 
> > should be first - before any type of data modeling (ERDs).
> > 
> > Also, a big part of discovering the user's world is walking through 
> > our understanding with them.  DFD's are great for user 
> walkthroughs.  
> > ERD walkthroughs are alot tougher - often impossible.  And ease of 
> > walkthrough is especially critical in larger-scale projects, where 
> > multiple iterations of walkthroughs are required.
> > 
> > You ask how I can proceed [to functional model] without a 
> data model.  
> > To some degree I create data models as I function model.  
> However, I 
> > always lead with functional modeling. Also, functional model data 
> > dictionaries give me significant data insights.
> > 
> > Tony Markatos
> > 
> > --- "Finnie, Scott" <Scott.Finnie at bskyb.com> wrote:
> > 
> > Tony Markatos:
> > 
> > Analysis is a discovery process.  When a DFDr
> >> misses essential functions, the omissions really
> > stick out like a sore thumb!  To rigorously scope out a 
> system, DFDs 
> > are required; they are the only tool that can do such......
> > 
> > 
> > Tony, I have to disagree.  In my experience quite the opposite is 
> > true: a class diagram (or ERD) is an extremely useful tool for 
> > exploring the problem domain.  Building a class diagram forces the 
> > analyst to ask searching questions about the concepts in the domain 
> > and how they relate to each other.
> > 
> > I use an analogy (repeated on this forum previously  I
> > think?) that the class diagram defines the vocabulary and 
> grammar of 
> > the problem domain; behavioural specifications (DFDs / Use Cases / 
> > Process models / StateCharts / ...) are analogous to the 
> sentences we 
> > wish to make about the domain space.
> > 
> > That's not to dismiss their use - understanding the behavioural 
> > requirements is of course important - but you can't write a 
> sentence 
> > without a vocabulary or grammar.
> > 
> > In practice I find the following most useful in nailing 
> down the scope 
> > and
> > requirements:
> > 
> > . Domain Model (Class Diagram / ERD - statics only) . Some form of 
> > behavioural specification.
> > Depending on the nature of the problem, I'll use one of the 
>  following 
> > as primary, with one or both of the others as backup:
> >>    a) For interactive systems, User Roles & their Goals 
> (aka Actors & 
> >> Use Cases, but initially just a
> >>       declarative definition of the goal - pre and post conditions)
> >>    b) For algorithmic or process-intensive applications, DFDs
> >>    c) For Workflow oriented systems, process maps with swimlanes
> >> 
> >> In a subsequent phase (at least logically, if not
> >> temporally) I'll model
> >> object lifecycles with statecharts where appropriate and add 
> >> declarative constraints (business rules / invariants) to prevent 
> >> illegal state space combinations.
> >> 
> >> Personal opinions only of course, although I'd be 
> interested to know 
> >> how you define the concepts in the domain without a class diagram 
> >> (data dictionary?).
> >> 
> >> Regards,
> >> Scott.
> >> 
> >> 
> > 
> > 
> > 
> > __________________________________
> > Do you Yahoo!? 
> > Yahoo! Personals - Better first dates. More second dates.
> > http://personals.yahoo.com
> > 
> > _______________________________________________
> > re-online mailing list
> > re-online at it.uts.edu.au
> > http://discuss.it.uts.edu.au/mailman/listinfo/re-online
> 
> ________________________________________________
> James Robertson
> the Atlantic Systems Guild
> james at systemsguild.com
> http://www.systemsguild.com
> 
> Mastering the Requirements Process by Suzanne and James 
> Robertson foreword by Jerry Weinberg - published by 
> Addison-Wesley 
> http://www.amazon.com/exec/obidos/ASIN/0201360462/theatlanticsyste?
> 
> _______________________________________________
> re-online mailing list
> re-online at it.uts.edu.au
> http://discuss.it.uts.edu.au/mailman/listinfo/re-online
> 
> 
> .
> 

-----------------------------------------
Information in this email may be privileged, confidential and is intended
exclusively for the addressee. The views expressed may not be official
policy, but the personal views of the originator. If you have received it
in error, please notify the sender by return e-mail and delete it from your
system. You should not reproduce, distribute, store, retransmit, use or
disclose its contents to anyone.     Please note we reserve the right to
monitor all e-mail communication through our internal and external
networks.



More information about the re-online mailing list