Discussion Topics« Return to 2. Business Analyst - General Discussion
Use Cases - Alternate flow vs. Exception Flow
While constructing Use cases for one of the projects I am working on currently, I came across the dilemma of using the Alternate flows vs. Exception flows. From what I presume, alternate flow does not stop you from finish the use case but it just takes a different path from the basic flow. However, exception flow could result in incomplete termination of use case. Here is an example:
Use Case name: Login to the system
User Case description: User is able to enter username/password combination and login to the system successfully.
Actors: User A
Precondition(s): User must exist in the database.
Postcondition(s): User can login successfully.
Basic flow of events: Successful login
1. User launches the login screen.
2. User enters a combination of username and password.
3. System validates the combination and logins the user successfully.
Alternate flow A: Incorrect username/password combination
A.3. System validation of the username/password combination fails due to incorrect entry.
A.4. Systems asks the user to re-enter the username/password combination.
A.5. Go back to basic flow 2.
Exception flow B: User record does not exist in the database
B.3. System validation finds that the user record does not exist in the database.
B.4. Systems alerts the user that their record does not exist.
B.5. Use case ends.
The above alternate flow did finish the use case but the exception flow could not. What do you guys think of this? inputs appreciated.
Replies to this Topic
You are right... and according to Jacobson also alternate flow is really a "mini use case" in its own right,it begins with a trigger-the condition giving rise to the alternate flow,it has a goal and its main body includes a set of steps and alternate flow could in turn have its own alternate flows.
So according to the above description alternate flow should have a start and a end condition whereas a exception flow is useful to describe unusual behavior of a system so exception flow could result in incomplete termination of use case.
Yash you are absolutely right when you say that it creates dilemma
Alternate flow can start at the starting point itself or at any particular definite point in process.
If a customer is searching for a product on the company website.
He can go for Basic search where he can start searching afresh...or he can avail Quick search where he will get the output through system history(Most popular product etc). So here we are starting alternate flow from the start itself by giving user choice.
Your example gives view of the alternate flow starting from a particular decision point in process(to which Sushant refers as Trigger point).
In either way its a happy case scenario where we are getting output as per the conditions/input provided and trigger involved.
Exception is like anticipated Error or unforeseen conditions where these need to be handled for troubleshooting purposes and to generally avoid user dissatisfaction of being clueless....or rather HELPLESS with the current error condition encountered.
Exception is not a happy case scenario , But its is very much required considering any logic is always fulllproof till the point it meets its BAD FATE !...:-)
I am not sure whether I am on right track, just wanted to share my view. Let me know your inputs.
And I think We have one thread on alternate/exception case flow , If we move this there, it will help getting all the relevant info under one shop.....what say......just a suggestion tho ...:-)...just to make information tighly coupled....!
Can anyone help me out with some material or details of the following:
Regulatory Compliance Standards:(1) Sarbanes Oxley (SOX) (2)Basel II
Business Rule Engines:1) PEGA (2)FAIR ISAAC
Another example of Alternative Flow can be "Entering User Name and Password using Virtual Keyboard" like in https websites.
I think that entering an incorrect user name and password should also be the part of Exceptional Flow as it is not achieving the goal of the use case. Both Normal and Alternative Flows should achieve the specific goal of the Use Case, here the goal is to get successfully logged in the Application.
Exceptional Flow B: Incorrect username/password combination
B1. System validates the entered username/password.
B2. System displays an error message like "Re-enter username/password".
<<Use Case terminates>>
Now, user can again refer Basic or Normal Flow to login.
I too agreed with Jeewanshu. This is a nice thread to be discussed upon. Thanks for bringing this out.
I have read most of all comments and noticed my beliefs/practice is based on different understanding.
Basic Flow as we all know is a happy scenario.
Alternate Flow is a deviation to basic flow however please note that the use case goal should be achieved. if the use case goal is not achieved, it is considered as an exception. with this said, according to me yash's 'Alternate Flow A' is actually an exception because use case goal of successfully login is not achieved.
Well I am sure everyone has it's own convention on defining and using use cases based on situation/scenarios, however my above convention is solely based on yash's login scenario.
@Nitin - I doubt that your assumption "goal should be achieved in the alternate flow" is correct. The concept of Alternate flow was designed to insert many conditions in the basic flow which call sub-flows that handle the extensions. Alternate flows are nothing but the alternative actions that can be performed.
1. User Logs into business analyst forum.
2. Searches for topics interested.
3. Reads the topic.
4. Exits the website.
1. Do not have account.
User creates an Account and starts from Step 1 in Basic Flow.
Basic Flow: is a happy path or normal flow - is the most common pathway. It usually depicts a perfect situation, in which nothing goes wrong.
E.g: You get to the ATM, and successfully withdraw money.
Alternate Flow:is the path that is still good pathway;its just not most heavily traveled one.
E.g:You get to the ATM but could not withdraw money due to insufficient funds in your account.
Exception Flow:is unhappy path-things dont always go as planned. An exception is an error condition that is important enough to the application to capture.
E.g:You get to the ATM but your pin number is not accepted.
I have always heard, and use the definition that an Alternate Flow is a different (alternate) way of achieving the same goal as the normal flow.
using Sruthi's example,
I would say that the example she gives as an alternate flow would be classified as an exception flow.
You expect to withdraw money; however, you are unable to withdraw money. The ATM would provide you with an error message telling you that you do not have enough funds.
Yes, you are right Jason. Alternate flow is an alternate way to complement the functionality discussed in the basic flow. Let's take a look at couple of examples:
Use case description: Withdrawing money from ATM
Basic flow - You successfully withdraw money from ATM, just one shot.
Alternate flow - User (actor) should be able to modify the request before submitting the final request. For instance, the user inserts the card-enter the PIN number-select money options-select 'checking or 'saving' account; but before confirming the transaction, if the user modify the selected options such as enter different amount or choose different account then the system should be able to adhere to the modified request and carry out the functionality. Note, that the functionality is still 'withdrawing money' but a sub-functionality is added through alternate flows.
Also, another alternate flow would be to withdraw money from 'Teller'. The functionality is same but the method is alternate to the ATM withdrawal.
Exception flow - It discusses any error situations that occur when the functionality is carried out.
I find this discussion really knowledge sharing and good explanation regarding use cases and basic concepts involving them.
Alternate Path VS Exception Path.
There are three types of path in an use case write up namely,
- Basic Path - Sunny Day Scenario
- Alternate Path - Moody Day Scenario
- Exception Path - Rainy Day Scenario
Basic Path is normal course of event.
Alternate path is also normal course of event but not usual.
Exception path as name suggests its a omission.Error or Rule failed activities can be named as exception.
Alternate path will end the Use case or join to the Basic path of the use case.(Will never join previous step of the Use case basic path)
Exception path will abruptly end the use case or join to the previous step of the basic path.
I agree with Jason's post and have found it useful to think of these items in the following way:
Basic flow - like everyone else, the happy path - this is also usually the most efficient way to achieve the desired goal.
Alternate flow - a way to achieve the happy path result but with a deviation from the happy path.
Exception flow - Any flow that results in the user not achieving the desired result, regardless of the cause. (user driven or system driven).