OK, after turning the problem statement into a set of requirements at class Monday night, we are ready now to create a set of use cases to represent the requirements. I've gone ahead and taken an initial stab at a set of use cases on the web site (http://www.ajug-scea.org/app.htm#design). The original problem statement and distilled requirements are also there. You'll notice that in the requirements list, I have linked each requirement to the use cases that represent it. Conversely, in the use case list, I've linked each use case to the requirements that drive it. By cross-checking them back and forth, we can make sure that the requirements are solid (use cases don't bring up any implied or missing requirements) and that the use cases when properly implemented will in fact satisfy the requirements (requirements don't state anything that isn't covered by at least one use case, with the exception of non-functional requirements like availability, stability, etc.)
This is really good stuff, Jeff. Should there be two different use cases for rental, since the requirements for in-store and online rentals seem to be different? In fact, perhaps requirement 6 should be broken into two separate requirements. I see no use case that demonstrates the system notifying the customer of a completed transaction. Also, requirement 3 (maintaining member accounts) is only demonstrated in the form of creating an account. There is no use case that demonstrates how a customer or manager maintains (changes, deletes) an account. Thanks for the great education! Lee Grey SunTrust Banks, Inc. [ April 01, 2004: Message edited by: Lee Grey ]
I appreciate you taking the time to look over them and raise these points. This is exactly the kind of discussion we need to be having now. Basically, your first few points hit right on a key decision to make regarding how granular should the use cases be, fatter with conditional logic to accommodate different paths or thinner with several use cases covering a given function (one per path). Fatter can give a more cohesive view of a given business process, but become cumbersome or crowded. Thinner can be simpler to follow but lead to redundancy and a patchwork view of a system function. It's always tough to make that call. You don't want 80,000 use cases, nor any with 80,000 elements in them!
I initially had in mind for some of the issues you mention to be subsumed into the "customer rents video" use case in the form of conditional branches there. But after reading your comment on the in-store versus online rental, I think I agree with you that they should be broken out into 2 use cases. The two have different origination points and quite different flows with only moderate overlap, they are probably best separated. The notification of complete transaction I thought would be in the "customer rents video" or "customer buys video" use cases, since it's essentially the endpoint of those use cases and has no meaning apart from them. But perhaps since it is shared between the 2, it would be better factored out and then included in both. You convinced me there too ;-)
I think you're dead right regarding the missing use cases for "manager edits customer account" and "manager removes customer account", no doubt we need those, good eye.
Regarding the compound requirement #6, I don't generally have problems with compound requirements unless they are too egregious (lumping things together that really have nothing to do with one another). So long as they are closely related at the business level, if having them together makes it clearer reading for business users, I tend to leave it that way. You want the requirements to be mainly understandable to them. The fact that we know this requirement will decompose into 2 use cases and that they'll be physically different in how they work is more of a design/implementation detail that biz users won't care about. The way they see it, a person rents a video, whether online on in-store, it's still the same function, renting a video.
posted 15 years ago
OK, the requirements and use cases have been updated to incorporate the points discussed by Lee and I above. Please keep the feeback coming! We want to start the project with the most solid analysis possible so the design and coding will go well. Thanks, Jeff
Should we discuss the more detailed requirements, the concepts that will lead to attributes of the video/dvd and/or customers? For example, what attributes can be used for searching a video (genre, title, director..) and what info is required from a member (contact info, credit card?). Also, there are not requirements for return of rentals. What happens if a member keeps video longer than 1 week? Do memebers get notification of late items? Are they automatically charged for the next week? Can they automatically be charged for the cost of the item after say 1 month?
posted 15 years ago
Hmmm, well I'd think that the details of what data comprised a video and/or a customer would probably be best handled in the design phase and the use cases kept high-level. We'll certainly need that info, no doubt. But that information would be more handled when we got down to creating the class diagrams and then event sequence and collaboration diagrams, unless we want to make detailed use cases, which we could do. Now, about the missing requirements, I'd say that's a bulls-eye. Definitely missing scenarios there. I've added requirement 2a and use cases 1.8.1 and 1.8.2 to cover those scenarios.
hi Jeff / All- had some good discussions yesterday. was wondering if we need to start breaking down reqs to use cases. we had discussed starting on breaking up the responsibility onto some interested ppl. i would definitely be. was wondering if i could get some thoughts on use case approaches that centered on a primary use case and use sub use cases that *extends* or *uses* the pimary u.c. eg. would be: central use case: *browse titles* sub use cases: *by genre* *by actors/actresses* *by director* *by search criteria* *by status criteria* now certain sub u.c. notably *by status criteria* would be only available to an actor like *manager*, and not to other actors like: *non-member*, *member*, or *clerk*. haven't done much use cases, but was thinking in terms of keeping things minimal and also expandable for the future. hope it makes some sense :-). will look for feedback on how we should proceed. thanks.
Honk if you love justice! And honk twice for tiny ads!
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps