Company logo of Crocus Information LtdCrocus Information Ltd

Business Requirements Analysis consultancy to blue chip companies

Exercise 2 Answer

(answer to the exercise: Update the top level dataflow diagram with the results of Exercise 1)

There is no single right answer - but there are plenty of wrong ones!

This exercise was to give you practice in keeping the top-level dataflow diagram up-to-date with what you find in your investigations of the processes on it. We were concentrating on just one, the 'Sell Product and Take Order' process.

Old top level dataflow diagram

(click to see larger, opens in a new window) stuff less relevant to what we're doing is blurred out

New top level dataflow diagram

Without further ado, here is our answer for you to compare yours to. We've highlighted the changes to make them obvious for you.

(click to see larger, opens in a new window)

Decomposition of Process 1

So you can see and compare how the lower level was summarised upwards into the diagram above, we've repeated it here:

(click to see larger, opens in a new window)

Well done if you...

Here's the essentials you must get right. For each bullet you can tick off, give yourself two points :)

  • Did you include at least one dataflow to / from all the external entities from the lower level DFD?

    If the lower level DFD has flows in both directions then, on the level above, you need either two flows, one in each direction, or a bi-directional flow.

  • Did you remember to include the diagonal bar in the top left of any external entities that appear more than once?
  • On the level above (i.e. the top level in this case), now that process 1 is decomposed, it doesn't get the */ symbol in the bottom right.

    Remember, using that symbol is the way you indicate the process isn't decomposed further. Did you remember to leave it out?

  • None of the private datastores on the lower level should appear on the top level (T1.1 to T1.6, D1.1 and D1.2). Did you leave them out on your tope level DFD?

Observations about our answer

As we mentioned at the top, there isn't a single right answer. Where you might have done something different but still ok, we've mentioned why we did what we did, below.

Number of dataflows to and from external entities

Normally you don't show more than one flow in each direction between a process and an external entity. We have. Twice.

  • With Customer

    emailshots are really important to the business so needed to be mentioned. But equally, so are the sales calls they make because they're an important source of business (verbal purchase orders). We also needed to allow for purchase orders being received through the post / email and that's why the final flow from Customer is there.

    If the diagram was much busier, we'd probably not differentiate between verbal and normal purchase orders, saving a flow and helping keep the diagram simple.

  • With Accounts

    We wouldn't normally show reports on a DFD because it can lead to unecessary clutter on the diagram. Having them listed in a separate Reports section or in the I/O descriptions is how you record them formally in the dataflow model.

    In this case, though, the end-of-day Sales and Returns report is pretty fundamental to the operational running of business, from both Marketing's and Account's eyes. As such, if it was missing then a vital piece of the jigsaw would be missing in the eyes of the business.

Summarising dataflows

On the lower level, there are four flows interacting with the Stock Room Team. Three come from the team and one is a flow out to the them. How did we summarise them on the top level into just one in each direction?

From the Stock Room Team

  • List of stock items running low
  • Returns Notes
  • Unfilled Orders

When summarising up to the top level, we combined the first two into one flow from the Stock Room Team and called it "Low-stock and Returns Notes".

We ignored "Unfilled Orders" as that's more of an exception but we could have included it if the business felt it important enough. If so, we'd likely call the top-level flow "Low-stock, Returns Notes and Unfilled Orders".

To the Stock Room Team

  • Dispatch and Delivery Notes

This one made it to the top level intact.

Inter-process flows

Originally, on the top level there were dataflows between process 1 and processes 2, 3 and 5.

Normally, inter-process flows indicate that while doing one process (or at its end), you temporarily halt that process and start the other with the data that's flowing. You can also use them while working top down in the early stages to show there's some form of interaction, but you're not entirely sure of them until you decompose the process to find out. That's what's happened here.

During the interview with Bo Sibbuts, we found that things were being batched together and only passed on at specific times of the day. This was done either via internal post or by someone walking the batch over to the other team.

Of course, that data still has to be passed by the receiving teams into their processes. So we now have:

  • a flow from the Marketing Team representing the End-of-day Sales and Returns report into Process 5, Plan and Execute Advertising Campaign
  • a flow from the Stock Room Team representing the Dispatch and Delivery Notes into Process 2, Fill and Dispatch Orders

1 point for you for each you included - for each one you missed, lose a point!


  • 10 points: You're well on your way to being a master of the rules of drawing DFDs. Well done!
  • 7, 8 or 9 points: Oops, it was maybe an oversight of yours - more attention to detail, please :)
  • 6 or fewer points: You need to brush up on the rules of drawing DFDs - but well done for making it this far - some has stuck :D

If you do need to brush up, a good place to start is on our dataflow diagramming notation page

Exercise 1 | Exercise 2 | Exercise 3

Go to Top


First things first...

To do this exercise, you'll need to have read through our Acme Fashion Supplies case study. It would also make sense for you to complete Exercise 1 first but you don't have to as this one can be done on its own.

Get the Case Study as an ebook

Now you can carry it with you on your phone, tablet or e-reader and learn when it's convenient to you!

Client-site Business Analyst Essentials

All common ebook formats are included in the download.

If you have a discount code, enter it here:

Buy right now - only £4.50 (approx $6.50) - perfect for the daily commute!

...or you can peek inside via the ebook on Amazon

Companion Briefing Study

Our briefing study web pages, covering Requirements Analysis and Specification, are a complete guide to using a proven method and approach for business analysts. It's also available as a handy reference you can carry with you on your phone, tablet or kindle!

Client-site Business Analyst Essentials

All common ebook formats are included in the download.

If you have a discount code, enter it here:

Buy right now - only £4.50 (approx $6.50) - perfect for the daily commute!

...or you can peek inside via the ebook on Amazon