Having a use case that is slightly different for either actor, how should this be captured in the use case specification?
An example should be helpful, but if I correctly understood your question you just have to associate use case with the right actor...
Extract the differences to a sub-usecases. For example, it can be something like this (of course, the actual diagram may differ and should correspond to the actual context):
Related
The use case should depict this situation:
A shipman can ask questions via radio to either a VL, DM or WL. Depending on the question, they need to look it up in APIC (a software tool), but this is not always the case. They all are apic operators, but depending on their role, they have their speciality that they only can access in apic.
The question the shipman asks can be about lock executions, the nautical weather, etc... but it all comes down to the same question-answer format.
Is my use case correct?
Asking a question is usually not a use case. The goal of the shipman is probably not to ask a question, but to get some answers. So asking and anwering is one use case.
When analysing the use case, several possibilities will show up, such as looking up information in the APICS-system. I would just describe this within the use case (possibly with an Activity Diagram). What is the advantage of using an extend here? (I agree with the other answer, that the arrow is in the wrong direction. Additionally it should be an open arrow).
Each goal is an own use case, even when they have much in common. After describing the essential steps of the use cases, it may save some work to look at them and find those that have a big overlap in the essential steps and then create an abstract use case containing the commonalities. But this should only be done after describing the use cases.
Always remember, that the main goal of use case analysis is to find all functional requirements for the system, especially those that are not immediately obvious. If your use cases are just wrappers of functions you already know, not much insight is gained by them.
Three issues here:
The extends arrow is the wrong way around.
Generalizations of UCs is a bad idea in general.
Just as a side note: your actors miss their legs. This way it's a Female symbol (Venus' mirror).
Let's elaborate a bit on the 2nd. Why is it a bad idea? UCs represent a single added value for an actor a system under consideration will deliver. So each UC is unique (think of unique sales propositions). Generalization of USP is only valid in a franchise. So unless you model McDonalds here, it's likely a wrong approach. Look at the main UC "ask question". Do you consider that added value from a system? I wouldn't. When looking at the bubbles behind they more look like primary use cases. So, just remove that general "ask question" and connect the bubbles behind directly with Shipman.
As always when it comes to UC questions: Bittner/Spence about UC is the best read I can recommend.
I have this use case diagram. As you can see, "Rate Service Provider" is the general use case of "Rate on Computer" and "Rate Online" use cases. Since those two use cases are specific, I know they have separate use case narratives. Now my question is that do you need to create a use case narrative for a general use case? The general use case has almost the same behavior as the two specific use cases. Thank you. :)
Yes, base on my previous experienced. The rate computer and rate online will be the alternative sequence in your use case narrative.
You will need a narrative that describes the behavior common to both sub-cases for Rate Service Provider. In that narrative, mention the inherited cases, and provide a separate narrative for each of them. Much as you would do with a narrative for a use case that has included use cases.
I'm using PowerDesigner and I have a use case diagram with one actor and 28 use cases, I'm looking for the best way to represent it in one paper.
I tried the vertical center alignment of use cases, but it takes a lot of space.
Can I split them in two or three packages or something like that ?
I have a use case with one actor and 28 use cases
What do you mean by this? A use case "with" 28 use cases?
In UML it is not valid for a use case to "contain" other use cases. If you did it like this, simply convert the containing UC into a Package with the same name.
Are these 28 UC maybe included in the first one ("include" relationship)? If so, this already seems to be strange. We should know more in order to eventually fix this.
There are several ways you can visually simplify similar modelling situations. In general, you should not have more then 6-8 elements (UCs) in one diagram, simplicity reasons.
Make several diagrams and show only related use cases on each one, with corresponding (in this case always the same) actor
Are all use cases on the same level of abstraction? If not, consider restructuring them in terms of converting high-level ones into packages which would in turn contain corresponding low-level use cases
Are use cases maybe too atomic (too low-level)? If so, group several related ones in a higher-level use case. This would reduce the total of UCs
Do you have some relationships between them?
If you post your current diagram, we could probably help you further.
I know what use case descriptions are. But when people say use case specification is it the same as use case descriptions?
For my understanding, the specification includes both the diagram(s) plus the textual descriptions, but you should make sure your stakeholders' understanding is the same as your own if they use such wording.
I'm making a use case diagram for an android application and i want to represent a "consequence" relation but i don't know what to use exactly.To be more clear, i'm calculating something and depending of the result i'm calculating something else, how to repesent that ?
Thank you
A use case diagram shows an objective not working, for that use an activity or sequence diagram.