How should I model the external entity and actor in my DFDs and UC Diagram for an app used by the QA officer (and possibly other staff) in an agency?

Quality Assurance Officer is the role a person serves in your organization, not any single human being.

Let's say I am your QA Officer: Greg. I quit my position because I won the lottery and now I'm filthy rich. Has my departure fundamentally changed how the agency operates? Is my absence as QA Officer causing the agency to completely redesign their processes? No. The position of QA Officer is vacant. The agency will delegate this responsibility to another person — you, for example.

I win the lottery and now your boss says, "Bronwyn, you are the QA officer until we hire Greg's replacement."

So now you fill the QA Officer role. A single human can serve multiple roles within an organization. We have an expression for that: wearing many hats. The fact the human named Bronwyn is also the QA Officer does not fundamentally change the diagram, because as soon as you do "QA Officer" stuff, you are no longer serving the role of developer, you are serving the role of QA Officer. The diagram is still valid.

Let's take the situation where the QA Officer wants to delegate this to other people in the future (without winning the lottery). Again, the delegates are playing the role of QA Officer. In my opinion, the diagram is still valid. If the distinction between "QA Officer" and "delegate" is meaningful to your organization, then consider giving the delegates a different name. The trouble is, UML doesn't prescribe how to name things like this. Ask the QA Officer or management what to call these delegates.

To be honest, "QA Officer Delegate" isn't a bad name, but I recommend consulting people within the agency, because they might have an organization-specific name for this, and it's the people reading these diagrams that matter.

Disclaimer: if by “agency,” you mean government agency, or if the UML diagrams you're dealing with are made for legal purposes, rather than technical ones, then refer to the regulations, instead of asking for advice on SE.SE. The following answer assumes you work in an ordinary, non-regulated company, and the UML diagrams would be used as technical documentation only.

Imagine for a moment that you're working on a e-commerce website. You are asked to add a feature where a given person from your company—let's name him Jeff—can view a specific set of charts that are then used to produce a business report that shows how profitable the e-commerce website is.

Your manager has mentioned that he might authorize other staff in the company to also use the system to view the charts. Oh and by the way, one might need to access just some reports, but not the others, and we might need the reports to be funny dynamic and customizable, whatever that means.

We also want the app to remain usable for the company in the future, even if Jeff is replaced.

How would you implement this feature?

Very likely:

1. You won't find a single if user == 'Jeff' in your code. The fact that Jeff's in charge is perfectly irrelevant. Instead, you'll be using a role.

2. The system would make it possible to add other persons in the future. The only thing one needs to do is to assign those persons to a given role.

3. You would think twice about the exact name to use for the new role. Maybe Jeff would be a “report viewer”? Or “data analyst”? Or “business intelligence officer”? Or something more fancy?

4. You'll discard the fuzzy and unlikely idea of dynamic and customizable reports, to follow YAGNI and KISS principles.

Now, back to your UML diagrams. You can roughly use the same principles. Let's see.

We also want the app to remain usable for the agency in the future, even if the current QA officer is replaced.

Obviously, don't mention the person's name in the UML diagrams. It would be inconvenient to have to change your documentation just because the person left the company. Using a role is not only easier to do, but also easier to understand. If I'm new at your company and I see a diagram that says that Jeff can do this or that, the first question that pops out it “Who's Jeff?!”

Now, the important part is how to name the role. “QA officer” sounds good for me—it's clear and to the point. If this is what the role represents, go for it. If, on the other hand, the actual actions that would be allowed by the system to the persons having this particular role have nothing to do with QA, then you have to look for a better name. The terms “agency staff” and “agency personnel” don't seem specific enough. Doesn't everybody working at your company qualify?

But he has mentioned that he might authorize other staff in the agency to also use the system to help with data cleansing.

Define might. Unless there is something very tangible behind it, I would apply YAGNI and disregard anything that might happen somewhere in the future. Do the diagram for now, to document the current state of the system.

When and if the system changes, adjust the documentation accordingly.

(And, by the way, I see that you're new to Stack Exchange, so warm welcome. And congratulations for your first question here.)

Good answers already here, but I think there is a crucial point missing here. Ask yourself:

Who is the audience for these diagrams?

When the primary audience is this mentioned QA Officer, and when you are under the impression he has trouble to understand that the actor "QA Officer" in your diagram isn't necessarily himself in person, then it may be helpful to find a different designation. This could be the case when "QA Officer" is more than just a role in your diagram, but also an official, specific job designation in this company.

If that's the case, you should probably find a different term. Call it "QA system user" or "Cleansing system user", or "QA staff", or whatever you think will be understood best by the people involved in analysis of the requirements for this system.

In case the primary audience is just you or your development team, you are probably overthinking this.

I understand that you are quite at the beginning of the analysis, and according to the claim on non QA users, it is possible that along the way your stakeholders will realize that QA officer (and the people to whom he/she will delegate authority) and non-QA users have different roles in the business processes and system usage.

You need to highlight this now, or your project may become very difficult very soon.

One elegant way to do it is to distinguish among the actors: All users, QA users and non-QA users. This will force your customer to take a clear position on the respective involvement in the use-cases (formally in UML you can use generalization to be cristal clear).

It's surprising that non-standardized DFD is in use next to UML use-cases, as UML offers the more standardized activity diagrams instead. Align the approach for EE with the approach proposed for the actors, and for the same reasons: EE are source or destination of dataflows and you need to know who is really meant.