Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm stuck with one small part of my project. The main idea of the project is:
There are a customer, a bank and a shop as actors.
A customer wants to make an order but before he/she does it, the bank needs to check if the customer is on a blacklist.
If he/she is not, the bank puts the customer's and shop's details in a file and at the same time sends a credit note to the shop.
The next part makes me confused:
Customer personal information should
be protected following the General Data Protection Regulation
(General Data Protection Regulation - GDPR).
How can I implement this part in my diagram?
First of all, the use-case diagram is about user-goals. Use-case diagrams do not describe an order of what happens. So "before", "after", "at the same time" do have no effect on the diagram. If you're interested in the sequence of events, you should consider an activity diagram (i.e. flow of actions) or a sequence diagram (scenario).
So what I understand from your narrative is that:
actor User, in relation with the actor Shop (but is it really an actor?) has a use-case Order something
actor Shop (but is it really an acor or does your system ensure this?), in relation with the actor Bank has a use-case Control payment (make sure that the customer is not a known terrorist and ensure also that the customer has the money needed, probably in relation with the customer's bank).
The information you provide si probably very incomplete, so I leave you as an exercise the precise design of the use-case.
THe GDPR requirements do not influence at all your use-case model: it does not change the gloals, and it does not change the involved parties.
What might be influenced is the activity diagram and the class diagram:
the GDPR requires among others a privacy by design. So you cannot provide to the bank details that they do not need to know (e.g. what the customer purchased).
the shop is not allowed to get the blacklist either! The control of the blacklist is done by banks, so that the shop owner will not be tempted to refuse a sale just because of some similar naming.
THe only thing that could eventually influence your process, is the consent. Giving the consent and managing privacy could be a separate use-case, since its's a right given by the law and that some users want to exert. For example that the customer consents that his/her data is provided to another party. But in your case, it doesn't seem a big deal: in the case of a payment by the bank, this seems an obligation and the blacklist is in general a legal obligation not related to the the consent. So it will not impact your design, but only the wording of your privacy statement. So it seems that for you, GDPR will be more a legal matter to check with a legal expert, than an engineering one.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to model a use case diagram with two different front end applications. I have a web-based front end with different use cases than my front end for a tablet app. Some use case might have the same name but a different scenario.
My question is if it is a good way to use two system blocks in the diagram for each front end, or should I combine all uses cases in one system block? How can I model it in a UML correct and clear way?
UML use-cases and their boundaries
Setting the right boundaries is key to successful use-case modelling. According to the UML 2.5.1 specs:
A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure.
What matters is the system (i.e. the "subject" in use-case speak), the actors, and the behaviors that the subject offers to its actors (which, as QwertySO reminds us, supposed to provide value to the users, i.e. help to achieve the user's goal).
Use-cases focus on the users
From the point of view of your users, the expected functionality is independent of the from the front-endend. According to your comment, today:
the web frontend is targeting the actor admin with a use case: create a product. On the other side, the tablet front end is targeting the user to buy a product but is not made for the admin.
But tomorrow, your admins might want to use a PC, or a smartphone for the urgent tasks. And maybe some normal users would expect a voice interface rather than a tablet. The use-cases shall help us to focus on theses needs and not the way we are going to address them.
So, in principle, you should model your use-case independently of the front-end. You should not either show the split between front-end and back-end.
How to decompose the system
Use-cases are not meant to do functional nor structural decomposition. This kind of distinction is best performed in component diagrams that decompose your system into components and in deployment diagrams that map the components to the servers and devices.
If you have already a component decomposition in mind, and your component are independent, you could think of modelling the use-cases of a sub-system or a component. This is valid, since UML specs tell us:
A subject of a UseCase could be a system or any other element that may have behavior, such as a Component or Class. Each UseCase specifies a unit of useful functionality that the subject provides to its users
You can even model use-cases for a component, the actors being then the external actors and the other
But would this be helpful? You could have a use-case diagram for the admin application, with admin actors, and a system actor fo the back-end. But I'd not advise to go into that direction unless the app is a rich app with its own added value. If the app is just a front-end you'd just end-up with very redundant use-case diagrams (i.e. front-end UC and back-end UC would show the same use-cases) with a loss of end-to end relation to the real actor (i.e. the back-end UC would be associated with system actors corresponding to the front-end app, but you'd loose the direct link to the real actors).
In the end you might lose the main strength of UC, the focus on users and their goals. In exchange you'd have the burden to keep all the redundant models in sync but I don't quite see the advantage here. If you want to have more arguments about each alternative, you may also have a look here.
No, that's not good. Use cases are meant to show the added value a system under consideration delivers to actors of it. You are looking at implementation details. That is how the interface would look like. But for the added value this is completely irrelevant. You can create different implementations for the use cases so your collaborations will show either the one or the other front end. That will be part of the class design controlled by a requirement User may interact with frontend A and B.
I am trying to design a use case diagram for the following scenario.
I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals.
Depending on what the client is I want to know more or less of their info (name, number etc)
The use cases are different depending on whether the client is:
English
English and have used this service for more than 3 years
Foreign
For example:
The 1) English clients' orders are accepted only if they pay a small fee in advance.
The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)
The 3) Foreign clients' orders are always accepted no matter what.
This right here is where I run into trouble and need help with.
The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.
What are the most optimal actor choices here? I thought of going with English client, and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.
The use case diagram is not the right place to put this information. As correctly pointed out by #Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal.
This means that there is only one single use case in your scenario: "Order Goods". However, it has a set of preconditions. You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.
Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.
Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.
First of all, you need to clarify the super-ambiguous requirements:
"English client": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
"Foreign client": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
"Using this service more than three years": what with a foreign customer who uses the service for 3 years and then settles in the UK?
Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
"criminal record": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?
Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.
You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :
New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
Privately owned company: behavior is different since it can involve several persons,
Private individual
The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.
The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I understand that agile user stories are for human stakeholders for an app, product; but what if you're making a game (ie: tycoon) where you have AI characters performing actions or third-party entities that interact with the human player.
Do these entities have their own stories?
IE:
As a popcorn vendor I want to be able to ...
As a football shirt sponsor I want to be able to promote my product to last years Champions League Winner
Or am I overcomplicating it?
Thanks
Interesting question but consider the following two points:
A user story is a brief description of a features our customer would want in his software
Business people (of our customer) and developer team must work together daily through the project
So AI characters:
are really your actual customer?
can work daily with you?
Even if you are working on the "tycoon engine" AI characters interact with, so AI might be considered as your customer, I don't think they can work daily with you,maybe one day with some limitation.
The main objective of any good user stories is define the work and most importantly defines the value of that work.
So whatever situation it is, you will define user stories where the value is driven from the Business. In case of AI, if you believe that AI is running Business and Business is giving you money to build values then you should listen AI. Otherwise listen to whomsoever who is feeding you money (i.e. sponsoring your project).
In terms of entity, yes, AI can be an entity but at the end he has to interact with you and define these user stories. Of course Artificial Intelligence cannot do you for you. So someone is thinking on the behalf of AI.
Thus you can use AI as persona
What is persona?
A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people which are based on your knowledge of real users. - See more at: http://www.agilemodeling.com/artifacts/personas.htm#sthash.7ndZPbDx.dpuf
I have a scenario where a customer calls and gets an appointment at a garage. When drawing a UML Use Case Diagram, is the actor who is connected to placing this appointment inside the system (a) the customer, or (b) the employee?
The person that has their fingers on the keyboard and mouse is the actor. The person calling in is important from a business perspective, but not as important as the customer service rep that is interacting with the system.
Knowing that the actor is a CSR helps the screen designer and even the developer, because they will work from that perspective, ask for requirements or design clarifications from that perspective, and the system will be better as a result.
The reason the conflict exisits is because of the point of the project when you start drawing these use cases.
In your example, you already know that there is a CSR using 'a system' to make the booking.
However the design could have started from scractch. If this had happened the initial broad use case would have been 'a customer wishes to make a booking'. This could have lead to a number of differenc cases i.e. a customer will call a telephone number and an automated service will make the booking, a customer arrives at the garage and uses a terminal to make a booking or (as in your case) talks to a CSR (however that is i.e. phone or face2face) and they make the booking.
In many examples the customer would be the main actor in the system. However in your design the CSR is the one holding the mouse/keyboard/phone/pen or whatever and you don't need to design the iteraction between the customer and the CSR! Most societies did that years ago :)
It can be both. It depends. There is no single good way to model this. I would personally opt for the customer.
It is btw perfectly alright to include the phone as part of your system. So the boundary of a system does not have to be a defined by screen, mouse, keyboard. A printer might be included too as part of the system. I have written use case where it was quite essential that users printed some information and file that.
Who is the important actor here? The customer right? It is interesting to note here that Alistair Cockburn extended the actor and goals model of Ivar Jacobson with the actors and 'interests' model. His advice is to also think about who cares (or gets hurt) if user goal fails.
Is it important to get the actor just right? It is useful to brainstorm actors to find all user goals against the system. When you are confident you have found all goals, the actor is not so important anymore. Would you 'write' a completely different use case depending on this decision? Would a different system be build based on the outcome of this decision?
Who initiates the interaction? What is the event initiates it? This event is the decision of customer to call to make an appointment.
You could model customer as primary and employee as secondary actor helping customer to reach user goal. Both use phone and system to reach the goal, customer helped by employee. How they do that exactly is design?
Another consideration is that the 'actor' is a role. So you could use a role Appointment Maker. Some people care a lot about keeping job titles separate from roles as there typically some flexibility in roles that job titles perform.
There are also people who are of opinion that use of 'system' in describing use case is undesirable. They feel that it is a design/implementation decision and so they prefer more neutral 'Performer'. The Performer could be a system but also a human. In use case texts they use 'Initiator' and 'Performer' and in introduction of the use case text they explain that the 'Initiator' is in use case the Appointment Maker.
I personally think it would be fine and better if the use case was described as if customer was the one operating the system. The employee is just passing along information from system to customer and vice versa.
The book by Alistair Cockburn is a recommended read. His insights really helped me with questions like this one. It also helps to make sense of UML in relation to use case
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm currently busy writing business rules and user stories for a project I'm on. For a few stories there should be default behaviours like the following.
The application handles orders for representatives. When a order is placed for a certain region, it should pick a default warehouse (some regions have their own warehouses).
I'm wondering how you can define these behaviours for user stories. Are these considered business rules?
'Sounds to me like you just did an excellent job.
And yes - this is very definitely the kind of detail that absolutely BELONGS in a use case.
IMHO...
I'm wondering how you can define these behaviours for user stories.
They're expectations of the user that you're making explicit.
Are these considered business rules?
Yes.
The tricky part is this.
Story 1: The order is handled manually and a user picks the warehouse. This is front-and-center of everyone's mind. They talk about this at length.
Story 2: The order is handled automatically and a warehouse is picked by the system. This is assumed. What more important is that there's no actual user interaction here. It just "happens" without an actor seeing it or interacting with it. Since there's no interaction, it's not a very good user story. It doesn't lead to a fancy screen and the normal artifacts that go along with a proper user story where a user has interaction with the system.
When "automatic" or "default" things happen, the user story becomes a kind of degenerate case where it seems like less work needs to be done because there's no screens or pages or forms or interaction.
However, when "automatic" or "default" things happen some user somewhere actually does care and actually does need to see that it did happen. Even if it happens in bulk. Somewhere else, there's a variation on user story 2.
Story 3: Someone, somewhere, checks the counts and totals for the default warehouse assignments, including manual and defaults. Here, the default warehouse assignment is seen by an actor who is interacting with the system.
Automatic or default behaviors often highlight the need for review or audit or overview stories to be sure the automatic stuff really happened correctly.
From my point of view the default behavior is the main user stories and any alternative is another user stories.
So Yes you have to add this user story.
Thanks
M.Radwan