Data structure and flow
Between the two of them, basic use-case and business-process documentation may provide enough information to make the structure and flow of the data through the system obvious, or at least transparent enough that development won't need any additional information. The Refuel process we've been looking at probably falls into that category, but let's see what a data-flow diagram for it might look like anyway.
The data that's coming in (the Refuel Data in the flowchart) was defined earlier in Use Cases section, and at least some of the related data flow was also noted, but having some names to associate with those values, and knowing what types of value they are, will be helpful:
odometer: The current odometer reading (probably an <int> value)
fuel_quantity: The amount of fuel used to fill the truck (probably a <float> value)
truck_id: The truck being refueled (a unique identifier for the record of the truck in the application's database – to keep things simple, we'll assume it's also <int>)
During the process, a refuel-efficiency value is also being created that might need to be passed along to the Route Review alert and/or Maintenance alert processes:
re: The calculated refuel-efficiency value, a <float> value
In this very simple case, data elements are simply being noted, by name and type. The diagram indicates where they start being available, or when they are explicitly passed to a process – otherwise they are assumed to be available all the way through. Then the data elements are just added to the previous flowchart diagram:
In a more complicated system, something that has more complex data structures, more data structures in general, more processes that use those, or any of several combinations of those factors, a source and destination oriented flow-diagram may be a better option – something that doesn't really pay attention to the inner workings of the processes, just to what data is needed, and where it comes from.
