I am trying to model a data flow diagram in accordance with a requirement document. The document calls for a system with many roles that users can play, where it needs constant information exchange between different roles.
Here is an example of its functions, where 'Role A' is a reviewer or judge of some elements, and 'Role B' is a manager of those elements:
1. Role A is shown the list of elements (that are stored in a database), and chooses the items that he is interested in;
2. Role B gets a summary of the preferences of different Role A's, and assign the elements to them;
3. Role A receives the elements assigned to him, views them and leaves his feedback on the elements;
4. Role B summarizes the feedback from all Role A's, and decides which elements to eliminate from the pool.
Based on what I have learned, I would consider Role A and Role B to be different external entities, and so the DFD comes out this way:
DFD_is_this_good As can be seen, there are too many arrows linked to each external entity; while the processes are not connected. This is different from most of the DFD examples I have found.
So, is my work correct? If not, how should I modify it?

  • 1
    This looks more like a use-case diagram than a dataflow diagram. In a use-case diagram you would partition the diagram into 2, with the first and last bubble on their diagram. Since you don't indicate what data is flowing along the arrows, I am very suspicious of process bubbles like "Leave feedback". – BobDalgleish Apr 27 '17 at 18:32

My opinion: I think your model looks more like a business process diagram than a data flow diagram. I do understand that they are sometimes easily interchanged. Your model would have as well be done in such a way that the roles are depicted in stream lanes (bearing in mind that the data base runs beneath each action depicted in circles)

A data flow diagram would only show input of data into a system and output of data (information) out of a system.

| improve this answer | |

When your data flow has cycles, you're going to have a diagram like this. Data flow diagrams typically don't show ordering, so what you have is normal.

There are a few things you might do if you wanted to make it look more ordered:

  1. You should label the arrows with the data content that is flowing between the elements. Often when there is a cycle, showing the content that is being exchanged clears things up. For example, when there are two roles, customer and retailer, and the customer places an order, and the retailer sends a receipt. This does have a cycle; however, it can be inferred that the order is placed before the receipt is sent.

  2. You can step outside the traditional data flow diagram elements and augment the data flow diagram with numbers, if your diagramming system allows that.

  3. In your case, since you have so many responsibilities being done by both role A and role B, you might split the roles into sub-roles that are more functional, where each sub-role only has one input accepted and one output returned. The result would be that the data flow has fewer or no cycles. In your case the sub-roles might be Role A Chooser, Role B Assigner, Role A Feedback, Role B Finalizer. This would remove all cycles except the large one that involves the database.

    If you then wanted to show that these sub-roles are all the same role, that would be a different kind of relationship, which you might (1) leave implied by the naming of the sub-roles, (2) show on a different kind of diagram, or (3) add to this diagram using illustration that steps outside of traditional data flow diagramming (like a well-labeled dotted arrow).

And lastly, of course, you can combine the above.

| improve this answer | |

First of all you need to decide if data flow is the right diagram type for your main purpose, is it:

  • A: show how data flows
  • B: show in which order the steps of the process are done
  • C: show who is doing what

You might find an UML activity diagram with roles/actors to be a good alternative, as you seem mostly concerned with purpose B & C. The linked example borrows ideas from BPM where swimlanes show who is currently active in the process:


General points:

  • Define unique names for pieces of information and always use the same name. In your example you use item and element interchangeably.
  • If the diagram you draw suits your purpose, I wouldn't care too much about rules. Of course if your diagram is to be read by (many) other people, it gets more important that it mostly follows a standard which they already know.

If you stay with the data flow diagram, I'd suggest:

  • I'd like the arrows to have labels - which piece of information flows here? (Erik points this out as well)
  • Call the roles something meaningful, i.e. reviewer and element manager
| improve this answer | |
  • Well, actually it is not me who decides which kind of diagram to use, but it is an assignment by my teacher to model a given requirement document with DFD... (. _. ) So were there a better solution to my case, with a better understanding of 'how data flows' rather than merely showing the process order or responsibilities, if I had to take the purpose A as you have mentioned above? – Garlic Xu Apr 27 '17 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.