http://www.stellman-greene.

com/2009/05/03/requirements-101-user-stories-vs-use-cases/

https://www.boost.co.nz/blog/2012/01/use-cases-or-user-stories

http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/

use case vs use case scenario and use case vs user story

https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/804/What-is-the-
difference-between-a-use-case-alternative-flow-and-an-exception-flow.aspx

http://toolsqa.com/software-testing/waterfall-model/

http://tynerblain.com/blog/2007/04/09/sample-use-case-example/

http://tynerblain.com/blog/2007/04/10/what-are-use-case-scenarios/

https://knowhub.cognizant.com/bu/CBC-
BFS/Repository/Cards%20and%20Payments/Domain%20Assets/Digital%20Payment%20Wallet%20S
olution%20Framework/CBC-
%20Digital%20Payment%20Wallet%20Solution%20Framework_v1.0.pdf]

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/senior-manager-core-
digital-71302

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/project-
manager%E2%80%93-in-house-consulting-services-70407

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/ts-emeia-senior-analyst-
69671

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/advanced-analyst-ts-us-
69666

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/advisory-services-senior-
risk-financial-services-risk-management-69275

https://eygbl.referrals.selectminds.com/experienced-opportunities/jobs/advisory-services-manager-
risk-financial-services-risk-management-_-manager-1-67111
 Use Case Name: Place Order

The next step is to define the use case at a low level of detail. This quick use case definition allows for agile
development of use cases. This is also known as a use case brief.

Sample Use Case Brief

Use Case Name: Place Order

Actors:

 Shopper
 Fulfillment System
 Billing System

Use Case Description: After the user has selected items to purchase and then order the items. The user will
provide payment and shipping information. The system will respond with confirmation of the order and a
tracking number that the user can use to check on order status in the future. The system will also provide the
user with an estimated delivery date for the order, which will include all selected items. The user may already
have an account with the company with billing and shipping information.

Use Case Name: Place Order

Actors:

 Registered Shopper (Has an existing account, possibly with billing and shipping information)
 Non-registered Shopper (Does not have an existing account)
 Fulfillment System (processes orders for delivery to customers)
 Billing System (bills customers for orders that have been placed)

Triggers:
 The user indicates that she wants to purchase items that she has selected.

Preconditions:

 User has selected the items to be purchased.

Post-conditions:

 The order will be placed in the system.

 The user will have a tracking ID for the order.
 The user will know the estimated delivery date for the order.

Normal Flow:

1. The user will indicate that she wants to order the items that have already been selected.
2. The system will present the billing and shipping information that the user previously stored.
3. The user will confirm that the existing billing and shipping information should be used for this order.
4. The system will present the amount that the order will cost, including applicable taxes and shipping charges.
5. The user will confirm that the order information is accurate.
6. The system will provide the user with a tracking ID for the order.
7. The system will submit the order to the fulfillment system for evaluation.
8. The fulfillment system will provide the system with an estimated delivery date.
9. The system will present the estimated delivery date to the user.
10. The user will indicate that the order should be placed.
11. The system will request that the billing system should charge the user for the order.
12. The billing system will confirm that the charge has been placed for the order.
13. The system will submit the order to the fulfillment system for processing.
14. The fulfillment system will confirm that the order is being processed.
15. The system will indicate to the user that the user has been charged for the order.
16. The system will indicate to the user that the order has been placed.
17. The user will exit the system.

Alternate Flows:

3A1: The user enters billing and shipping information for the order. The user desires to use shipping and billing
information that differs from the information stored in her account. This alternate flow also applies if the user
does not maintain billing and / or shipping information in their account, or if the user does not have an
account.

1. The user will indicate that this order should use alternate billing or shipping information.
2. The user will enter billing and shipping information for this order.
3. The system will validate the billing and shipping information.
4. The use case continues

5A1: The user will discover an error in the billing or shipping information associated with their account, and
will change it.

1. The user will indicate that the billing and shipping information is incorrect.
2. The user will edit the billing and shipping information associated with their account.
3. The system will validate the billing and shipping information.
4. The use case returns to step 2 and continues.
 5A2: The user will discover an error in the billing or shipping information that is uniquely being used for this
order, and will change it.

1. The user will indicate that the billing and shipping information is incorrect.
2. The user will edit the billing and shipping information for this order.
3. The use case returns to step 3A1 step 3.

10A1: The user will determine that the order is not acceptable (perhaps due to disatisfaction with the
estimated delivery date) and will cancel the order.

1. The user will request that the order be cancelled.

2. The system will confirm that the order has been cancelled.
3. The use case ends.

Use case is a method for capturing software requirements as a scenario of repeatable order of
actions initiated by user to reach a desired result. The preferred course of actions is documented as
a basic flow and in addition to that alternate flow and exception flow is also included into the use
case. A use case specification describes the functionality of a system in terms of a sequence of user-
system interactions. The main flow of events describes a single path through the system. It
represents the most common way that the use case plays out successfully and contains the most
common sequence of user-system interactions

Use Case Scenario: it is a single path through the use case. A use case defines all of the paths that
lead to the success of the use case. The use case also defines all of the paths that lead to the
abandonment of the use case without achieving its goal. Each unique combination of those paths
that can be taken by an actor during a single “pass” through the use case is a use case scenario.

Alternate Flow: It is a series of actions in non-random, repeatable order different from the basic
flow which still delivers the desired result to a customer. An alternate flow describes a scenario
other than the basic flow that results in a user completing his or her goal. It is often considered to
be an optional flow. It implies that the user has chosen to take an alternative path through the
system

Exception Flow: It contains any actions that will cause the user to not achieve the desired result. The
benefit of exception flow is its focus on potential problems a user might experience. This gives the
software developer an opportunity to develop a feature that would mitigate the issue. An exception
flow is an unintended path through the system usually as a result of missing information or system
availability issues. Exception flows represent an undesirable path to the user. However, even
though the exception flow has occurred the system should still react in a way that recovers the flow
and provides some useful information to the user.

Story Point: Unit of measure used to estimate the relative size and complexity of user stories in agile
development.
 Use Story: it is self-contained and it can be fully coded and tested to ensure it meets expectations.
User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the
software or application. They describe the users’ goals when using the system. The initial
descriptions can be written by the users, customers, product managers, or developers, and are just a
few sentences at most (1-3 sentences being typical). This isn’t the entire user story, but it is all that
is created at first.

Epics: These are made up of multiple user stories.

 User stories are about needs.

 Use cases are about the behavior you’ll build into the software to meet those needs.
 User stories are easy for users to read.
 Use cases describe a complete interaction between the software and users (and possibly
other systems).

A user story is written in the format

As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

User Stories have limited scope to fit within an Use Cases are almost always larger in scope than user
Size and Scope
iteration. stories.
User Stories typically represent a single scenario
Use Cases represent a series of related user
or path through a use case. This could be the
scenarios. While a main scenario (often the most
main scenario, or an alternative or extension
Structure common scenario) is selected, there are many
path. Remember that the user story includes the
decision points throughout the flow that branch into
acceptance tests which often describe the details
alternative or exception flows.
covered in alternative and extension flows.
User Stories are created to facilitate
conversation between the client and
Use Cases are written to be understood by both the
development team when the time is right, and
Purpose client and the technology team. They represent a
have the primary purpose of supporting release
written contract of the desired functionality.
and iteration planning process. They are never
referred back to as a contract between teams.
Use Cases are completed in their entirety early in the
User Stories are intentionally written at a goal analysis and design process. Because of this there
level initially with just enough detail to describe exists a natural urge by the customers to place screen
the user story with just a few sentences at specific elements in the use cases themselves, even
Completeness
most. Only once the iteration planning begins though there is usually a very strong push by the
and more detail will be required the team has technology team to try and avoid this. Inevitably the
conversations to capture acceptance tests. technology team rarely succeeds in keeping UI
features out of the use cases.
 Typically User Stories are not intended to live
Use Cases are often saved and become permanent
beyond the iteration in which they are
Longevity artifacts representing a permanent contract between
developed. Once the functionality has been
the customer and development team.
developed they are discarded.

ATM
Use-Case: Withdraw Cash
1 Brief Description
This use case describes how the Bank Customer uses the ATM to withdraw money his/her
bank account.
2 Actors
2.1 Bank Customer
2.2 Bank
3 Preconditions
There is an active network connection to the Bank.
The ATM has cash available.
4 Basic Flow of Events
1. The use case begins when Bank Customer inserts their Bank Card.
2. Use Case: Validate User is performed.
3. The ATM displays the different alternatives that are available on this unit. [See
Supporting Requirement SR-xxx for list of alternatives]. In this case the Bank
Customer always selects “Withdraw Cash”.
4. The ATM prompts for an account. See Supporting Requirement SR-yyy for account
types that shall be supported.
5. The Bank Customer selects an account.
6. The ATM prompts for an amount.
7. The Bank Customer enters an amount.
8. Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank
Consortium replies with a go/no go reply telling if the transaction is ok.
9. Then money is dispensed
10. The Bank Card is returned.
11. The receipt is printed
12. The use case ends successfully
5 Alternative Flows
5.1 Invalid User
If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete
successfully, then
1. the use case ends with a failure condition
5.2 Wrong account
If in step 8 of the basic flow the account selected by the Bank Customer is not associated
with this bank card, then
1. the ATM shall display the message “Invalid Account – please try again”
2. The use case resumes at step 4
5.3 Wrong amount
If in step 7 in the basic flow, the Bank Customer enters an amount that can't be 'created'
with the kind of in the ATM (See Special Requirement WC-1 for valid amounts), then
1. the ATM shall display a the message indicating that the amount must be a multiple
of the bills on hand, and ask the Bank Customer to reenter the amount
2. The use case resumes at step 7
5.4 Amount Exceeds Withdrawal Limit
If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the
withdrawal limit (See Special Requirement WC-2 for maximum amount), then
1. the ATM shall display a warning message, and ask the Bank Customer to reenter the
amount
2. The use case resumes at step 7
5.5 Amount Exceeds Daily Withdrawal Limit
If in step 8 in the basic flow, the Bank response indicates the daily withdrawal limit has been
exceeded (this is determined by the Bank and depends upon the specific account), then
1. the ATM shall display a warning message, and ask the Bank Customer to reenter the
amount
2. The use case resumes at step 7
5.6 Insufficient Cash
If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the amount
of cash available in the ATM, then
1. the ATM will display a warning message, and ask the Bank Customer to reenter the
amount
2. The use case resumes at step 7
5.7 No Response from Bank
If in step 8 of the basic there is no response from the Bank within 3 seconds, then
1. the ATM will re-try, up to three times
2. If there is still no response from the Bank, the ATM shall display the message
“Network unavailable – try again later”
3. the ATM shall return the card
4. the ATM shall indicate that it is “Closed”
5. the use case ends with a failure condition
5.8 Money Not Removed
If in step 9 of the basic flow the money is not removed from the machine within 15 seconds,
then
1. the ATM shall issue a warning sound and display the message “Please remove cash”
 2. If there is still no response from the Bank Customer within 15 seconds the ATM will
re-tract the money and note the failure in the log
3. the use case end with a failure condition
5.9 Quit
If at point prior to step 8 in the basic flow the Bank Customer selects Quit, then
1. the ATM shall print a receipt indicating the transaction was cancelled
2. the ATM shall return the card
3. the use case ends
6 Key Scenarios
6.1 No Response from Bank
7 Post-conditions
7.1 Successful Completion
The user has received their cash and the internal logs have been updated.

7.2 Failure Condition

The logs have been updated accordingly.

8 Special Requirements
[SpReq:WC-1] The ATM shall dispense cash in multiples of $20.
[SpReq2:WC-2] The maximum individual withdrawal is $500.
[SpReq:WC-1] The ATM shall keep a log, including date and time, of all complete and
incomplete transactions with the Bank.