Dataflow Modelling (DFM)

Most important thing for you to remember: DFDs do not show nor imply sequence. I'll say that again do NOT try and show sequence on DFDs. Someone knowledgeable about the business system might be able to see sequence - but that comes later in Function Definition (described a bit more, below) where it is much more appropriately considered. If you find you're trying to show sequence, stop and remember, it's what that counts, not how or when.

On with Dataflow Modelling… but first, a conundrum:

Three different business analysts would likely come up with three variations on groupings and decompositions of the dataflow diagrams (DFDs) in the dataflow model, although the lowest level (elementary) processes will likey be very similar.

How does that work? it can't be very scientific! Well, the DFM is only a stepping stone to get to the real view of processing.

All these possible ways of getting to the elementary processes is of no matter because the DFDs will have served their purpose - to get to function definition where it's then resolved. In function definition, the lowest level processes are re-grouped according to the users' view of how they will organise:

• themselves (multi-skilled teams / specialised groups / leaders / managers)
• the processing (work flow through functions, on-line, batch)

to support their activities. They'll be thinking about who is to do what and in which sequence and using this to decide on how to group - or split - elementary processes.

You'll see on the next slide how the DFM cross validates with the LDM.

So what's in a dataflow model?

(If you need to, see a description of the notation used in dataflow diagrams here...)
Well, you'll need a context diagram and at least a top-level DFD (it's important that you never attempt to show sequence on a DFD - if you manage it, the DFD won't fit in with the other techniques in this Briefing Study).

If you only have a need for a top-level DFD then each process on it will be an Elementary Process and you will describe each of them. The description will depend on the variant of the DFM you are producing.

If it's the current physical, then you will be describing how things are done, warts and all. You'll describe where and by whom, you'll record any known or perceived issues with the current process (these are likely to turn into requirements for the new system to address).

If you have a second-level DFD for any of the top level processes, then you only describe the most elementary (i.e. lowest-level) processes - these are called Elementary Process Descriptions (EPDs). This means that you might have a mixture of EPDs, some for top-level processes (those that aren't decomposed) and some for second-level processes (i.e. those that are decomposed). For larger or more complex projects, you might end up going down to a third or even fourth level DFD. If you do, you'll have an EPD for each at the levels where they aren't decomposed further.

You'll need to describe the data that flows across the boundary of your DFDs and into or out of the outside world. These I/O Descriptions need to go to the entity level to begin with (e.g. The dataflow coming in from a customer in my web sales example would be described with reference to the Customer, Order, Order-line and Product entities).

There'll need to be a description of all the external entities involved on each dataflow - a visitor (who in placing an order and becomes a customer), PayPal (my on-line payment processor), me (on a whim I do stuff to that transforms data in my business system - like archiving off old data), my Book-keeper (who needs to know about sales and who sometimes has to issue VAT receipts), my web server (I download the log files and use them to assess visitor statistics and, in rooting around, try to find any correlation with searches they make to find my website and any sales made).

You'll have cross referenced the datastores on your DFDs to the entities in the Logical Data Model, so you can be sure what's where. In the logical variants of a DFD (Current Logical DFD, Required System DFD), an entity can appear in only one datastore - you can't have customers orders held with some in the orders datastore and some in the invoices datastore - they're in one or the other, make up your mind! Of course, if you're documenting the current system, warts and all - or if it's a clerical / manual store then that's a different story.

As you're DFD'ing you'll record in the EPDs any non-functional aspects such as security and access, volumes, audit requirements. It's also helpful to note how any common exceptions are handled. And if you discover any business rules, you'll want to record them in the EPD, too, together with typical and peak volumes of the various activities, customers, i/o dataflows etc.

As you move to the required system DFD you'll end up with a logicalised view of the current system on which you can start to overlay the changes brought about by accommodating the requirements. New and modified processes will result - some on the current system will be pushed out of scope and some may be brought in scope. There may be new user roles to provide for and new or updated datastores to hold new data.

In short the DFM is a key product holding a structured view of analysis results, initially, and finally supporting the development of the requirements specification (in conjunction with the other major technique products, of course).

Some other aspects of DFDs

It always makes sense to show major operational reports and enquiries as dataflows as they will need I/O Descriptions but try to keep the number of management information type of reports to a minimum as they just tend to clutter a DFD without adding much value. Record them separately in the enquiries section of the Requirements Catalogue.

Often in the early stages of a project, during DFD'ing of the current business system, it helps to make the initial DFDs much richer than in the later stages. Purists wouldn't necessarily allow flows between external entities or showing of iconic representation of external entities. But I firmly believe the business analysts' maxim- if it improves user understanding and buy in, find a way of doing it.

Other activities being done in parallel

Requirements

As you are DFD'ing and EPD'ing you'll be bumping into potential requirements to be validated with users. Put entries for them in the requirements catalogue and mark them TBC (to be confirmed).

User / Roles Catalogue

You'll have or be developing a user catalogue, listing all the people involved together with their job titles, and you'll have or be developing a user-roles catalogue showing how the job titles map to the various roles in the business system. The catalogue is a living document, growing and changing as you move from the current system to the required system DFM .

LDM

As mentioned above you'll be bumping into entities on I/Os that end up in or come from datastores. You'll be validating and challenging both the LDM and DFM as you refer between them. You must, of course, achieve consistency between them.