How to represent a complex use case where every step of the main flow can have multiple scenarios (alternative or error path)?

user_7927757 0
Viewed 189

Little background

I'm new to writing use cases and representing their scenarios. I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship. I understand that include and extend relationships need to be used only when necessary. Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.

Main issue

The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram. I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.

What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence? I have attached a simplified version of the activity diagram for "Initialize" use case. As I mentioned, each activity can have many scenarios. For example

  • "Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
  • "Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity. Same goes for every other activity in the diagram; many steps with exception or alternative paths.

Can I map these on one sequence diagram for the "Initialize" Use case? My attempt to put all these on one sequence diagram failed. I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :( What is the best way to deal with such level of complexity? Could you provide some good examples.

enter image description here

sysml activity-diagram use-case sequence-diagram uml
2 Answers

The only way to represent a complex use case, where every step of the main flow can have multiple scenarios, is fortunately very simple:

enter image description here

The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you'd probably looking at too much details. Or the things are not as clear as they should.

The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.

By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagram, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one UC and forget it for the others.

Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:

  • user-stories are generally used without use-cases. Complex erquirements are described as an epic. The epic would then successfully be refine it into user-stories, that fit in an iteration;
  • it is possible to structure such user-stories according to stakeholder goals and tasks. THis approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals.
  • use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermeriate user-stories.

Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reegineered appraoch that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developped in one iteration.

user_37234230

A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.

Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:

rake

See UML 2.5.1 specification, section 16.3.4.1 for more information.

user_54830790
Related