Requirements

Analysis
 • Project planning and managing the triple
constraint (Cost, Time, Scope)
• Clarify requirements and understand the
current process, which is often skipped when
doing business analysis (As-Is)
• Thereafter develop changes to the current
business process. (To-be)
Requirements • All these result in a system proposal (a detailed
list of requirements, as well as diagrams that
Analysis describe the system being proposed)
• The system proposal then serves as the input
into the design phase
• In principle though, the documentation is
largely the same. This is a list of potential
deliverables, some of which were created
during plan phase and others which are new to
analysis phase.
 Understanding the current process
should be an important step in your
analysis phase.
•  Swim lane diagram or a flow
Requirements chart to document the current
Analysis process
• Workflow diagram or any process
model
• Use cases
 • Whether you're writing traditional
requirements like you might do in a
mature software organization or
whether you're writing Agile user
stories, like you might do at a smaller
IT organization or a startup company,
the principles of writing clear,
Requirements unambiguous requirements are the
same.
Documentation • The overall purpose of writing
requirements is communication.
• Requirements are so important that
they're covered by the International
Standards Organization, otherwise
known as ISO in a document
ISO/IEC/IEEE 29148:2018
 • Whether you're writing a
requirement or an Agile user story,
the requirements should not state
how the system will meet the
requirement, only what the system
should do.
Requirements • Requirements should be Specific,
Documentation measurable, achievable, relevant,
and time bound (SMART).
• Good requirements define the
performance of the system (not the
performance of the user or other
stakeholders).
 • We should uniquely identify our
requirements. We usually achieve this by
giving each requirement a number. We
should also work to identify
dependencies. Some requirements are
only relevant if a previous requirement is
implemented.
• How to construct a good, clear and
Requirements unambiguous requirement.
Documentation • Avoid superlatives, subjective language,
vague pronouns, open- ended,
comparative phrases, incomplete
references  
• The primary role of the BA is during the
analysis phase is writing requirements.
Other roles of the BA include preparing
diagrams and other documentation

* Acknowledgement: Coursera Business Analysis

 • Requirements with planned expiration
dates or applicability dates should be
clearly identified. (Necessary)
• Requirements should be free of
implementation. 
• Requirement should be unambiguous.
• Requirements should be consistent. This
Requirements means essentially that one requirement
should not conflict with other
Documentation requirements.
• The requirements should be complete.
This means that the requirement needs
no further clarification than what is
written.
• Requirements should be feasible.
• Requirements should be traceable.
 • Mandatory and Binding “Shall”
• The software shall acquire data from
the………….
• Desired but Non-Mandatory “Should”
• The system should withstand……
• Positive statements
Requirements • Active voice
Documentation • Indirect words, vague words,
persuasion words, completion words,
qualifiers, comparatives, quantities,
pronouns, positional words,
temporal words, and similar
ambiguous words to be avoided
 •  User stories should also be
correct, complete, clear,
consistent, feasible, and traceable
• “As a customer, I want to be able
to make changes to the dishes I
order after I've submitted the
User Stories order to the kitchen so that I can
customize their preparation to my
Criteria liking”
(operational nightmare for kitchen
staff)
 • This artifact captures the sequence of actions a system performs that
yields an observable result of value to those interacting with the system.
• The primary purpose of the Use Case is to capture the required system
behavior from the perspective of the end user, to achieve one or more
goals. Different users benefit in different ways, of course:
• Customers use them to describe, or at least to approve, the
description of the system's behavior.
• Potential users use them to understand the system's behavior.

Use Cases
• Architects use them to identify architecturally significant
functionality.
• Developers use them to understand the required system behavior
so they can identify classes from the Use Cases' flow of events.
• Testers use them as a basis for identifying a subset of the required
Test Cases.
• Managers use them to plan and assess the work for each iteration.
• Technical writers use them to understand the sequence of system
behavior that they need to describe in the documentation.
Use Cases
• The functionality of a system is defined by
different use cases, each of which
represents a specific goal (to obtain the
observable result of value) for a particular
actor.
• In an automated teller machine shown in
Figure, the Bank Customer can withdraw
cash from an account, transfer funds
between accounts, or deposit funds to an
account. These correspond to specific goals
that the actor has in using the system
 Use Case: Withdraw Cash
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. 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
Use Case: Withdraw Cash
5 Alternative Flows
5.1Invalid 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.2Wrong 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.3Wrong 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 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.4Amount 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.5Amount 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
Use Case: Withdraw Cash
5.6Insufficient 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.7No 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.8Money 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.9Cancel
If at point prior to step 8 in the basic flow the Bank Customer selects Cancel, 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
Use Case Scenarios

• Following each possible path through

the use case in the last example, the
different use-case scenarios can be
identified. Beginning with the basic
flow and then combining the basic
flow with alternate flows, different
use-case scenarios can be identified.
 Scenario 1 - Basic Flow

Scenario 2 - Basic Flow >> Alternate Flow

1

Scenario 3 - Basic Flow >> Alternate Flow

1 >> Alternate Flow 2
Use Case Scenario 4 - Basic Flow >> Alternate Flow
Scenarios 3

Scenario 5 - Basic Flow >> Alternate Flow

3 >> Alternate Flow 1

Scenario 6 - Basic Flow >> Alternate Flow

3 >> Alternate Flow 1 >> Alternate Flow
2
Traceability between requirements

• Verify that an implementation fulfills all

requirements: Everything that the customer
requested was implemented
• Verify that the application does only what was
requested: Don't implement something that
the customer never asked for
• Help with change management: When some
requirements change, we want to know which
test cases should be redone to test this change
 • Requirement Traceability Matrix (RTM) is a
document that maps and traces user
requirement with test cases.
• The main purpose of Requirement Traceability
Matrix is to validate that all requirements are
checked via test cases such that no functionality
Traceability is unchecked 
• Many enterprise CASE (computer aided
between software engineering tools) support
traceability in some form
requirements • Forward traceability moves forward
through the systems development life
cycle
• Backward traceability starts at the end of
the system and its development life
cycle, and moves backwards
 • Use case include is a directed relationship between
two use cases which is used to show that behavior
of the included use case (the addition) is inserted
into the behavior of the base use case.
• The include relationship could be used:
• to simplify large use case by splitting it into
several use cases,
Relationships • to extract common parts of the behaviors of
two or more use cases.

between Use
Cases: Include
 • As the name implies it extends the base use case and adds
more functionality to the system.
• The extending use case is optional and dependent on the
extended (base) use case.
• The extended (base) use case must be meaningful on its own.

Relationships
between Use
Cases: Extend
Relationships between Use Cases: Examples