Use Case / UML scenario for App and an external system

Question

I am currently working on the use cases for a car sharing app.

The simple diagram for the process of registration looks like this:

At the moment I am stuck with the following scenarios. When a new customer is registered, a process is carried out at the head office (central)in which the following points are checked

Scenario 1 - Head office side:

1. The identity of new customers is carried out externally with the post. Two possibilities: presenting the identity card at a post office branchor carrying out by video. 2. The verification of the customer's bank details is carried out externally with the bank. 3.The system will verify that the contact details (email address) are correct 4.the consent to the GTC has been obtained

My sketch for the confirmation process looks like this:

How do I show that the system verifies that the contact details (email address) is correct ? How do I show that consent to the GTC has been given ?

Scenario 2 - Customer's side: A customer can view and edit the information of his registration.

1.Edit profile data 2.Edit contact information 3.Edit bank details. If information is changed during editing, verification must be carried out again by the head office.

What would the two use case diagrams look like ?

Answer 1

One or two apps?

(Posted before diagrams were added to the question)

Nothing in the narrative says that you need two systems. It's too early to decide about system architecture. You could have the following variants, each with pros and cons:

• one and the same system (e.g. post office and customer access it via the web);
• one and the same system that is accessible using different components on different devices (e.g. a rich client in the post office, a web interface for the customer on her mac/PC and a mobile app for a customer when using a smartphone);
• several independent systems (e.g. a back office in the post-office, and an independent app that would connect not only to the back office, but also to other back-end services e.g. from other companies).

But how do you want to decide before first knowing what is needed and how the needs are related?

First, you have to understand the big picture of what's needed. Focus on the users not on the inner details of your solutions, as explained in the UML specifications:

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...)
a UseCase (...) specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders (...)
(...) without reference to its internal structure

Look into your narrative to find actors (people, organisation, responsibilities), their goals (what do they need to do?) and how they could relate to each other. Just try a first sketch.

Your current model

(Posted after the diagrams were added)

I still see no reason to go for 2 distinct systems. You are working on a solution for car sharing. It may have different sub-systems/components, but the actors do not care. And neither does your customer. But:

• If you'd go for two independent systems, you'd draw two disginct diagrams, and in each diagram you'd have an actor representing the other system that interacts with the system under consideration. As said, this makes sense only if it's an independent system.

• In your case, I could imagine this for the bank account verification and the video identity verification: unless you intend to develop your own super-secured AI component capable of doing this, you'd probably outsource this to a specialized company, that may offer this service via an automated API.

The identify verification is at a different level of details than the other use-cases. You may want to show it in a separate diagram, in order not to pollute the main diagram.

And lastly, your second diagram has some issues:

• the arrows of extend and include should not following the same direction: the target of an include is the included use case whereas the target of the extend arrow should be the use case that is extended (and not the use case that is extending the normal use case as you have shown).
• ID correct and Bank correct are states. Use cases do not show states. The end-state can be specified in the description of the use-case but not in the use-case diagram.
• Post office, Bank account, Video seem to be use-cases, but they are not well described.

A possible diagram could therefore be:

Note: I'd personally prefer specialization of Ensure identity. This corresponds more to the reality that there are two very distinct behaviors. But extension is ok.

Answer 2

Just to stress this fact: you do NOT describe a scenario with use cases. A use case is "just" to show the added value a system under consideration delivers to one of its actors. What you are asking is functional decomposition and that's just plain wrong. You would describe a scenario with an activity diagram (or as plain text like in the Cockburn way).