Data Flow Diagrams (DFD) modeling doubts

Question

I have some doubts about what would be the most correct way of modelling some things in DFDs. I have the following requirements for a system for a hospital:

1. "All doctors agendas will available for patients in the website. The patient will be able to select any doctor"

   My questions about this requirement are:

1.1: Would "Obtain Agenda" and "Choose Doctor" be different processes? I suppose that they should, but I'm not 100% sure.

1.2 Can "Obtain Agenda" be modeled as a process that simply read from the "Agendas" data store and generates an output flow that goes to the "Patient" external entity? Or would an input flow be required to represent that the patient has first to ask for the agenda? I'm more inclined to represent it as just an output flow because I see that asking for the agenda is more a control flow than a data flow. Am I correct? If also including an input flow is better, I assume that in that case I could use a dialogue flow in the context diagram instead of separate input/output flows for asking the agenda and obtaining the agenda, correct? I've uploaded the following image to show graphically what are the 2 versions I'm referring to the point of view of the context diagram: https://i.stack.imgur.com/wjDp4.jpg

2. "A patient can change the specialist doctor it has assigned for a $10 fee. Doctors can change the specialist assigned to a patient without cost for the patient"

2.1 Could I model this with a single "Change specialist" process? In that case, how would I represent that the payment of a fee is only required if the change comes from a patient and not from a specialist?

Apart from these questions about requirements, can anyone recommend me a good free software for drawing DFDs using the METRICA syntax? That syntax is the one that can be seen in this links:

https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-flujo-de-datos/

https://administracionelectronica.gob.es/pae_Home/dam/jcr:da7d91fa-d6bd-467c-be32-a72e27c603b3/METRICA_V3_Tecnicas.pdf

Thanks for your time.

Answer 1

1.1. The requirements are not meant to be mapped one to one with DFD processes, unless you want to make a very detailed diagram:

• The process seems to be Book appointment the selection of the doctor and the viewing of free slots in a doctor's agenda are details of that process.
• Of course, you could imagine a process Select doctor followed by a process Obtain agenda, followed by a process Book an agenda slot. But then you've started to define the user interface. Moreover, you'd need to add a lot of arrows back to the previous step, but with no data. This would be overkill.

1.2. Conclusion: Obtain agenda should not be a process. Users obtain by the way nothing: the agenda remains in the data store. And I doubt that patients would have full access to the agenda and view appointments of other patients with their name. In fact, the process Book appointment would read free slots from the data store Agenda, and would write in the data store new appointments. The rest is functional requirements for this process.

2. Again, a DFD shows the flow of data between data processing processes. External actors who interact with the system can be shown as entities. But DFDs are not a business process analysis notation. So it seems reasonable to have one process Change specialist with two entities that can provide input. The rules that apply (who can do what, under which conditions and at which price) are functional specifications of this process.

Tools: this part of your question is out of scope. We do not recommend tools. Btw, looking at your documents, it seems that Metrica uses its own syntax for the processes. It seems inspired from IDEF3 boxes, but top down, which is different from the usual DFD notation. I'm afraid that you'll not find a free modelling tool and that you'll have to use a simple drawing tool with an appropriate template.