Chapter 4

SEN2022 SOFTWARE ENGINEERING
ANALYSIS AND DESIGN
CHAPTER 4: REQUIREMENTS ANALYSIS
Prepared by Prof. Dr. M. Alper TUNGA

SDLC
WHAT IS REQUIREMENT?
√ System (business) requirement is something that the

information system must do or a property that it must
have.
− What the system is intended to do.
− Specifies what the customer wants.
3 of 103
WHAT IS REQUIREMENTS ANALYSIS?
√ Requirements analysis is the process of

understanding what’s wanted and needed in an
application.
− We express requirements in writing
• to complete our understanding
• to create a contract between developer and customer
4 of 103
REQUIREMENTS ANALYSIS PHASE
√ Requirements analysis phase defines the business

and user requirements for a new system.
− The requirements analysis phase answers the question:
What do the users need and want from a new system?
− Sources: Stakeholders – mainly owners and customers

− Output: Software Requirements Specification (SRS)
5 of 103
REQUIREMENTS ANALYSIS PHASE
√ Problem Discovery
− Fishbone diagram (Ishikawa diagram)
√ Requirements Discovery
− Fact-finding techniques
√ Use Case Modeling
− Actors
− Use-cases
− Scenarios
− Model diagram
6 of 103
CLASSIFICATION of REQUIREMENTS
√ Business requirements include high-level statements

of goals, objectives, and needs of your project.
√ Stakeholder requirements help to find what end users
expect from a particular solution.
√ Solution requirements describe the product
characteristics that will meet end user expectations and
business needs.
− Functional requirements
− Nonfunctional requirements
7 of 103
TYPES of REQUIREMENTS
√ There are two types of solution requirements:

− Functional Requirement
• Specifies activities and services an application must
provide.
• Describes ways a product must behave.
− Nonfunctional Requirement
• Describes the general software characteristics that define a
satisfactory system.
8 of 103
FUNCTIONAL REQUIREMENTS
√ Examples:
− Students shall display his/her weekly schedule.
− Instructors shall display the list of students who are taking
his/her course.
− The mailing service shall send a welcome email when a
site visitor creates an account.
− The customers shall display the list of products in his/her
past orders.
9 of 103
NONFUNCTIONAL REQUIREMENTS
√ Any requirement that does not specify functionality

provided by the application like other features,
characteristics, constraints that define satisfactory
system
− Quality attributes
− Constraints
− External interfaces
− User interfaces
− Error handling
10 of 103
√ Examples:
− The Airport Radar Application shall experience no more
than two level-one faults per month.
• Reliability – this quality attribute specifies how likely the
system or its element would run without a failure for a given
period of time under predefined conditions.
− The web dashboard must be available to the users 98
percent of the time every month during business hours.
• Availability – this quality attribute describes how likely the
system is accessible for a user at a given point in time.
11 of 103
√ Examples:
− The average time for a maintenance engineer to repair a
severity-2 defect shall be no greater than 8 person-hours.
• Maintainability – this quality attribute specifies how easy or
difficult it is to modify the software, as a result of fixing a
defect or implementing an enhancement
◊ This nonfunctional requirement defines the time required for a
solution or its component to be fixed, changed to increase
performance or other qualities, or adapted to a changing
environment.
12 of 103
√ Examples:
− The landing page supporting 5 thousand users per hour
must provide 6 seconds or less response time in a
Chrome desktop browser, including the rendering of text
and images, over an LTE (a standard for wireless
broadband communication) connection.
• Performance – this quality attribute specifies timing
constraints that the application must observe
◊ This nonfunctional requirement defines how fast a software
system or its particular piece responds to certain users’ actions
under certain workload.
13 of 103
√ Examples:
− The user password in the login procedure of the
application shall contain at least 8 characters including
one upper letter and one digit.
• Security – this quality attribute concerns malicious intent
toward a system.
◊ This nonfunctional requirement assures that all data inside
the system or its part will be protected against malware
attacks or unauthorized access.
14 of 103
√ Examples:
− The graphics subsystem shall be designed so it can run in
both the Windows and Linux operating systems.
• Portability – this quality attribute establishes how well
actions performed via one platform are run on another.
− The iOS application must support iPhone devices running
on OS versions; 3.6, 3.3, 3.4, 4.3, 2.3
• Compatibility – this quality attribute defines how a system
can co-exist with another system in the same environment.
15 of 103
√ Examples:
− The error rate of users submitting their payment details at
the checkout page mustn’t exceed 10 percent.
• Usability – this quality attribute addresses a simple
question: How hard is it to use the product?
16 of 103
√ Examples:
− The student registration system shall calculate the
cumulative GPA within two-digit precision.
• Design constraint
− The student registration system shall be implemented in
Java and developed on the Eclipse platform.
• Software constraint
17 of 103
√ Examples:
− The student registration system shall be run on a server
with Intel Xeon E5 2600 v4 CPU.
• Hardware constraint
− The student registration system code shall be
documented using company code documentation
guidelines version 5.2.
• Certain standards
18 of 103
√ Examples:
− The inventory management system shall interface with a
model 1234 bar code reader.
• A nonfunctional requirement including an external hardware
interface feature.
− The inventory management system shall use Apache
HTTP Server version 2.4
• A nonfunctional requirement including an external software
interface feature.
19 of 103
√ Examples:
− The inventory management system shall communicate
with finance system via the company intranet.
• A nonfunctional requirement including a communication
interface feature.
− The inventory management system shall have at most
four functions in each menu.
• A nonfunctional requirement including a graphical user
interface (GUI) feature.
◊ Windows, menus, icons, colors, etc.
20 of 103
√ Examples:
− The course management system shall restrict the access
to the login page after three unsuccessful login attempts.
• A nonfunctional requirement including an error handling
process.
◊ Defines different ways of dealing with errors.
◊ ignore, warn user, restrict, allow unlimited tries, log and
proceed anyway, restart, shutdown, etc.
21 of 103
PROBLEM DISCOVERY
√ Fishbone diagram or Ishikawa diagram is a tool that

explains the cause and effect relationship for any quality
issue that has arisen or that may arise.
√ It provides the visual representation of all the possible
causes for a problem to analyze and find out the root
cause.
√ It is a tool to identify, analyze and solve problems.
22 of 103
PROBLEM DISCOVERY
√ Fishbone Diagram: (cont.)
23 of 103
PROBLEM DISCOVERY
√ How to Create a Fishbone diagram?

− Make the head of the fish in the right.
• Here we mention the subject (problem) that needs our
attention.
− Draw a backbone in the left.
− Draw branches to the backbones that will list the main
causes.
• List four to eight main causes.
− Attach causes and sub-causes to the main causes.
• These can be identified by organizing a brainstorming session.
24 of 103
PROBLEM DISCOVERY

− Example:
25 of 103
PROBLEM DISCOVERY

− Example:
26 of 103
REQUIREMENTS DISCOVERY
√ Requirements discovery is the process and tools used

to identify system requirements of the users of the
proposed system.
− also called information gathering or data collection
√ Project team members use fact-finding techniques to
gain a better understanding of the requirements of the
system during the requirements discovery process.
27 of 103
√ Fact-finding activities:
− Research
− Observation of the work environment
− Prototyping
− Sampling
− Questionnaires
− Interviews
− Meetings
• Joint Requirements Planning (JRP) sessions
28 of 103
√ Research
− Computer trade journals, reference books, and websites
of similar projects are a good source of information.
• They can provide information on how others have solved
similar problems.
29 of 103
√ Observation of the work environment

− The systems analyst either participates in or watches a
person when performing activities to learn about the system.
• Advantages
◊ Data gathered can be very reliable
◊ Can see exactly what is being done in complex tasks
• Disadvantages
◊ People may perform differently when being observed
◊ Timing can be inconvenient
◊ Interruptions
30 of 103
√ Prototyping
− The act of building a small-scale, representative, working model of
the requirements in order to ask the users to verify those
requirements.
• Advantages
◊ Can experiment to develop understanding of how system might work
◊ Aids in determining feasibility and usefulness of system before
development
◊ May minimize time spent on fact-finding
• Disadvantages
◊ Users may develop unrealistic expectations
◊ Could extend development schedule
31 of 103
√ Sampling
− Process of collecting a representative sample of
documents, forms and records.
• Organization chart
• Memos and other documents that describe the problem
• Standard operating procedures for current system
• Completed forms
• Manual and computerized screens and reports
• Samples of databases
• Flowcharts and other system documentation
32 of 103
√ Sampling (cont.)
− Things to be gleaned from documents:
• Symptoms and causes of problems
• Persons in organization who have understanding of
problem
• Business functions that support the present system
• Type of data to be collected and reported by the system
• Questions that need to be covered in interviews
33 of 103
− Techniques:
• Random sampling
◊ Each individual is chosen entirely by chance and each
member of the population has an equal chance, or probability,
of being selected.
◊ Advantage: the most straightforward method of sampling.
◊ Disadvantage: you may not select enough individuals with
your characteristic of interest, especially if that characteristic
is uncommon.
34 of 103
− Techniques: (cont.)
• Systematic sampling
◊ Individuals are selected at regular intervals from the sampling
frame.
◊ If you need a sample size n from a population of size x, you
should select every x/n-th individual for the sample.
◊ For example, if you want a sample size of 100 from a
population of 1000, select every 1000/100 = 10th member of
the sampling frame.
35 of 103
• Systematic sampling (cont.)
◊ Advantage: more convenient than random sampling
◊ Disadvantage: leads to bias; individuals with the same
characteristic may come one after another in the population.
36 of 103
• Stratified sampling
◊ The population is first divided into subgroups which all share
a similar characteristic, then either random or systematic
sampling is applied on each subgroup.
◊ It is used when we want to ensure representation from all the
subgroups.
37 of 103
• Stratified sampling (cont.)
◊ For example, we may stratify the successfully completed
software development projects by their application type, to
ensure equal representation of projects with different
complexities.
◊ Advantage: improves the representativeness of the results by
reducing sampling bias.
◊ Disadvantage: requires knowledge of the appropriate
characteristics of the sampling frame
38 of 103
− Finding an appropriate sample size
39 of 103
− Finding an appropriate sample size (cont.)
• Example: Suppose that the analyst wants to be 90% certain
that a sample of invoices will contain no unsampled
variations over 6800 samples.
2
1.645
SampleSize=0.25∗
0.10 ( ) =68
◊ If the required sample size was 68, a program could be
written that prints every 100-th record.
40 of 103
√ Questionnaires
− A research instrument consisting of a series of questions
for the purpose of gathering information from
respondents.
− Questionnaires can be thought of as a kind of written
interview.
− They can be carried out face to face, by telephone,
computer or post.
41 of 103
√ Questionnaires (cont.)
− Questionnaire Formats
• Questions in Open Ended Format
◊ Questions give respondents an opportunity to express what
they feel freely.
◊ Questions are not based on pre-determined responses.
◊ Mostly placed at the end of a questionnaire tend to draw
accurate feedback and suggestions from respondents as well.
• Questions in Closed Ended Format
◊ Questions that require selecting an answer from predefined
available responses.
42 of 103
− Examples:
• How do you go about booking tickets for a flight?
◊ An open ended question
• Do you think that the number of branches available for our

bank is adequate?
– Yes – No
◊ A "yes" or "no" question
43 of 103
− Examples: (cont.)
• How often do you conduct surveys?
1- Weekly, 2- Monthly, 3- Quarterly, 4- Annually
◊ A multiple choice question
• How often do you visit the calculate gpa option?

1- Never, 2- Rarely, 3- Sometimes, 4- Often, 5- Always
◊ A likert question
44 of 103
• The response time of our student registration system to
calculating GPA is no more than five seconds.
1- Strongly agree, 2- Agree, 3- No opinion, 4- Disagree,
5- Strongly Disagree
◊ A rating question
45 of 103
• Rank the below transactions according to the amount of
time you spend processing
– % new customer orders, – % order cancellations,
– % order modifications, – % payments
◊ A ranking question
46 of 103
− Developing a Questionnaire:
• Determine what facts must be collected and from whom you
should get them.
• Based on the facts and opinions sought, determine whether
open or closed ended questions will produce the best
answers.
• Write the questions
• Test the questions on a small sample of respondents.
47 of 103
− Advantages
• Often can be answered quickly
• People can complete at their convenience
• Relatively inexpensive way to gather data from a large number
• Allow for anonymity
• Responses can be tabulated quickly
− Disadvantages
• Return rate is often low
• No guarantee that an individual will answer all questions
• No opportunity to reword or explain misunderstood questions
• Cannot observe body language
• Difficult to prepare
48 of 103
√ Interviews
− A technique to collect information from individuals through
face-to-face interaction.
− Types of interviews:
• Unstructured interview
◊ Conducted with only a general goal or subject in mind and
with few, if any, specific questions.
• Structured interview
◊ Interviewer has a specific set of open and/or closed ended
questions.
49 of 103
√ Interviews (cont.)
− Interview question guidelines:
• Use clear and concise language
◊ avoid long or complex questions.
• Types of questions to avoid (Do not include your opinion as
part of your question. )
◊ Do we have to have both of these columns on the report?
◊ You're not going to use this operator code, are you?
◊ How many codes do we need? I think 20 ought to cover it.
50 of 103
√ Interviews (cont.)
− Advantages
• Give analyst opportunity to motivate interviewee to respond freely
and openly
• Allow analyst to probe for more feedback
• Permit analyst to adapt or reword questions for each individual
• Can observe nonverbal communication
− Disadvantages
• Time-consuming
• Success highly dependent on analyst's human relations skills
• May be impractical due to location of interviewees
51 of 103
√ Meetings: Joint Requirements Planning (JRP)

− A technique for drawing out user requirements through
joint planning sessions of software users and information
technology personnel.
− These informal sessions are workshops that provide an
open environment for people to discuss what they do, how
they do it, and what critical information they need to
support their job responsibilities.
− Written documentation defining these requirements
results from a JRP session.
52 of 103
√ Meetings: Joint Requirements Planning (JRP) (cont.)

− JRP Participants:
• Facilitator
◊ Plans, conducts and leads the session, follows through on the
requirements.
• Sponsor
◊ Person who is a part of top management, leads the session with
the facilitator, makes closing remarks for the session.
• Users and Managers
◊ Stakeholders of the project who have knowledge about project
goals, objectives, piorities, plans, costs and requirements.
53 of 103

− JRP Participants: (cont.)
• IT Staff
◊ Technical members who listens and takes notes about the
requirements and necessary issues voiced by users and
managers.
− Benefits
• JRP actively involves users and management in the
development project
• JRP reduces the amount of time required to develop systems.
54 of 103

− Steps to Plan a JRP Session:
• Selecting a location away from workplace where equipped
with all necessary physical and technological conditions.
• Selecting the participants
• Preparing the agenda to setting guidelines for
brainstorming.
◊ Brainstorming is a technique for generating ideas during
group meetings.
55 of 103
USE CASE MODELING
√ Use case modeling is the process of modeling a

system’s functions in terms of business events, who
initiated the events, and how the system responds to
those events.
√ A use case model shows a view of the system from the
user perspective describing what a system does.
√ The key elements in a use case model are actors and
use cases.
56 of 103
USE CASE MODELING
√ A use case is a behaviorally related sequence of steps

for the purpose of completing a single business task.
− used to document a single transaction or event.
• An event is an input to the system that happens at a
specific time and place and causes the system to do
something.
√ A use case is a list of actions or event steps typically
defining the interactions between an actor and a system
to achieve a goal.
57 of 103
USE CASE MODELING
√ A use case describes how the system should respond

under various conditions to a request from one of the
stakeholders to deliver a specific goal.
− This is primarily done in the form of a scenario that
describes a sequence of steps.
√ A use case is a unit of functionality (a requirement), or a
service, in the system.
− not a process, or program, or function.
58 of 103
USE CASE MODELING
√ A use case is a single unit of meaningful work

− Take the functional requirements into account when
defining use cases.
• login to system
• register with system
• create order
• display weekly schedule
√ Use a verb phrase in naming a use case !
59 of 103
USE CASE MODELING
√ An actor is anyone or anything that needs to interact

with the system to exchange information.
√ An actor is anyone or anything with behavior.
√ An actor is an entity (human or otherwise) external to
the system, and which interacts with it.
− human, organization, another information system, external
device, time
√ Use a noun or noun phrase in naming an actor !
60 of 103
USE CASE MODELING
√ Types of actors:
− Primary Actor is an actor that interacts with the system
to achieve a specific goal.
• often triggers the use case.
• Examples:
◊ the user clicking the search button on an application's user
interface.
◊ The customer adding products to the shopping cart.
61 of 103
USE CASE MODELING
√ Types of actors: (cont.)

− Supporting (Secondary) Actor is an actor that the
system needs assistance from to achieve the primary
actor’s goal.
• an external actor that provides a service to the system
• Examples:
◊ the credit bureau authorizing a credit card charge
◊ the database system responding to an SQL request with a
result set.
62 of 103
USE CASE MODELING

− Example – Process Sale: A customer arrives at a checkout
with items to purchase. The cashier uses the POS system to
record each purchased item. The system presents a running
total and line-item details. The customer enters payment
information, which the system validates and records. The
system updates inventory. The customer receives a receipt
from the system and then leaves with the items.
• Primary actor: Cashier processing the customer’s sale
• Supporting actor: Credit bureau authorizing credit card charge
63 of 103
USE CASE MODELING

− Example – Enterprise Selling Things: A customer visits the web
pages of the enterprise to search for and buy items. The customer
adds items to the shopping cart. When the customer completes the
shopping, he/she clicks the payment page. The system presents a
running total and line-item details. The customer enters payment
information, which the system validates and records. The system
updates inventory. The customer receives a receipt from the
system and then leaves the system and waits for the shipment of
the items.
• Primary actor: Customer buying items.
• Supporting actor: Credit bureau authorizing credit card charge
64 of 103
USE CASE MODELING

− Primary and supporting actor specification depends on the
system boundary of the system under design.
− An actor can be the primary actor for one use case and
the supporting actor for another.
65 of 103
USE CASE MODELING
√ Questions to identify actors:

− Which user groups require help from the system to
perform their tasks?
− Which user groups are needed to execute the system’s
most obvious main functions?
− Which user groups are required to perform secondary
functions, such as system maintenance and
administration?
− Will the system interact with any external hardware or
software system?
66 of 103
USE CASE MODELING
√ Actor Glossary:
− Example:
Actor Description
Member An individual that has joined the club via an agrement.
A member that has fulfilled the agreement obligation

Past Member
but not submitted a new subscription order yet.
A unit that houses and maintains the product inventory,

Distribution Center
and processes customer shipments and returns.
67 of 103
USE CASE MODELING
√ Use Case Glossary:

− Example:
Use Case Name Description Participating Actors
Shopper
This use case describes the event of a Bank system
Place Order shopper submitting an order for XXX Authentication system
products. Fulfillment system
Billing system
68 of 103
USE CASE MODELING
√ A Use Case Scenario is a textual description of the

business event and how the actors will interact with the
system to accomplish the task.
√ There may be different templates with different sections
in scenario preparation.
− A scenario template is also called fully dressed use case
template.
69 of 103
USE CASE MODELING
√ Sections in a scenario are as follows:

− Use case name
− Use case description
− Primary actor(s)
− Supporting actor(s)
− Triggers
− Preconditions
− Postconditions
− Normal flow
− Alternate flows
− Business rules
70 of 103
USE CASE MODELING
√ A scenario template (a fully dressed use case):

Use case name: Place order
Once the shopper has selected items to purchase,
he/she orders the items. The system authorizes the
shopper. The shopper will provide payment and
shipping information. The shopper may already
have an account with the company with billing and
shipping information. The bank validates the credit
card and charges the amount. The system will
Use Case Description:
respond with confirmation of the order and a
tracking number that the shopper can use to check
on order status in the future. The system will also
provide the shopper with an estimated delivery date
for the order, which will include all selected items.
The shopper shall only be billed when the products
are shipped.
71 of 103
USE CASE MODELING
√ A scenario template (a fully dressed use case): (cont.)

● Shopper placing the order with the selected
Primary actor(s):
products.
● Bank system validating credit card and charging

the amount.
● Authentication system authorizing shoppers and
processing their account details.
Supporting actor(s): ● Fulfillment system processing orders for delivery
to shoppers.
● Billing System billing shoppers for orders that
have been placed.
72 of 103
USE CASE MODELING

The shopper indicates that he/she wants to
Triggers purchase items that he/she has selected and clicks
the place order button.
● The shopper must be a registered user.
● The shopper has selected the items to be
Preconditions
purchased.
● The items must be in stock.
● The order will be placed in the system.

● The shopper will have a tracking ID for the order.
Postconditions
● The shopper will know the estimated delivery date
for the order.
73 of 103
USE CASE MODELING
1. The shopper indicates that he/she wants to order

the items that have already been selected.
2. The authentication system requests that the
shopper enters his/her username and password.
3. The shopper enters his/her username and
password.
Normal Flow
4. The authentication system validates the shopper.
5. The billing system presents the amount that the
order will cost, including applicable taxes and
shipping charges.
6. The shopper will confirm that the order details are
accurate.
74 of 103
USE CASE MODELING
7. The authentication system presents the billing and

shipping information that the shopper previously
stored.
8. The shopper confirms that the existing billing and
shipping information should be used for this order.
9. The bank system validates the credit card and
charges the total amount.
Normal Flow
10.The bank system confirms that the charge has
been placed for the order.
11.The fulfillment system provides the shopper with
a tracking ID and an estimated delivery date for
the order.
12.The fulfillment system indicates to the shopper
that the order has been placed.
75 of 103
USE CASE MODELING
2A. If the shopper does not have an account, he/she

can create an account or cancel the login, at
which point the use case ends.
4A. If the username or the password is invalid, an
error message is displayed and the shopper is
asked to re-enter the username/password
Alternate Flows information.
6A. The shopper may change the ordered items and
the quantities by cancelling the place order event
and visiting the select products event again.
8A. The shopper enters another billing and shipping
information.
76 of 103
USE CASE MODELING

10A-1. The shopper is informed about the problem
with his/her credit card validation, asked to solve
the problem, and redirected to Step 1 of normal
Alternate Flows flow.
● The shopper is informed about the problem with
his/her credit card limits, asked to solve the

problem, and redirected to Step 1 of normal flow.
● The shopper must be a registered user to place
an order.
Business Rules ● The shopper is billed for products only when they
are shipped.
77 of 103
USE CASE MODELING
√ A user story is a documented description of a software

feature seen from the end-user perspective.
− User stories are part of an agile approach that helps shift
the focus from writing about requirements to talking about
them.
√ The user story describes what exactly the user wants
the system to do.
− All agile user stories include a written sentence or two
and, more importantly, a series of conversations about the
desired functionality.
78 of 103
USE CASE MODELING
√ In Agile projects, user stories are organized in a

backlog, which is an ordered list of product functions.
− Currently, user stories are considered to be the best
format for backlog items.
− They are often recorded on index cards, on Post-it notes,
or digitally in project management software.
79 of 103
USE CASE MODELING
√ Great User Stories always fit the INVEST set of criteria by Bill Wake:
− Independent – they can be developed in any sequence and changes to
one User Story don’t affect the others.
− Negotiable – it’s up for the team to decide how to implement them; there
is no rigidly fixed workflow.
− Valuable – each User Story delivers a detached unit of value to end
users.
− Estimable – it’s quite easy to guess how much time the development of
a User Story will take.
− Small – it should go through the whole cycle (designing, coding, testing)
during one sprint.
− Testable – there should be clear acceptance criteria to check whether a
User Story is implemented appropriately.
80 of 103
USE CASE MODELING
√ Some common templates used in writing user stories:
As a <role> I can <capability>, so that <receive benefit>.
In order to <receive benefit> as a <role>, I can

<goal/desire>.
As <who> <when> <where>, I <want> because <why>.
81 of 103
USE CASE MODELING
√ Examples (user stories):

− As the HR manager, I want to create a screening quiz so
that I can understand whether I want to send possible
recruits to the functional manager.
− As a manager, I want to browse my existing quizzes so I
can recall what I have in place and figure out if I can just
reuse or update an existing quiz for the position I need
now.
82 of 103
USE CASE MODELING
√ Examples (user stories):

− As a user, I want to indicate folders not to backup so that
my backup drive isn't filled up with things I don't need
saved.
− As an admin, I want to add descriptions to products so
that users can later view these descriptions and compare
the products.
− As a passenger, I want to link the credit card to my profile
so that I can pay for a ride faster, easier and without cash.
83 of 103
USE CASE MODELING
√ How to write effective user stories?
84 of 103
USE CASE MODELING
√ How to write effective user stories? (cont.)

− Initiatives are collections of epics that drive toward a
common goal.
− Epics are large bodies of work that can be broken down
into a number of smaller tasks called stories.
• Epics are almost always delivered over a set of sprints.
− Stories, also called “user stories”, are short requirements
or requests written from the perspective of an end user.
• Stories are something the team can commit to finish within a
one or two-week sprint.
85 of 103
USE CASE MODELING

− Example:
• Initiative: Develop a video player
• Epic#1: Improve Streaming Service for Q1 Launch.
• User Story#1: iPhone users need access to a vertical view
of the live feed when using the mobile app.
• User Story#2: Desktop users need a “view fullscreen”
button in the lower right hand corner of the video player.
• User Story#3: Android users need to be linked to apple
store.
86 of 103
USE CASE MODELING

− It is also important to have acceptance criteria to help the
project team know when a user story is considered
complete or “done”.
87 of 103
USE CASE MODELING
INITIATIVE EPIC USER STORY ACCEPTANCE CRITERIA
Ensure the bidder is able to:
As a bidder, I want to
select an auction ● Login to the platform
As a bidder, I product so that I can ● Navigate to the auction page
want to access bid on it. ● Select product(s) to bid on
the ordering
DEVELOP platform behind a Ensure the bidder is able to:
AN secure login so
that I can As a bidder, I want to ● Login to the platform
AUCTION
purchase review my previous ● Navigate to a page to review
SYSTEM
products. bids so that I can items previously bid upon
remove expired bids. ● Select one, or multiple, expired
bids
● Remove expired bids
As a ... As a ...
88 of 103
USE CASE MODELING
√ A use case diagram is a diagram that represents the

interactions between the system and external systems
and users.
− Graphically describes who will use the system and in what
ways the user expects to interact with the system.
− A tool for diagrammatically summarizing the set of actors
and use-cases.
89 of 103
USE CASE MODELING
√ In a use case diagram, Course Management System
− The system boundaries is represented by
− A use case is represented by Process order
− An actor is represented by
Customer
90 of 103
√ Use case diagram example:
91 of 103
USE CASE MODELING
√ Use case relationships:

− Association
• The association relationship is the interface between an
actor and a use case.
◊ An actor must be associated with at least one use case.
◊ An actor can be associated with multiple use cases.
◊ Multiple actors can be associated with a single use case.
• It is represented by a line between an actor and a use case.
92 of 103
USE CASE MODELING
√ Use case relationships: (cont.)

− Include (uses)
• A use case includes the functionality described in another
use case as a part of its business process flow.
• A uses relationship from base use case to child use case
indicates that an instance of the base use case will include
the behavior as specified in the child use case.
• Include relationship is used to show that the child use case
is always called when the original (parent) use case is
executed.
93 of 103
USE CASE MODELING

− Include (uses) (cont.)
• An include relationship is depicted with a directed arrow
having a dotted line. The tip of arrowhead points to the child
use case and the parent use case connected at the base of
the arrow.
• The stereotype "<<include>>" identifies the relationship as
an include relationship.
94 of 103
USE CASE MODELING

− Generalization
• There may be instances where actors are associated with
similar use cases while triggering a few use cases unique
only to them.
• In such instances, you can generalize the actor to show the
inheritance of functions.
• You can do a similar thing for use case as well.
95 of 103
USE CASE MODELING

− Generalization (cont.)
• NRFC: Non-Resident Foreign Currency Accounts
96 of 103
USE CASE MODELING

− Generalization (cont.)
• A generalization relationship is a parent-child relationship
between use cases.
◊ The child use case is an enhancement of the parent use
case.
◊ Generalization is shown as a directed arrow with a triangle
arrowhead.
◊ The child use case is connected at the base of the arrow. The
tip of the arrow is connected to the parent use case.
97 of 103
USE CASE MODELING

− Extend
• This relationship extends the base use case and adds more
functionality to the system.
• In such cases, you can use the extend relationship and
attach an extension rule to it.
98 of 103
USE CASE MODELING
99 of 103
USE CASE MODELING

− Extend (cont.)
• The extending use case is dependent on the extended (base) use case.
◊ In the example, the “Calculate Bonus” use case doesn’t make much sense
without the “Deposit Funds” use case.
• The extending use case is usually optional and can be triggered
conditionally.
◊ In the example, you can see that the extending use case is triggered only
for deposits over 10,000 or when the age is over 55.
• The extended (base) use case must be meaningful on its own.
◊ This means it should be independent and must not rely on the behavior of
the extending use case.
100 of 103
USE CASE MODELING
√ Example:
101 of 103
USE CASE MODELING
√ Example:
102 of 103
REFERENCES
√ The below resources are used to prepare some examples and figures given in
these slides:
− https://www2.cs.duke.edu/courses/cps108/spring04/readings/usecaseslarman.pd
f
− Getting Started With Use Case Modeling, An Oracle White Paper, May 2007
− http://tynerblain.com/blog/2007/04/09/sample-use-case-example/
− https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-
use-case-diagram/
− https://creately.com/blog/diagrams/use-case-diagram-relationships/
− https://medium.com/@warren2lynch/use-case-learn-by-examples-5a63b67fa64d
− https://tech.gsa.gov/guides/user_story_example/
− https://www.atlassian.com/agile/project-management/user-stories
103 of 103

Chapter 4

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 4

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 4

Uploaded by

Copyright:

Available Formats

SEN2022 SOFTWARE ENGINEERING

ANALYSIS AND DESIGN

CHAPTER 4: REQUIREMENTS ANALYSIS

Prepared by Prof. Dr. M. Alper TUNGA

√ System (business) requirement is something that the

√ Requirements analysis is the process of

√ Requirements analysis phase defines the business

What do the users need and want from a new system?

− Sources: Stakeholders – mainly owners and customers

√ Business requirements include high-level statements

√ There are two types of solution requirements:

√ Any requirement that does not specify functionality

√ Fishbone diagram or Ishikawa diagram is a tool that

√ Fishbone Diagram: (cont.)

√ How to Create a Fishbone diagram?

√ Fishbone Diagram: (cont.)

√ Fishbone Diagram: (cont.)

√ Requirements discovery is the process and tools used

√ Observation of the work environment

• Do you think that the number of branches available for our

• How often do you visit the calculate gpa option?

√ Meetings: Joint Requirements Planning (JRP)

√ Meetings: Joint Requirements Planning (JRP) (cont.)

√ Meetings: Joint Requirements Planning (JRP) (cont.)

√ Meetings: Joint Requirements Planning (JRP) (cont.)

√ Use case modeling is the process of modeling a

√ A use case is a behaviorally related sequence of steps

√ A use case describes how the system should respond

√ A use case is a single unit of meaningful work

√ An actor is anyone or anything that needs to interact

√ Types of actors: (cont.)

√ Types of actors: (cont.)

√ Types of actors: (cont.)

√ Types of actors: (cont.)

√ Questions to identify actors:

Member An individual that has joined the club via an agrement.

A member that has fulfilled the agreement obligation

A unit that houses and maintains the product inventory,

√ Use Case Glossary:

Use Case Name Description Participating Actors

√ A Use Case Scenario is a textual description of the

√ Sections in a scenario are as follows:

√ A scenario template (a fully dressed use case):

√ A scenario template (a fully dressed use case): (cont.)

● Bank system validating credit card and charging

√ A scenario template (a fully dressed use case): (cont.)

● The order will be placed in the system.

√ A scenario template (a fully dressed use case): (cont.)

1. The shopper indicates that he/she wants to order

√ A scenario template (a fully dressed use case): (cont.)

7. The authentication system presents the billing and

√ A scenario template (a fully dressed use case): (cont.)

2A. If the shopper does not have an account, he/she

√ A scenario template (a fully dressed use case): (cont.)

his/her credit card limits, asked to solve the

√ A user story is a documented description of a software

√ In Agile projects, user stories are organized in a