Unsure if this is the right place to ask such question.
I have to define use cases for a Windows Service application and I have some issues.
It regards a Windows Service application that is programmed to perform some tasks periodically.
One of the use-cases is "The system looks up unpaid orders and sends reminder to customer".
Alistar Cockburn's definition of an Actor: "An actor is anyone or anything with behavior."
My questions now are:
1) In my scenario, who is the Actor or Actors?
2) Who are the stakeholders / interests?
I am not Mr. Cockburn, but...
Actor should be anyone (or anything) who comes into touch (/uses) with system. <= Easier definition for me.
1.) So in your case, customer should be actor.
2.) I was always creating use cases with just use cases and actors.. what are stakeholders and interests? They are imo just another actors. If not, it just adds complexity to tool, which should be simple. (IMO)
Btw: Is "The system looks up unpaid orders and sends reminder to customer". really a use case? Isn't that a scenario (part of a use case)?
Edit: Use cases should describe behaviour from end user point of view. So it really should be something like:
Scenario: Pay for order
Actor: Customer
Flow:
1. Customer requests unpaid orders from system (not specifing how).
2. System provides (shows) unpaid orders.
3. Customer chooses one order
4. System process selection and shows detail about selected order
5. Customer requests to make a payment (again not telling something like 'customer will click on button called "pay"')
6. System requests payment details from user
7. User fills details
8. System validates entered data
9. IF successful:
a.) Order payment is comleted, system redirects user to XXX.
10. ELSE go back to step 7
It might be a bit long... but that's basically how I am doing scenarios (which are grouped into one use case).
Related
So suppose I want to make an e-commerce system using Event-driven architecture with Event-sourcing. Let's say the user want to buy a product and its price is 1$, but I miss calculate and it becomes 2$. Now the user would lose 2$ from his wallet instead of 1$. So if it was CRUD I could just simply fix the bug and connect to the database host and fix the user wallet (also give him some apologize). but in event-sourcing, as far as I know, we should not edit or delete event (only append) since it's single source of truth. So how should I deal with this kind of failure? One thing I can think of that's to create an admin page which can publish any kind of events and fix it like this.
AccountCreatedEvent { userId: 1, balance: 3 }
ProductPurchasedEvent { userId: 1, price: 2 } // **miss calculate price should be 1$
DepositMoneyEvent { userId: 1, amount: 1 } // manually fixed by admin
I know it seems weird, but what if I really have to fix the bug and also valid the data how do we achieve that in event-sourcing
A common answer is that you look to the domain. For example, what business processes exist to mitigate the contingency that a customer is over charged?
Does our business have a process for refunds?
The "right" answer is to implement that process. The resulting history will look like an event that over charges the customer, and later another event that refunds the overcharged amount to make things right.
This is, of course, exactly your fix it and apologize approach; the main difference being that we treat the error correction as part of the system, rather than being something we improvise.
Memories, Guesses, and Apologies (Pat Helland, 2007) is a good starting point.
Another example would be a fault where the system did the right thing, but wrote down the wrong information. A common pattern here is to process this mistake the way it would be done in accounting - an event is produced to "reverse" the transcription error, and a new event is created to introduce the correct accounting.
Again, notice that this correction process is part of the domain of accounting. Our job here is to faithfully re-create the error correcting processes that already exist.
The basic pattern is the same throughout; we add more events to the system to correct the mistakes (and more events to correct mistakes in the corrections; it's turtles all the way down).
When you've got processes that are triggered by the events that appear in the stream, you may end up playing "chase".
We overcharged the customer, but this meant that the customer was automatically enrolled in the VIP discount program. When we fix the error, do we also need to remove their VIP status? What happens to the discounted purchases they made before the error was discovered?
For my internship, I need to implement a blockchain based solution to manage a drug supply chain. The management of this supply chain implies to track-and-trace (geolocate) a drug on the chain, but also to monitor the storage temperature to see if the cold chain is respected. For that I created a mock-up of the POC my Dapps (https://balsamiq.cloud/sum5oq5/p8lsped)and also I wanted to prepare myself by doing a UML and a use cases. However, I didn't find a lot of information about blockchain's UML and use cases besides two literatures which were quite different, so I don't know if what I did was correct or not...
The users of my Dapps will be the following ones:
The stakeholders (Manufacturers, Distributors and Retailers) which will use the Dapps to place orders and also monitor them. They also can search in the historic a specific order. Finally, trough IOT sensors they update the conditions of the order (temperature & location).
The administrator which roles is to update the Dapps and its rules. But also to add or delete user while also defining the rights that they have on the blockchain (I intend to use a permisionned blockchain). Finally, they are also here to help in case of technical problem.
The Dapps that I'm thinking about works in the following:
A user, the customer, can place an order (a list of products) to a
certain seller and choose the final destination of the order.
The order is then put together before being shipped or stocked in the
depots of one of the stakeholders (distributor or retailer) with a
description of the stocking and/or shipping condition of the product
(for example the product must be stocked or transported in a room
with a temperature of less than 5°C). During the shipping and
storing, an IOT device will feed the drops with the temperature and
geolocation of the product by updating the data each 5-10mn.
Obviously they will be a function that allows all the users to see
the history of the order passed and search inside a specific order.
In case where the temperature doesn't respect the temperature
recommended, then the smart-contract send an alert. The same if the
collocation of the product is "weird" like being in some European
countries and not in an Asian country, an alert will be sent again by
the smart-contractual. Finally, in the case where the product is sent
to the asked location by the customer, then the money for the order
will be paid to the seller.
So based on what I explained, I came here in hope that someone tell me if the use cases and UML that I did were correct or not.
I thank in advance anybody who'll take the time to help me.
Scenario: (sort of Call center) (1) Customer Requests technician. (2) Request goes into queue for technicians to see. (2b) Customer gets confirmation email about submitting data (3) Technicians Process request (3b) everyone gets email (4) Request is completed (5) Technician submits data for completed request (6) Closed Request.
So two actors on the left. Not everything has to connect right? So for customer getting emails and submitting data is drawn.
For Technician actor they have processing interaction and submitting data and getting email.
I am reading about UML here: http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html
Was wondering if there should be an actor on the right side of the diagram representing the database? Am I missing anything? How do you know you are completed with a use-case diagram?
Actors are not included in the system, they are extern to the system. Usually, the DB is in the system and it is not an actor.
For example, in your case, a secondary actor could be google map if the technician has to know how to go the customer and, for that he has to see a map whith the travel. In this case, during a use case, google map is reached to get the map.
The only way I know to be sure that UCs are completed is to review them and/or to get a list of customers needs and to trace customers needs with UCs.
Hope this help.
More :
The remark of #Kilian about function is a real good one. Usually when we start we thought use case as "workflow to achieve a feature" or as the set of all user interface menus and this is not that.
So #Waren, I could suggest:
First try to define the system with a title and a paragph deifning the main mission of the system. System is not only the code you are going to write but all what will deployed for it (machine, virtual machine, db, bays, swicht, procedures, DDL, configuration files and so on)
Then define the needs, high level needs that the system must fulfilled (iso term is shall see enter link description here )
Then define the actors/stackeholder and the inheritance hierarchy to figure the needed roles and rights. Do not forget all operational needs (monitoring, backup/restore, DRS procedure, reports, deployment and so on)
Then define your use cases thinking features or single added values and check the whole coherency. A good point about UC is to describe "error/exception" scenarios.
Then an interesting point could be to define the mode of system : installation, tests before production live, production, update/patch, maintenance, system stop and removing. Like that you will be sure to cover the whole system lifecycle.
When defining scenarios in Gherkin sometimes there is no clear distinction between Given and When steps, i.e. there is no active interaction with the system from the user and the purpose of the validation is to verify how the system should look under certain circumstances.
Consider the following:
Scenario: Show current balance
Given user is on account page
Then user should see his balance
vs
Scenario: Show current balance
When user goes to account page
Then user should see his balance
I am not sure I would always use the second variant. If I have multiple scenarios sharing the context "user is on account page" and some of them have additional user actions while others don't, then it seems to me it should be valid to keep "user in account page" as a Given step even though it may lack "When" for some scenarios. Is this a valid approach?
Formally and technically Cucumber/SpecFlow doesn't require you to write a When-step or rather Given/When/Then's are just executed in the order they are written in the scenario. In that regard you don't need a When-step.
But, as Andy Waite wrote about, the When-step shows on the action or event that your system takes from the "Setup" to get to the new state that you verifies in the Then-step. In that regard a When-step should be present in every test (as you wrote: what are we testing otherwise).
That leaves your final comment; what about verifying just the setup (Given the system is started, Then the database is clean as a naïve example). In such scenarios the When-step could be skipped.
So, as always, it comes down to readability and understanding. Scenarios are written to make our thoughts about the systems behavior concrete and clear. Use the form that optimize for understanding and learning about the behavior in question.
Without thinking too hard on this I would probably guess that the general advice is to always use a When-step that makes the event or behavior very apparent and clear. I would shy away from implicit and hidden behavior when possible.
I hope this helps.
Generally a scenario consists of 3 parts:
Setup (the Given)
Action (the When)
Verification (the Then)
Sometimes the setup isn't required (or it's implicit). But I can't think of any situations in which you wouldn't need an action and verification.
Agree with Andy + Marcus here but I've a few comments that may be of use.
Gherkin feature files should act as living documentation for the behaviour of your system.
For this reason scenarios should provide enough detail to convey to a developer and other project stakeholders (product owner, testers etc) the business rules that embody that feature.
I think your question may have arisen from not considering this business rule end to end when articulating the scenario. I'd have to ask someone the question , what is a balance? Therefore I feel you may need a step to at least convey the concept - that before a user can look at their balance, they have to have one.
Scenario: Show current balance
Given I have a balance
When I go to my account page
Then I should see my balance
It's important to set system state (i.e. any 'Given' step) to allow you to clearly test that the system is working correctly - otherwise how are you going to determine that the balance is actually correct? You may wish to make this more explicit by specifying some arguments:
Scenario: Show current balance
Given my balance is £10
When I go to my account page
Then I should see my balance as £10
I'm not sure which BDD framework you are using but I use Behat which allows you to map more than one Gherkin step to a step definition. I.e
user is on account page
user goes to account page
can both map to a step definition which navigates a user to a page. The system behaviour is the same, the only reason to distinguish between the two, as you have, would be to make your scenarios more readable.
To my understanding when you write a scenario the are 3 steps that are needed.
A state that your application should be in at the begining.
What the user has to do to reach a certain state.
The outcome/input of the user's action i.e the end point of your scenario.
So the scenario will be something like :
Given the user is on the profile page
When the user goes to the balance page
Then the user should see their balance
The profile page will be where the user can click a button or link to acess their balance.
Then have a background :
Given the user is logged in
And the user has a balance
Hi im not used to UML but i have to create a Use case diagram for a system.
Id Appreciate(HELP!) if some one could make an example of a use case Any of the information i provide. the system rums on windows mobile phone 7
Mobile Location based GPS
User creates account,
User Creates Profile(identy) on the account
User Chooses Region
User Chooses to partcipate, then gets Assigned A location from servers online
User gaol of Reaching loaction met, User is Assigned Points(leader board updated), If the user Fails No points Valuse of location increases.
USer Can Equip tools, User Gets new Tools if Points Goals are reached.
User Can lookup point leaderboard, See users Rank
Please wip out paint for 2-3 mins and how me how to do one of these use cases !
And does each sentance need a use case ? or is it possilbe to give a use case to each of these lines ?
THANKs!
I can't help but ask: What benefit does creating a UML use case diagram, with stick men and bubbles, give you that the simple sentences you posted do not? I simply don't understand what the fascination with UML is all about.