Secondary Actors are actors that the system needs assistance from to achieve the primary actor's goal.

If a external printer system to the system under construction is commonly shown as a secondary actor when defining the system under construction use cases, why databases (which are also external to the system under construction) are not?.

The only difference I see between the database and the printer in this context is that the database service is to CRUD data under the system demand, and the printer print some paper under the system demand.

If database is not secondary actor, why other external systems used as a content manager/engine or external filesharing systems (dropbox for instance) are shown commonly as secondary actors?

  • 1
    Actors also initiate actions, something a database or printer generally does not do. Oct 31, 2019 at 0:11
  • Primary actors initiate actions, secondary actors dont.
    – MABC
    Oct 31, 2019 at 8:30

3 Answers 3


It all depends on the boundaries of the system under design.

Personally, I've never included printing systems as actors when modeling use cases of a system. When modeling a use case about printing, I would handle cases such as no available printers attached to the system or error responses. But I wouldn't call out a printer as an actor. The same goes for file systems, input devices (keyboards and mice), other kinds of output devices.

Unless there's a good reason to do otherwise, I tend to consider all of these things as part of the system under design. The software that I'm building is residing as a subsystem inside of a larger system that contains these resources.

There are times when an actor may be a non-human, but I'm struggling to think of a time when a resource like a printer system would be one.

  • you says "Unless there's a good reason to do otherwise, I tend to consider all of these things as part of the system under design." What kind of good reasons do you come up when thinking about putting secondary actors in the use case diagram?
    – MABC
    Oct 31, 2019 at 9:05
  • @MABC See my last paragraph. All relevant actors would be identified, but I can't think of a time when resources (printing systems, file systems, databases) would be actors. But there may be cases out there.
    – Thomas Owens
    Oct 31, 2019 at 9:21
  • @MABC, one case where I would model a database as a secondary actor is if I am asked to build a system that interacts with an existing database and I have no authority to make changes to the interface and/or schema used by the database. The keywords here are existing and no change. Oct 31, 2019 at 9:25
  • @ThomasOwens what makes an actor to be relevant? I cant think about some secondary actor that can not be modeled as a resource or subsystem used by the system under desing to deliver the use case goal to the primary actor. My entire point is what are the advantages to put secondary actors in the use case diagram or describing the interaction with the secondary actor in the use case specification?
    – MABC
    Oct 31, 2019 at 9:57
  • 2
    @MABC, by modelling it outside the scope of the system, you give a clear message that there is no design freedom in that area. As the system still needs to interact with the database, it should be shown as an actor. If you would leave it out, then the conclusion can be reached that the value of the use case can be delivered without interacting with stuff outside the system being created. Oct 31, 2019 at 13:48

I came out with this conclusion:

When writing requirements

If the client DOES NOT demand to use some secondary actor (some existing third services, databases…)

Then using the secondary actor is a design decisión and we should not think about this when writing requirements. We should only model how the users use the system (its goals) and detail this interaction.

During design phase the proper people will think about what tools and external services will be used in order to deliver the requirements.

If the client DEMANDS to use some secondary actor (some existing third services, databases…)

If the secondary actor behaviour impact in how the system interacts with the primary actor I would add the secondary actor to the use case diagram and include it in the use case specification.

If the system should communicate some event to the secondary actor during the realization of some use case (triggered and carried out by a primary actor) I Will write this requirement as a note in the use case specification.

If the secondary actor does not impact in how the system interacts with the primary actor I will write that the system should use some existing third service/system (as it is demanded by the client) as a non functional requirement but wont add this actor to the use case diagram or any use case specification.

When writing design

When designing use cases specification (a RUP activity) with UML diagrams I will describe the relevant external systems the system under construction uses and how the system integrates with this secondary actors.


In many/most cases the database is not secondary.

It is an integral part of your design, its attributes and structures are part of the system being built.

So unless the database is under control of an external system (e.g. you get an employees name and contact details from the personnel systems database) it is not secondary.

In the same way that you do not include the file system, the cpu or the network card as secondary actors you do not include the underlying DBMS software as a secondary actor.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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