Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use case diagram
Previous Previous
 
Next Next
New Post 8/2/2011 9:08 PM
User is offline Chris Adams
319 posts
5th Level Poster






Re: Use case diagram 

I should probably add that I just took a quick look at what you had, not what you didn't have.

Such as...if you have an Admin to manage user accounts, then you likely would have a use case to create an account for internet users...etc.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 8/16/2011 11:41 AM
User is offline GVerkerk
2 posts
No Ranking


Re: Use case diagram 

I'm sorry for my comments, because I want to encourage you, but there are a lot of mistakes in your UCD.

For instance, if you have a use case with check out, but not a use case with check in, then that fairly odd. It means that you never identify your users. And how can you check out if your aren't checked in?

The use case select product is not an include of use case place order. It's the other way around. You cannot place an order without selecting a product.

As cadams5 already stated, you cannot have a use case manage user accounts without a use case create user accounts. You cannot have a use case update products without a use case insert products.

In your case I would remodell the UCD, and start with basic needs, like: accounts, products, paying etc. After that, I should identify which states are used with those use cases, like: insert, update, save, delete. After that, you can easely rewrite your UCD.

Good luck!

 
New Post 8/17/2011 5:23 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: Use case diagram 
Modified By Kimbo  on 8/17/2011 7:25:16 AM)

 Hi GVerkerk,

Disagree with some of your comments enough to reply:

You Said: "For instance, if you have a use case with check out, but not a use case with check in, then that fairly odd. It means that you never identify your users. And how can you check out if your aren't checked in?" 

In a standard online purchase process, you browse, make selections (add to cart) and check out when you're ready to buy. No Check in required

You said: "The use case select product is not an include of use case place order. It's the other way around. You cannot place an order without selecting a product."

Think you're wrong here. The use case place order is doing something of value to the client and is a standalone function. During the action of placing an order, the client will select one or more products. So Select Product is included in Place Order.

You said: "you cannot have a use case manage user accounts without a use case create user accounts. You cannot have a use case update products without a use case insert products."

To me Manage User Accounts and Update Products are standard CRUD use cases. Some people split these into separate Create, Read, Update, Delete use cases but I don't for a number of reasons - they usually share a set of business rules and having them in 4 places makes them hard to maintain; always the same initiating actor (if not, they should be separate); separating them out artificially distorts the number of use cases and inflates the expectation of work required; I'm lazy cause there is a lot of extra typing and repetition.

I can see other problems with the diagram (e.g. trying to show process in a use case diagram) but it looks like at least the functionality required is all there. So its not a bad start.

Kimbo

 

 
New Post 8/17/2011 8:00 AM
User is offline GVerkerk
2 posts
No Ranking


Re: Use case diagram 

Well Kimbo, i think we have to agree to disagree....

In a standard online purchase you select a product (UC1) click on a product
then you place an order (UC2) put it in your basket
you identify yourself to buy (UC3) (check in)
and you close the deal (UC4) (check out)

I agree on the CRUD use cases, but i already stated to name them User account in stead of manage user account.(read my first post )
i agree on the actor difference....

 
New Post 8/19/2011 5:02 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: Use case diagram 
Modified By Kimbo  on 8/19/2011 7:11:24 AM)

 Yes, I"m sure we'll never agree. It looks to me like you seem to equate use cases with screens. I don't. (perhaps I have that wrong). There is a many to many relationship between use cases and screens. Looked at from how you've ordered your screens, your explanation is plausible but if you think about the actual functions being undertaken, and not the screens required to realise those functions, then I think my explanation is better.

cheers,

Kimbo

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use case diagram

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 



 

Copyright 2006-2021 by Modern Analyst Media LLC