Hi, my company has adopted a process of using sub-alternate flows, an alternate to an alternate flow, in their Use Cases. Is this more common or an wrong practice. I've not seen this used by any other company as a method of capturing use cases. Typically, in my experience if you driving to this deeper level of branching you should be creating another use case. I don't think this is best practice at all - are there many others using alt-alt flows in Use Cases?
Main scenario
1. Login to system
2. Present menu
3. Select "x' menu item
Alternate Scenario
1a. Use Automated login of windows userid/pw
Alternate-Alternate Scenario
1a.1 User automated login of corporate id
Thoughts?
Thanks,
B
1a.1
Hi Bill,
Use cases are not meant to be used as a solution design tool. They're a business modelling tool. (I just ducked to avoid all the flaming I'll get for saying that!@!)
Anyway, looking at your example, you have a login use case with alternates for automated user and corporate login. You could easily write this so that 1a.1 is an alternate of 1. Doesn't have to be a sub alternate.
there was a thread on here a while back about whether Login is actually a use case or not. I don't think so personally cause it fails the basic rule of doing something of value for the actor. Logging into a system does not solve an actors business process / problems. But that's another issue.
Have you thought about using other techniques to define your system? For example you could create a site map using a UML Statechart and show the transitions between screens and other actions on the site chart. Much more visual and easier to understand than masses of pseudocode written as use cases. That's how I'd do it.
Kimbo
I dont believe there is anything wrong with having an alternate to an alternate flow, and I have seen a number of ways of documenting it in the past. There first is to have two completely seperate alternate flows, as per your example, and the second is to nest them within one. I dont subscribe to the theory that if there is a depper level of branching then it should be another use case. You should discover use cases from actors and the actors goals in relation to the porposed system.
I assume the example you posted is a cut down verison? Can you elaborate on the alternate flows and exactly what you are trying to shw because, as the previosu poster stated, it looks like you may be able to roll this up into one flow.
I'm totally with Kimbo on this one. If you have different paths through the use case that branch from the same point (such as automated windows login vs. automated coporate login), these fit into the "sibling" model as both being alternate flows without the need for "sub-alternate flows". And I definitely agree with Kimbo that use cases or any other requirements document aren't meant to describe or dictate system design, navigation paths, etc.
What difference in functional requirements and/or user interaction with the system would you see between automated log-in with a windows ID vs. automated log-in with a corporate ID? Perhaps they are not two different flows at all, but one flow with differentiation through the business rules.
Kimbo's suggestion of a statechart is a good option to consider.
Sandy
Bill,
A few years ago one of the UML tools out in themarket could convert a usecase into an activity diagrams and vise versa (cant remember which one). You could toggle between activity and usecase. So if you have alternates of alternates, you would have a decision node following another decision node... see http://www.technosolutions.com/visual-use-case-screenshots/use-case-flow-editor-screenshot.html, and press <<Next>>. So I guess, you could use nested alternates ... and an activity diagram that shows the flow would help.
And another matter, people sometimes get hung up on NOT using solutions (ie signon using user/pw) narrative. Its OK if the boundary is the system -- sometimes an existing system, so there is no point in being generic; the main thing to remember is the BOUNDARY, some of the most overlooked components of a use case.
warm regards,
K
brought to you by enabling practitioners & organizations to achieve their goals using: