Comments on: Subordinate and Superordinate Use Cases http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/ Software product success. Sun, 12 Feb 2012 19:10:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: cannockfivesladies.com » Dynamo Advance to the CONCACAF Semis http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/comment-page-1/#comment-82446 cannockfivesladies.com » Dynamo Advance to the CONCACAF Semis Fri, 23 Mar 2007 13:43:09 +0000 http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/#comment-82446 [...] The fulfillment system ships the order [note: this would likely be a subordinate use case]. [...] [...] The fulfillment system ships the order [note: this would likely be a subordinate use case]. [...]

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/comment-page-1/#comment-57541 Scott Sehlhorst Thu, 30 Nov 2006 04:37:52 +0000 http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/#comment-57541 Great points Bas, thanks for reading and commenting! All things in moderation, right? Great points Bas, thanks for reading and commenting!

All things in moderation, right?

]]> By: Bas van Gils http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/comment-page-1/#comment-57439 Bas van Gils Tue, 28 Nov 2006 13:50:22 +0000 http://tynerblain.com/blog/2006/11/27/subordinate-use-cases/#comment-57439 The idea of "hyperlinking to other use cases" to explain how a certain step in a UC is performed can be very powerful. This is particularly true with nice tool-support so that readers can click their way through the UCs if they want more information on a certain step. There is also a danger here, though. It can be very tempting (especially for beginning authors) to adopt a functional-decomposition approach to UC-writing. I.e., one UC must logically follow another UC which must logically follow... etcetera. I recently reviewd a UC specification of a fairly large system with a large number of use cases and this is exactly what went wrong :-( In this case a bit of re-writing and re-arranging made the UCs a lot more readable. We adopted the Cockburn-approach and defined some "summary level UCs" as a table of contents for the user-goal-level UCs. In short: composing UCs can be a good idea... just be very careful. The idea of “hyperlinking to other use cases” to explain how a certain step in a UC is performed can be very powerful. This is particularly true with nice tool-support so that readers can click their way through the UCs if they want more information on a certain step. There is also a danger here, though.

It can be very tempting (especially for beginning authors) to adopt a functional-decomposition approach to UC-writing. I.e., one UC must logically follow another UC which must logically follow… etcetera. I recently reviewd a UC specification of a fairly large system with a large number of use cases and this is exactly what went wrong :-( In this case a bit of re-writing and re-arranging made the UCs a lot more readable. We adopted the Cockburn-approach and defined some “summary level UCs” as a table of contents for the user-goal-level UCs.

In short: composing UCs can be a good idea… just be very careful.

]]>