I'm working on a software and hardware system which is completely autonomous in its activities. There is no user involved and one external system which data is sent to. There are a lot of different activities and processes going on inside the system, but they cannot be modelled well with use cases as these are all internal. There is, however, one use case and that is sending the data to the external system, but it is not very representative of the system.

I am developing this project using SCRUM and wanted to have some use cases or user stories to base my sprints on or build part of my backlog with. In our team we have traditionally used these to do this. I was thinking about using something like process models for these activvities but it seems non-standard and slow or hard to explain to my manager and client.

What are alternatives to representing a userless system in such a way that it is clear to business and IT stakeholders and, less importantly, can be used as the basis for agile sprints, much like use cases and user stories?

  • 1
    The system is the actor or at least the parts that are doing something.
    – JeffO
    Commented Mar 2, 2017 at 10:39
  • @JeffO The system would be the scope or system boundary of a use case diagram for sure, but the internals don't belong in a use case diagram IMO...
    – Robbie Dee
    Commented Mar 2, 2017 at 10:52
  • You have a complex system generating lot of data and sending all to an external client then what about to cut your system in subsystem and use each subsystem as an actor ?
    – Walfrat
    Commented Mar 2, 2017 at 12:17
  • @Walfrat Hammering in a nail with a boot doesn't prove it is the right tool for the job. The OP rightly has misgivings that use case diagrams are a good fit here. Subsystem detail does not belong in a use case diagram.
    – Robbie Dee
    Commented Mar 2, 2017 at 14:33
  • @RobbieDee - Then don't create a use case diagram. Put it in a user story or anything else to communicate what the thing does, so the manager can understand it. The point is, this app/service/system is doing things whether it is a human or not.
    – JeffO
    Commented Mar 2, 2017 at 17:14

4 Answers 4


"Actors" can be whatever you want the actor to be in order to convey the information that you are trying to communicate. There is nothing that requires an "actor" to be a person or even a tangible thing. An "actor" can simply be a concept if that conveys the information effectively.

The most important criteria for identifying actors is what triggers an action at the level of abstraction you want your use-cases defined at. If the "trigger-er" can be identified then it is a legitimate candidate for being an "actor". The "trigger-er" can be a person, it can be a sensor, it can be just about anything, it can even be time. There are even cases where you may not even want to be very specific in identifying an actor for a use-case because you may not know or you may have a multitude of options to choose from.

Most people have the mis-perception that an "actor" has to be something external to the system. That is absolutely false. There is no such thing as something being "external" to your system if it has to interact with your system. EVERY "actor" in EVERY use-case that I have ever designed and implemented has required an interface implementation representing the "actor". Just because an actor shows up as being external on the use-case diagram doesn't mean you won't have to write code/build hardware that implements the interface to that user. In other words, just because the actor is modeled as being external to the system doesn't mean they aren't part of the system. In fact, you almost certainly don't want the interfaces to the actor getting described by the use-cases as that tends to turn your use-cases into novels.

In summary, I contend that your claim that there are no actors is not correct. Instead, it just appears so because of your misunderstanding of the purpose of actors in the context of use-cases. Identify what triggers the actions in your system, give them a meaningful and representative name and the odds are pretty good that they'll make decent enough choices for being actors.


Your system might be performing its activities autonomously, but it will still be true that those activities are performed to achieve an objective that benefits someone.

If your system doesn't provide any benefits, then nobody would use/buy it (except perhaps as a curiosity). If you can articulate those benefits and who benefits of them, then it is possible to write user stories. Use cases are less suitable for autonomous systems, because use cases are more focused around user interaction.

For example, if you have a system for heating your house, then a possible user story could be:

As a resident, I want the heating system to start heating my house if the actual temperature drops more than 1 degree below the desired temperature, so that I am comfortable in my house.

Here there is a clear benefit for the user (a comfortable house) and the system is also expected to provide that benefit without the user having to take explicit actions.

  • While the GWT pattern is great for describing system detail, I can't help but think there is a better way the OP could present this to their manager.
    – Robbie Dee
    Commented Mar 2, 2017 at 13:11
  • We have a clear end-user, so that might be a pretty good idea actually!
    – Zimano
    Commented Mar 2, 2017 at 20:05

Use cases and user stories are one method of capturing requirements. There are other ways of capturing requirements - from "shall"-style statements to various tabular or graphical models. Getting into all the options for how to elicit, capture, analyze, and manage requirements is beyond the scope of a single answer here, so I'd check out some other questions about requirements, or I can also recommend reading Karl Wiegers and Joy Beatty's Software Requirements (3rd Edition) and Joy Beatty and Anthony Chen's Visual Models for software Requirements for more specifics.

As far as Scrum is concerned, the Scrum guides do not require that you use any particular methods for capturing requirements. The requirement is that you maintain a Product Backlog that is a priority-ordered list of the work that you need to do. You refine this backlog, add dependencies between work items, and estimate the work. The Sprint Backlog is a subset of items from the Product Backlog that you are working on in the current iteration. Although it's true that many people use user stories as items in the backlogs, it's not called out as a rule of Scrum.

  • Completely agree; scrum doesn't require particular methods but we have traditionally used use cases or user stories for creating part of the product or sprint backlog, but found it hard to adapt our usual methods to this new system to be developed. My question might be a bit broad in that regard.
    – Zimano
    Commented Mar 2, 2017 at 20:02
  • 1
    @Zimano Given the information, it's too broad to give anything more specific than "change your methods - find a new technique".
    – Thomas Owens
    Commented Mar 2, 2017 at 20:04
  • I was asking for an alternative to use cases when there are no user interactions with the system, in that regard I was planning to change methods by asking about this technique. What could I do to improve the question more?
    – Zimano
    Commented Mar 2, 2017 at 20:05
  • @Zimano I don't think you need to improve the question. Any method of capturing requirements can feed an iteration just as well as any other. I once ran iterations with a formal software requirements specification. The answer to your question is "any of them". If you want a more specific suggestion, I'm not sure what else you can provide.
    – Thomas Owens
    Commented Mar 2, 2017 at 20:14

All you have identified is that use case diagrams are unsuitable here. Without knowing the details of your system, it is pretty hard to advise.

Although UML has many diagrams, I rarely see a system modelled with anything other than these 3:

Maybe see if the latter 2 are a good fit for you.

This of course assumes you wanted to stick with UML. As others have intimated there is a myriad of possible methods for achieving the same.

N.B. you mention Agile/Scrum but that really has little bearing here.

  • 1
    State machines can be handy (whatever UML may call them) Commented Mar 3, 2017 at 9:24

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.