This is a question confused me for a rather long time.
For the definition of stakehoder, I can understand that a stakeholder is not always an actor. For example, to build a nuclear power station, the National Nuclear Safety Administration may be a stakeholder, but it does not interact with the station, so it's not an actor.
But on the other hand, is an actor always a stakeholder?
Consider this: we build a underground cable system, and some rat bite the cable. In usecase analysis, I would like to model the rat as an actor, but it is definitely not a stakeholder of this system.
Well, the rat has an interest in not being electrocuted. So, it is a stakeholder. The question is, how important you consider it to be. Probably not so much.
Also, you would not analyse the use case "satisfy hunger for cables". Rather you should analyse how to "protect cable against rat bites". Both are valid use cases, but I assume, that you don‘t want your system to be used in the first way and therefore you should not model it. The second one is only a use case, if your system shall have functions to drive off rats.
The UML doesn‘t say much about how to describe use cases. I always recommend to describe them from the viewpoint of the stakeholder for whom the result is of value.
In short
Yes, every actor is always stakeholder. But not every stakeholder is an actor.
Some more thoughts:
First definition
In the UML specifications, there is no definition of stakeholders. But it is said that:
[A use case] specifies a set of behaviors performed by that subject [i.e. the system], which yields an observable result that is of value for Actors or other stakeholders of the subject.
This wording also suggests that actors are stakeholders: if they weren't, the word "other" wouldn't be needed.
By the way, this clearly eliminates the rat from the suspected actors, since the cabling system is not supposed to produce results of value for rats. And the result that could be observed on the rats is not of value for the other stakeholders.
How are stakeholders related to use cases?
Many systems produce an observable result that is of value for the actor interacting with the system: the actor benefits of cash after a withdrawal, the actor could achieve a task with the system, etc...
But the value is not always for the actor. If you walk through a body scanner at the airport, as a user you might not fully value the results of being scanned yourself. But the airport, the airline, homeland and security, and the other passengers may very well value the result of the use case. This shows that not all stakeholders who have interest in a system, are necessarily users.
Second definition
As strange as it may sound, the SWEBOK does not define the stakeholder either. They just enumerate some examples, such as users, customers, regulators etc. ISO 21500 does also have a definition by example.
Moreover, we must keep in mind that the interest of a stakeholder is not only the own benefit, but could be the opposite. If your neighbor installs a video surveillance system with a camera that captures the entry of your house, you're neither the customer, nor the user, but you will probably be a stakeholder perceiving a threat for your right to privacy.
A popular definition is therefore the PMI's:
An individual, group or organization that may affect, be affected or perceive itself to be affected by a decision, activity or outcome of a project, programme or portfolio.
We can cross check that according to this definition that all actors are stakeholders, since they will be affected by the future system.
And the rats?
Rats are in principle not actors of an underground cabling system, as the system is not build for providing them value nor to involve them to provide value to other stakeholders. Rats could be considered as stakeholders if we'd extend the concept to animals: they may be affected or think to be affected by all this cables. Bust most probably, they are simply a source of malfunctions in the system's environment.
This reminds me a story that an old system engineer told me 30 years ago, and that happened to him at the begin of his career, probably another 30 years before. It was on his first bigger computing project, a large electromechanical computer designed to compute the payroll of a large organisation. For some reasons, there were some mistakes every month, but never the same. After months of (expensive) debugging, they found out that some rats indeed have eaten the hull of some cables in the floor space under the very large computer, and if a rat by chance walked on the wires at the wrong moment, it closed random circuits that were supposed to stay open. A more modern version of the first bug?
Related
I have a task to make a simple information system for the functioning of a guest house. I need to make a USE CASE diagram, but I don't know if what I've done is correct, or if I need to add something, I don't know where to include the maid.
As users of the system I have put - client, receptionist, manager
As objects of the system I have put client, room, occupied rooms, employees (maids, receptionist, manager), tour agency, payment
Can you give me a hand?
Well, you are at the verge of functional decomposition. And that's not what UCs are about. They are about added value. So the bubbles contain headers describing those added values. For a hotel the basic UC would be Reserve room. (A real hotel would of course offer more added values, but for your example that's it.)
Now, the reservation is usually going along with payment. But would you consider that added value? I would not. So rather than making these UCs they are constraints (from requirements defined elsewhere). There's a lot one could talk about representing requirements and business rules, but that is far too much for a discussion here. I recommend reading Bittner/Spence about UC sythesis. It takes that book and a lot of experience to get familiar with this area.
Note that UCs are described with subject/predicate(/object) to be meaningful. Room is no UC. If you intend to show an object, use a rectangle (with object notation). That however, is in most times more confusing than helpful. Stay with actors and (real!) use cases.
Another note: the downward association from Hotel manager should rather be a generalization (open triangle instead of an arrow). And the actors usually are also shown with arms ;-)
JBehave is Java based & good for Java applications. JBehave also supports good HTML reporting. However, the problem with JBehave is that it only supports Story level and not Feature level.
Can any one here help me with a small explanation or documentation where I can understand how Cucumber supports Feature level?
A feature is an implementation of a capability (a capability might need more than one feature).
Let's look at Mike Cohn's description of a "story", since it's pretty good:
User stories are short, simple descriptions of a feature told from the
perspective of the person who desires the new capability, usually a
user or customer of the system. They typically follow a simple
template:
As a <type of user>, I want <some goal> so that <some reason>.
A good user story follows the INVEST principles, and this is where we start getting into scenarios:
Independent, which means it can be delivered on its own
A story may have one or more contexts in which the feature is going to work. The contexts are by their nature independent of other contexts.
Negotiable, so you can rewrite it
As you work through a story, you may find other contexts or outcomes that need to be considered. The capability which is the core of the feature is usually associated with the "when". For instance, if I wanted to be able to generate a report, the "when" would be, "When I generate the report..."
Valuable, so it delivers value to stakeholders
There may be several stakeholders with different outcomes. For instance, sending an email to say that a cab's been booked is important, but so is sending the booking confirmation to the driver! By considering different stakeholders, we come up with the outcomes for the scenarios that need to be considered.
Estimable, so you can estimate the size
If you can't estimate the size, try just getting one scenario working. This is the functional equivalent of Kent Beck's "spike". Incidentally the only reason you need an estimate is usually to work out whether it's worth doing, given other work that could be done, so treat this accordingly.
Small, which (quick edit as I realised I missed this letter) means you should have some level of certainty about it.
I actually prefer people knowing they have some level of uncertainty about it, and look to get feedback ASAP. If you're really certain about it (eg: login) then it's OK for it to be bigger, because you'll need feedback less frequently; you know what "working" looks like.
Testable, which means the related description must include enough to test it
Examples become tests as a nice by-product of this analysis.
Why do we do stories in the first place, though? Why not just deliver whole features?
It turns out that the work needed to get some features shipped ends up being pretty big, especially if you've got a lot of stakeholders involved, and we want to either slice them up so we can get value from them earlier, or we want to slice them so we can get feedback.
So a story might be a slice through a feature that can actually be shipped, or it might be something designed to get feedback.
Scenarios are a fantastic way of doing this! The feature can be narrowed down to the most valuable contexts, or different stakeholders whose outcomes need to be considered. Be careful not to eliminate stakeholders with transactional needs (the user at the ATM gets their money; the bank debits the account) or regulatory needs (the bank makes a major investment; the regulators see the change in capital reserves).
Scenarios aren't the only way of getting feedback on a feature. New UI? Hard-code it without any behaviour and show it to people. New report? Make up a mock copy. New feed that nobody's ever processed? Make a spike, see if you can get the information out of it that you think you can.
Otherwise, consider different contexts and stakeholders whose outcomes need to be considered, and consider different capabilities with their contexts and outcomes. Features implement the different requirements, whose behaviour is illustrated by the scenarios you've derived.
Since a story is a slice through a feature, and a feature implements a capability, this is a typical hierarchy:
Stakeholder
Goal
Capability
Feature
Story
Scenario
If you're trying to work out how to relate scenarios to stories and features, this isn't a bad way to go. You'll find it familiar if you look at Gojko Adzic's "Impact Mapping" or Matt Wynne's "Example Mapping" (I think we all got it from listening to Chris Matts).
Be careful because in reality this is a bit fuzzy; you'll make discoveries as you start to deliver, so don't break everything down ahead of time. I find capabilities make good planning-level artifacts, and are often associated pretty easily with "Epics". They also come with their own high-level tests: "Can our users do what they need to, for the contexts we need to consider, and the stakeholders whose outcomes are also needed?"
The trick with a story is to only consider what's needed to deliver value, until it's actually delivered... and then some of the rest will be the next thing that's needed, etc.
For more ideas, here's my blog on capability-based planning and lightweight analysis, and another one on splitting up stories.
For Cucumber, organize by capability and then (if you need to) by context, and tag your check-ins with the story number (most CI tools, electronic boards and version control systems support this). It's OK for a feature or story to create more scenarios.
I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
It is not included because the "User is paid cash in hand from job" is outside the scope of a project and would not be needed for what you are trying to create.
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
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
I have just been re-reading "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans. I could not help but notice a hint towards creating a language where there is a one-to-one mapping between a noun and an entity. For example, we might call a phone, a phone and no other noun is accepted. However, can this always been achieved with every other entity. Let us take for example, language used to denote a bid on a phone. Here, there are several different names that refer to a bid on that phone where all these refering names mean the same thing, e.g., negotiate bid, negotiate offer, phone bid, etc. Also, there are additional terms used by other customers. Using these terms interchangably does not cause confusion. Nevertheless, attempts to introduce a single term to be used across all the source code as well as in conversations with all customers can cause confusion.
There is the obverse problem when we talk about similar phones where similar means something different to each customer. Here, we have the same term, which is sought after. However, it has many different meanings.
So, what justification in this instance could be used to attempt to introduce a one size fits all term when it contradicts working experience?
Your argument "begs the question" (in the logic sense of the term).
You ask: "Under what conditions could we justify an attempt to introduce a one size fits all term when it contradicts working experience?" How about under those conditions where it actually doesn't contradict working experience?
You suggest: "attempts to introduce a single term to be used across all the source code as well as in conversations with all customers can cause confusion." Indeed, it can... and it can also avoid confusion.
Source code is a great example of a limited domain where we can expect a minimum level of familiarity and training for all of the users expected to work in that domain (at least, in most commercial settings).
It is quite reasonable for a style-guide to declare the preferred term, and expect everyone to follow it, as consistency in this situation has a big upside. Using your example, in my particular project, I use the term "offer" over "bid" every time, and the code is better for it. I can point to other terms which have not yet been standardised, and can see the extra effort it takes to code for them.
Similarly, it is a widely accepted design goal in User Interface design and in User Documentation to use consistent terms. Using multiple terms for the same item is more difficult for users to follow - particularly non-native speakers. (I disagree with your claim that it does not (ever) cause confusion.) When introducing a new term, it is a good idea to mention other terms that could be used.
(Funnily enough, I worked at an organisation where the User Documentation referred to phones as "Voice Terminals", as the term 'phone' was ambiguous; this was, I suspect, going too far?)
On the other hand, someone selling a product or training users would generally do well to mimic the language of the users to best engage them.
You said,
There is the obverse problem when we talk about similar phones where similar means something different to each customer. Here, we have the same term, which is sought after. However, it has many different meanings.
What about bounded contexts? Probably, when same term means two different things, they should reside in two different contexts?
I quote from Martin Fowler's page on Bounded Context:
As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty).
His and yours problem descriptions sound similar.