What are some good alternatives to use cases when the system has no actors?

Question

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?

Answer 1

"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.

Answer 2

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.

Answer 3

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.

Answer 4

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:

• Use case diagram
• Sequence diagram
• Class diagram

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.