RML™ Requirements Model 5 - The Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) is a very useful part of the Requirements Modeling Language (RML™). The Structured Analysis Wiki contains a great explanation of how to create a DFD, so I’m not going to cover that information here. Instead, I’m going to provide one answer to the question “How do I know when to use a DFD?” This answer comes from my own (unique) view of the world, so some of you probably won’t relate to it, but others will--I’m sure there is at least one more out there…

Sometimes I have what I think of as an "equation" in my head. In vague terms, I may be thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”. But that's not really right, nor is the equation a good representation of the information.

And, the “equation” also misses a few other particulars about creating an order that I’d like to convey: Sales Reps update customer data, the Finance staff maintains the rules for the tax calculations, and orders flow to the Order Fulfillment system after creation.

The data flow diagram is great for representing all of this. Here’s my “equation,” expressed as a data flow diagram:

I have found that business users, as well as developers, react well to this model—it provides a “big picture” with which to begin a conversation about creating an order. It paints exactly the picture I want to convey and validate when I’m thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”.

Display this picture, and you’ll get some interesting questions and comments:

• How is customer data populated initially?


• Does the order fulfillment system update the order store with information about the fulfillment of the orders?


• Where does the product data come from?


• Are all of the tax rules manually entered, or is there also an electronic source for them?


• And, maybe, “No, that’s wrong, updating customer data isn’t a separate process. Customer updates need to automatically flow out of changes made when creating the order.”
  

One note: it doesn’t have to be technically perfect to be useful. I often provide “conceptual” DFDs, in that I intentionally provide conceptual, but not technical information. For example, conceptually, there is a “products” data store. Technically, there may be multiple stores: product list, product descriptions, etc. The important thing is that they work together to provide product data. Developers and architects are very receptive to this; they understand I’m illustrating the behaviors of the system without defining the implementation (which, after all, is their job). Oh, and how does the audience know it is conceptual? I put the word “conceptual” in the title!

You may notice I didn’t number my processes. That’s because I rarely decompose them and many people tend to take the numbering as ordering. So, for my usage, numbering adds confusion rather than clarity.

Happy diagramming!

Related Articles:

How To Choose A Software Requirements Model

Six Requirements Models For Agile Projects

Live from BAWorld: A Case For Visual Models

I heard a presentation at BAWorld, but for this one I won't mention who it was, because I'm going to critique it in a very specific way. The talk wasn't bad per se, but one thing about it really bothered me. You see, the speaker displayed a slide that was supposed to convey traits of an effective team. The slide contained a circle with 16 lines coming out from it (like a sunshine almost). Each line had a trait on it, for example "committed", "conflict management", "self directed", etc.


The speaker then asked us "What traits are missing?" And my immediate reaction was to go to a place of "Seriously? You want me to read a list of 16 things and tell you something meaningful that is missing?"


So this is another fine example of Miller's Magic number, aka 7 +/2, where the human brain can only hold that many things. So by the time I get to item 10 out of 16, it's unlikely I remember the first.


Add to that, the ideas around the wheel aren't parallel ideas, so it's even more frustrating. If you are going to make a list like this, make them the same type of word - i.e. verb, noun, etc. Ideally they should be of similar type too, but that's harder to measure.


And finally, if you are going to use a visual to display your list, that's great, except that it needs to be one that actually organizes the information in a way that is useful. A circle of lines did not help organize the list. Maybe if he had grouped items together, there would have been 7+/2 items at the first level, with a few branches off each of those.


People did play along and shout ideas, but honestly, I thought the ideas overlapped with what he already had up there. Who knows.


This whole example is simply more justification for why we use visual models to represent information. With an appropriate model choice, we wouldn't have to remember 16 things, it might have helped force a parallelism, and finally it will help organize the information.

How To Choose A Software Requirements Model

Do you find that you're always trying to use process flows on your projects, but they just don't seem to fit your needs?

Do you need to start modeling requirements, but can't quite decide what models to use?

There are quite a few requirements models out there to choose from, ranging from the mundane (process flow), to the amorphous (use case) to the exotic (fishbone diagram). Knowing which models may be most helpful to you can be a bit tricky, but the following tips can help!

Choosing the Right Software Requirements Model

If your application has:

• Lots of User Interaction - useful models can be Org Charts, Use Cases, System Context Diagrams
• A Complex UI - useful models can be Org Charts, Use Cases, Wireframes
• Lots of Involvement with Different Systems - useful models can be System Context Diagrams, Data Flow Diagrams
• Data Processing - useful models can be Entity Relationship Diagrams, Data Flow Diagrams, System Context Diagrams

And don't stop with these - there are many other models to explore! Take the plunge, and break away from process flows today!

Check out these detailed explanations.

• State Tables
• Decision Trees
• Click Action Response Tables
• Data Dictionaries