Should I make two separate use cases if a Member of the website can View their own personal profile and those of other users? Should it be Member - View Own Profile and Member-View Others' Profile? Or just Member - View Profile is enough?
As per comments, An use case can have one complete scenario/feature/function of the application. Hence if you are talking about use-case of member viewing profile, then it will be one use case but if you are talking about test cases for verification, then it would be two test cases.
A member viewing own profile does not mean that he can view others profiles too. Hence you need to have two test cases for verifying both the possibilities.
On the other hand, there are few more cases in this too - you should have cases like member able to edit his profile, edit others profile and this can also go to individual fields too. Member being able to edit all his details, but able to edit few details of other particular members below him in hierarchy and should not be able to edit any details of other members above him in hierarchy etc.
I would say the three use cases, like this:
Use cases demonstrate how actors use the system to achieve their goals. So structuring of use cases must adhere to these goals. Would you say, that an actor, e.g. visitor of your web app, would use your appication just to view his profile? Would he use it just to view profile some other user? If those are separate goals, then the use cases should be separate. But if you want to allow a visitor to see information about other users on site, one use case suffices.
Related
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 ?
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.
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).
In my application each user can create his own system and add team members to it. Each team member in scope of a system has a certain set of permissions, basing on which system decides if team member can access the functionality.
Some examples are:
Access to analytics board
Access to system configuration utility
Access to team management utility
Access to service handling utility
Each team member can have assigned any combination of these permissions.
I'd like to create an UML use case diagram, but i don't know how to represent use cases which are restricted only to team members that are allowed to use them.
Representing permission is like breaking the generalisation os UML use-case diagrams. You need to write them down in your use case scenario and for UML you can have separate section wise representation.
I don't think that use case diagram is sufficient for your requirements. You are talking about a user who has set of permissions. These permission are variable in time. It doesn’t depend on position (what’s more, we are not talking about being a deputy for a boss who just left for holiday).
In this case I always prepare use case such as Manage Permission and an actor is always a user. Then I make a class diagram where the user/permission model is. Then you have several possibilities how to work with permissions:
In every scenario the first step should be checking the permission to
do this steps.
Every use case has a preconditions related to
permissions.
…
Check the diagram where the simplest example is.
In the model part, I use actors inheritance to model right. For example, the
most simple actor is "user" and it is linked to use case "login" only, it gets the minimum right.
Others actors inherit from it. Like that they all have the right to connect to the system.
The most powerful actor, let say Administrator, inherits from all actors like that it gets all rights.
After you can not translate this in code automatically ... :)
I have created a use case diagram for site similar to oDesk.
Site description: the place, where freelancers can find suitable jobs accordingly to their skills and pricing demands and where employers/clients can find suitable freelancers for their job postings with necessary skills and for stated price.
The goal of the site owner is: get income, by means of taking 10% fee from every payment made from employer/client to freelancer.
Have a look at the link below. Will be happy to hear any comments and advices!
I'm new here, but this question looks suitable for Business Analysts. This diagram does make sense. From my point of view, i would have added a "user" role (generalization of "employer" and "freelancer)". And aligned functions similar to "freelancer" and "employer" with "user" role.
From use full functionality point of view (it is what UseCase defines) your diagram is almost perfect. BUT, remove login usecase (it is not service..no body use system to login. Login is precondition for accessing security website functionality). Separate profile manage, block profile and other administration services (usecase) from the rest and build new diagram for them. There are mix of incompatible use cases at the same place.
Your "Make Payment" use case is off. You have it so that only the Employer doesn't make payments to anyone except possibly himself. Consider making the two types of payment into specializations of Make Payment (remove all the extends and includes except from the Make Payment to the Process Transaction), associating the Employer with the main use case, and associating the Site Owner and Freelancer each with the appropriate specialized use case.
Also, as Vladimir says, you might consider splitting this up into multiple diagrams.
Company X wants a web-based system that serves as a market place of ideas. Users should be able to login and post new ideas. Other users can comment on them and “upvote” them. The Administrators can login and mark that ideas have been implemented, and can reward the employee who posted it.
Following are the requirements:
Users should be able to login.
Users should be able to post a new idea.
Users should be able to search for and view other ideas
Users should be able to comment on ideas
Users should be able to upvote ideas
Administrators should be able to mark ideas as implemented
Administrators should be able to delete unwanted comments
Do you guys think my diagram is correct? I am new to UML so you guys can make fun!
http://imgur.com/TGKhweh
It is a not so bad start. Only:
Administrators are also users. They descend from them. So, they should have a generalization connection - empty triangle head arrow from Admin to User. Or to OtherUser (look below).
it is more natural to have a picture and name of an exemplar of agent. So, user, administrator - in singular.
you can divide Users from Other Users only if they have different definition and that difference is seen from the documentation, too. It is not. I would use only Users.
Of course, if some users really have different rights, it is OK, but:
the name is not good, IMHO.
They have all options of users, don't they? So they have to descend from Users
You should continue by adding the parts of your future system, that will collaborate with human agents on these use cases. Now you have only the first half of work done.
Edit:
Still your admin hasn't the generalization error from Admin to User. Admin can do ALL activities that user can, cannot he?
Still you have no subsystems on the diagram.
Search through older ideas should be the use case directly connected to user. And it does not extends nothing on the diagram.
Remember - use Include and Extends only on the last stage of UC diagram creation. When you already have the main picture and are refining it. And very often they should be used only on further, more thorough diagrams. Using Include and Extend from the start means that you haven't found the main concepts yet.
How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.