Requirements Engineering

Software Engineering

Muním Zabidi
Faculty of Electrical Engineering, UTM
Table of Contents

1 What Are Requirements

2 Requirements Engineering Process

3 Requirements Validation

4 Requirements Elicitation

5 Software Requirements Specification (SRS) Document

6 Use Cases

7 User Stories

8 Activity Diagrams

9 References

© Muním Zabidi 2
 What Are Requirements

© Muním Zabidi 3
Scope of Software Project Failures

Project Impaired Factors % of Responses

Incomplete Requirements 13.1%
Lack of User Involvement 12.4%
Lack of Resources 10.6%
Unrealistic Expectations 9.9%
Lack of Executive Support 9.3%
Changing Requirements & Specifications 8.7%
Lack of Planning 8.1%
Didn’t Need it any longer 7.5%
Lack of IT Management 6.2%
Technology Illiteracy 4.3%

Jim Johnson, The Standish Group International Project Leadership Conference, May 1995, Chicago

© Muním Zabidi 5
Relative Cost to Fix an Error

Phase Error Found In Cost Ratio

Requirements 1
Design 3-6
Coding/Implementation 10
Development testing (unit) 15-40
Acceptance testing 30-70
Operation (field) 40-100

From Barry Boehm’s Software Engineering Economics, 1981

He developed the COCOMO and COCOMO II models of software economics
These data based on 63 plan-driven projects

© Muním Zabidi 6
What Are Requirements?

A software requirement is a statement of one thing a product must do or a quality it

must have
It may range from a high-level abstract statement of a service or of a system constraint to a
detailed mathematical functional specification
Requirements describe what not how

© Muním Zabidi 7
Requirements Engineering

Also known as Systems Analysis or Requirements Analysis

It is the process of defining user expectations
Results in a specification of the system that stakeholders understand
natural language
easy to understand pictures (UML Diagrams)
Requirements are documented as:
Software Requirements Specification (SRS) document
use cases or
user stories

© Muním Zabidi 8
Stakeholders

A stakeholder is anyone who should have some direct or indirect influence on the
system requirements.

Users use the system

Sponsors pay for system
Solution team provide information such as the feasibility of the
solution, potential costs, time
Legal them compliance adherence

© Muním Zabidi 9
Types of Requirements

Software requirements specify what to build, not how. It describes the problem, and not the
detailed solution.
Functional requirements
Describe what the system should do.
Can be objectively measured and verified
They are often called product features.
Examples: login feature, add item to cart, checkout process
Non-functional requirements
Describe how the system should perform
Related to attributes rather than functionality
More subjective and broader in scope
Examples: performance, usability, reliability, maintainability, scalability

© Muním Zabidi 10
FURPS+

FURPS is an acronym representing a model for classifying software quality attributes

Developed at Hewlett-Packard
First publicly elaborated by Grady and Caswell [GC87]
FURPS+ is now widely used in the software industry.
The “+” was adder later to extend the acronym to emphasize attributes such as design
constraints, implementation requirements, interface requirements and physical
requirements.

© Muním Zabidi 11
FURPS

Functionality Activities the system must perform

Usability Human factors such as user interface, documentation, work
procedures, responsiveness
Reliability Availability, frequency and extent of failures, accuracy, preditability
Performance Speed, efficiency, resource usage, throughput, capacity, scalibility
Security Access to the software and data protection mechanisms

© Muním Zabidi 12
FURPS+

FURPS+ is an extension of FURPS that includes design constraints as well as

implementation, interface, physical and supportability requirements

Design constraints restrictions for designing a system

Implementation constrains the construction of a system such as programming

languages , tools, documentation standards, level of detail
Interface specifies interactions with external systems

Physical specifies hardware characteristics such as size, weight, power

consumption, and operating conditions
Supportability specifies how a system is installed, configured, monitored and
updated

© Muním Zabidi 13
 Requirements Engineering Process

© Muním Zabidi 14
Steps in Requirements Engineering

Feasibility Requirements Requirements Requirements

study elicitation specification validation

Draft Validated
Feasibility
requirements requirements
report
document document

© Muním Zabidi 15
SE Phases & Outputs

© Muním Zabidi 16
Models in Requirements Engineering

Requirements Analysis Design Implement & Deploy

Business Activity Design

process Diagram Domain Package
Class
Model Diagram
Diagram

Use Case Use Case State Component

Diagram Description Diagram Diagram

System
Sequence Deployment
Sequence
Diagram Diagram
Diagram

© Muním Zabidi 17
Feasibility Study

A feasibility study is a study made before committing to a project

It decides whether or not the proposed system is
possible to build with current technology
affordable given the time and budget constraints
worthwhile contributing to organizational objectives

© Muním Zabidi 18
Information Gathering

also known as Requirements Elicitation step

Interacting with users to identify their needs
Need to understand why not just what
Techniques
Interviews
Questionnaires
Observation
Document analysis
Prototypes
Joint Application Design (JAD) Session
Groupware
Focus groups
On-site customer
Policy/law documents

© Muním Zabidi 19
Defining the Requirements

Filtering the information

Conversion to models:
Use case
Data flow diagrams (for classical projects)
User stories
Activity diagrams

© Muním Zabidi 20
Writing the Requirements

Characteristics of a good requirement statement:

Correct Accurately states a customer need

Unambiguous Has only one possible meaning
Prioritized Essential vs. desirable function points clearly spelled out.
Concise 1 page is better than 3 pages if all validation criteria are met
Feasible Requirements can be implemented and delivered
Traceable Each system function can be traced to a corresponding set of functional
requirements
Complete All possible scenarios through the system are described, including
exceptional behavior by the user or the system
Testable One must be able to create a test or some sort of proof that the
requirement has been met.
Consistent Requirements do not contradict each other
Design-free Everything about what the customer wants and nothing about how the
programmer(s) will do it

© Muním Zabidi 21
Writing the Requirements
Shall (== is required to):
used to indicate mandatory requirements strictly to be followed in order to
conform to the standard and from which no deviation is permitted. (must or
will is obsolete)
Should (== is recommended that):
used to indicate
among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others
or that a certain course of action is preferred but not necessarily required;
or that (in the negative form) a certain course of action is deprecated but
not prohibited
May (== is permitted to):
used to indicate a course of action permissible within the limits of the standard
Can (== is able to):
used for statements of possibility and capability, whether material, physical, or
causal
https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf See Section 9 [IEE20]
© Muním Zabidi 22
Prioritizing the Requirements

The priority of requirements determines the order

in which they will be implemented.
MoSCoW Approach [CB94]
Essential have to be realized to make the system
acceptable to the customer. M ust have
Desirable highly desirable, but not mandatory o
requirements S hould have
Optional might be realized if time and resources C ould have
permit
o
Future requirementwill not be realized in the
W on’t have this time
current version of the system-to-be, but
should be recorded for consideration in
future versions

© Muním Zabidi 23
Levels of Detail

User Stories Use Cases Requirements

Goal Generate conversations Capture a behavior Establish a contract
Scope A single activity A process Everything
Format A single sentence Numbered bullets Specifications
Completeness Open for negotiation Locked Locked
Language Simple Structured, flows Precise, techinical

© Muním Zabidi 24
 Requirements Validation

© Muním Zabidi 25
Requirements Validation

Make sure gathered information is correct

Requirements reviews
System manual analysis of the requirements
Prototyping
Using an executable model to check the requirements
Test-case generation
Developing tests to check testability
Automated consistency analysis
Checking the consistency of the requirements description

© Muním Zabidi 26
Requirements Validation

© Muním Zabidi 27
 Requirements Elicitation

© Muním Zabidi 28
Information Gathering Techniques

A system analyst must have the ability to gather the right information so that the system
requirements are accurate and complete.
The ultimate aim is to understand the problem that the software is required to solve
Fundamentally a human activity
Some common methods (some more effective than others):
Interviews
Questionnaires
Prototyping
Observation
Document analysis

© Muním Zabidi 29
Interviews Question Themes

1. What are the business processes?

Understand the business function
User will most likely answer in terms of the current system
You as analyst must discover which functions are fundamental and which may be eliminated
in the new system
2. How is the business process performed?
Focus on how the new system will support the business
Discover the system requirements in terms of the new system
3. What information is needed?
Defines specific information on the new system

Question Types:

Open-ended questions – encourage discussion or explanation

Close-ended questions – elicit specific facts

© Muním Zabidi 30
Conducting Interviews

Benefits:
Interactive discussion with stakeholders.
The immediate follow-up to ensure the interviewer’s understanding.
Encourage participation and build relationships by establishing rapport with the stakeholder.
Drawbacks:
Time is required to plan and conduct interviews.
Commitment is required from all the participants.
Sometimes training is required to conduct effective interviews.

© Muním Zabidi 31
Survey/Questionnaires
A set of questions is given to stakeholders to quantify their thoughts.
After collecting the responses from stakeholders, data is analyzed to identify the area of
interest of stakeholders.
Open-Ended: Respondent is given the freedom to provide answers in their own words
rather than selecting from predefined responses.
Close Ended: It includes a predefined set of answers for all the questions and the
respondent has to choose from those answers. Questions can be multiple choice or can
be ranked from not important to very important.
Benefits:
Easy to get data from a large audience.
Less time is required for the participants to respond.
You can get more accurate information as compared to interviews.
Drawbacks:
All the Stakeholders might not participate in the surveys.
Questions may not be clear to all the participants.
Open-ended questions require more analysis.
© Muním Zabidi 32
Observation

The main objective is to understand the activity, task, tools used, and events performed
by others.
Active observation is to ask questions and try to attempt the work that other persons
are doing.
Passive observation is silent observation i.e. you sit with others and just observe how
they are doing their work without interpreting them.
Benefits:
The observer will get a practical insight into the work.
Improvement areas can be easily identified.
Drawbacks:
May make users nervous.
Users might change their way of working during observation and the observer might not get a
clear picture.
Knowledge-based activities cannot be observed.

© Muním Zabidi 33
Document Analysis

Review/examine the available materials that describe the business environment.

Document analysis includes reviewing the business plans, technical documents,
problem reports, existing requirement documents, etc
Able to identifying the gaps in the system i.e. compare the AS-IS process with the TO-BE
process
Benefits:
Existing documents can be used to compare current and future processes
Existing documents can be used as a base for future analysis
Drawbacks:
Existing documents might be outdated
Time-consuming

© Muním Zabidi 34
Prototyping
Prototypes model the working of a more complex system
Client can get an idea of the "look and feel" of the new system
Lo-fi prototypes check & test functionality
Hi-fi prototypes appear & function very close to the actual product
Benefits:
Gives a visual representation of the product.
Stakeholders can provide feedback early.
Drawbacks:
May become time-consuming if the system or process is highly complex

© Muním Zabidi 35
 Software Requirements
Specification (SRS) Document

© Muním Zabidi 36
Software Requirements Specification (SRS)

Detailed description of a software system to be developed

Created at the beginning of the software development lifecycle as a reference for the
design, development, testing, and maintenance of the software
Defines software requirements (functional, non-functional, constraints)
Includes features, user interfaces, data models, use cases, system architecture
Critical to project success, ensures understanding, and keeps project on track and on
budget

© Muním Zabidi 37
Software Requirement Specification (SRS)

SRS should have the following features:

User requirements are expressed in natural language.
Technical requirements are expressed in technical language so that they can be
comprehended by the software development team.
Design description should be written in pseudocode.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for dataflow diagrams (DFDs) etc.

© Muním Zabidi 38
IEEE Software Engineering Standards

IEEE Computer Society has working groups and subcommittees on working on software
engineering standards

Table: IEEE Standards for Software Engineering Documentation.

Standard Acronym Document

IEEE 730 SQAP Software Quality Assurance Plan
IEEE 828 SCMP Software Configuration Management Plan
IEEE 829 STD Software Test Documentation
IEEE 830 SRS Software requirements specification
IEEE 1012 SVVP Software Validation & Verification
IEEE 1016 SDD Software Design Description
IEEE 1058 SPMP Software Project Management Plan
IEEE 1063 SUD Software User Documentation

© Muním Zabidi 39
Model IEEE SRS

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements

© Muním Zabidi 40
Model Part 3 IEEE SRS

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communication Interfaces
3.2 Functional Requirements
3.2.1 Mode 1
3.2.1.1 Functional Requirement 1.1
:
3.2.1.3 Functional Requirement 1.n

3.2.m Mode m
3.2.m.1 Functional Requirement m.1
:
3.2.m.n Functional Requirement m.n
3.3 Performance Requirements
3.4 Design Constraints
3.5 Attributes
3.6 Other Requirements

© Muním Zabidi 41
Traditional Requirements

ID REQ001
Title Calculate the Area of a Rectangle
Description The system shall provide a function that calculates the area of a
rectangle based on its length and width.
Rationale The ability to calculate the area of a rectangle is a fundamental re-
quirement for any system that deals with geometric calculations.
Priority High
Dependencies None
Functional Requirements - The system shall accept input values for the length and width of
a rectangle.
- The system shall calculate the area of the rectangle using the
formula: area = length * width.
- The system shall display the calculated area on the screen.
Non-functional Requirements - The area calculation shall be accurate to at least two decimal
places.
- The area calculation function shall execute within 1 second for
rectangles with length and width values up to 100 units.

© Muním Zabidi 42
Traditional Requirements

ID REQ002
Title User Authentication
Description The system shall authenticate users before allowing ac-
cess to secure features.
Rationale Authentication is necessary to protect sensitive informa-
tion and prevent unauthorized access to secure features.
Priority Medium
Dependencies None
Functional Requirements - The system shall require users to provide a valid user-
name and password to access secure features.
- The system shall compare the provided username and
password with stored user credentials.
Non-functional Requirements - The user authentication process shall be completed
within 5 seconds to provide a responsive user experience.

© Muním Zabidi 43
 Use Cases

© Muním Zabidi 45
What are Use Cases?

An effective and widely used technique for requirements elicitation

A use case is a written description of how users will perform tasks
A set of scenarios that describe an interaction between a user and a system
A scenario is a sequence of simple steps, beginning with a user’s goal and ending when
that goal is fulfilled.
A use case emphasises on what a system does rather than how.

© Muním Zabidi 46
Why use Use Cases?

Easy to use even for non-technical people

Its simplicity makes use case diagrams a good way for developers to communicate with
clients.
Determining features
New use cases often generate new requirements as the system is analyzed and the
design takes shape. Use case modeling helps us design a system from the end user’s
perspective
Generating test cases
The collection of scenarios for a use case may suggest a suite of test cases for those
scenarios.

© Muním Zabidi 47
Use Case Deliverables

Use Case Components

Use Case Diagram Use Case Specification

1. Use Case Name

1. Actors
2. Brief Description
3. Actors
2. Use Cases
4. Pre-condition
5. Post-condition
3. Boundary box
6. Basic flow
7. Alternative flows
4. Relationships
8. Exception flows

© Muním Zabidi 48
Use Case Diagrams

UCD describes the system’s intended functions and its

environment.
The primary form of requirements for a new software Actor
under development
A use case diagram is usually simple. Actor name

It only summarizes some of the relationships between

use cases, actors, and systems Use case name Use case
It does not show the order in which steps are performed
to achieve the goals of each use case.
Use cases represent only the functional requirements of a
<<extend>>
system Relationships
Non-functional requirements such as business rules, <<include>>

quality of service requirements, and implementation

constraints must be represented separately, with other
UML diagrams or traditional modeling tools.

© Muním Zabidi 49
Use Case Diagram Elements Actor
Someone or something that interacts with the system causing it
to respond to business events
Actor represents a role.
Primary actor:
Something or someone that stimulates the system to react
Something we don’t have control over
Secondary actor:
Something or someone that responds to system requests
Something the system uses to get its job done
Represented in UML as a stickman, even when they are not
“people ” such as a bank.

Place the primary actor in the top-left corner of the diagram

Name actors with singular, business-relevant nouns
Actors don’t interact with one another
© Muním Zabidi 50
Use Case Diagram Elements Use Cases

A use case is an activity by the system

that provides a value to an actor.
The connecting line between the actor
and the use case indicates that the actor
Buy item
is involved with that use case
The actor is always outside the boundary
Customer
box Restock items

A use case is represented by an oval with Supplier

the name of the use case inside Collect money

Names begin with a strong verb

Imply timing considerations by stacking
use cases.

© Muním Zabidi 51
Use Case Diagram Elements Boundary Box

Defines the border between the

computerized portion of the application
and the people operating the application
Also known as automation boundary

Draw your system’s boundaries using a

rectangle that contains use cases.
Place actors outside the system’s
boundaries.
The actor’s communication with the use
case crosses the automation boundary

© Muním Zabidi 52
Use Case Elements Basic Relationships

An association between an actor and a use case indicates that the actor and the use
case somehow interact or communicate with each other.
Illustrate relationships between an actor and a use case with a simple line

© Muním Zabidi 53
Use Case Elements Include and Extend Relationships

<<include>>
A use case diagram may also Pay by Validate
credit card PIN
show relationships between use
cases indicated by arrows: Customer
include, extend or generalization
include : one use case is needed
by another in order to perform a
task. Pay by
<<extend>>
Calculate
cash balance
extend : alternative options
under a certain use case Foreign
Customer

© Muním Zabidi 54
Use Case Elements Generalization Relationships

generalization : when two or more use cases that

have commonalities in behavior, structure, and
Pay
purpose.
A specialized use case is a particular way to
achieve the goals expressed by another general
use case.
Pay by Cash Pay by e-Wallet
Specialized use cases can help you show different
ways that your system can achieve the same goal.

© Muním Zabidi 55
Summary: Advanced Use Cases

Generalization Extend Include

Base use case could Base use case is complete Base use case is incomplete
be abstract use case (concrete) by itself, defined (abstract use case).
(incomplete) or concrete independently.
(complete).
Specialized use case is Extending use case is Included use case required,
required, not optional, if optional, supplementary. not optional.
base use case is abstract.

© Muním Zabidi 56
Use Case Diagram for Film Camera

In UML 2.0, a frame encapsulates components and

also provides context on the type of diagram.
Frames have headings with a descriptive notation
for the diagram type, the mapping for the diagram uc FilmCamera
types is below:
uc = use case Take picture

act = activity
class = class Actor Change film

cmp = component
dep = deployment
sd = interaction
pkg = package
stm = state machine

© Muním Zabidi 57
Use Case Diagram for Online Store

© Muním Zabidi 58
Use Case Diagram for ATM

© Muním Zabidi 59
Use Case Tips

After client interview the following system

scenarios were identified:
A customer buys a product
The supplier restocks the machine Buy item
The supplier collects money from the
machine
Customer
On the basis of these scenarios, the Restock items

following three actors can be identified:

Supplier
Customer
Collect money

Supplier

Collector
(in this case Collector=Supplier)

© Muním Zabidi 60
Writing Use Case Specifications
Jacobson et al. proposed a template for writing use cases as shown below [JSB11]:
Name Descriptive name that illustrates the purpose of the use-case.
Goal Describes the objective of the use case.
Actor List any actors that participate in the use-case.
Pre-condition Conditions that must be met before starting the use-case.
Post Condition Describe the state of the system after a use-case has run its
course.
Flow of events Description of interaction between the system and the actor.

1. Basic Flow – List the primary events that will occur when
this use case is executed.
2. Alternative Flows – Any additional events that may occur in
the use case should be listed separately. Each such
occurrence should be listed as an alternative flow. A use
case can have as many alternative flows as needed.

© Muním Zabidi 61
Flows in UC Specifications

Main flow
The most common sequence of user-system interactions to
reach the goal.
Example: customer pays bill by cash

Alternate flow
A alternative way to get to achieve the goal.
Example: customer pays bill by mail, by check, by credit card, by debit card, etc.

Exception flow
A path that does not lead to the goal.
Example: credit card is declined.

© Muním Zabidi 62
Use Case Specifications Example 1

Use Case ID UC1

Use Case Name Find a product.
Description Describes the steps to find a product.
Actor Customer.
Pre-Conditions Customer is logged in.
Post-Conditions Customer decides to buy a product or not.
Flow of events
Main flow:

1. Customer choose a category of the product.

2. System presents a list of products belonging to the category.
3. Customer chooses the product.
4. System displays detailed information about the product
Alternative flow:
1a. Customer would like to search for the product
1a1. Customer searches for the product (UC2)

© Muním Zabidi 63
Use Case Specifications Example 2

Use Case ID UC2

Use Case Name Login
Description A user logs into the System to access system functions.
Actor Parents, Students, Teacher, Admin
Pre-Conditions System must be connected to the network.
Post-Conditions After a successful login a notification mail is sent to the user mail id
Flow of events
Main flow/happy path:

1. User enters username and password

2. System validates username and password
3. System allows access to the system
Alternative flow:
1a. Invalid username: System shows an error message
2a. Invalid password: System shows an error message
3a. Invalid password for 4 times: application closed

© Muním Zabidi 64
Use Case Specifications Example 3
Use Case ID UC3
Use Case Name Create Order
Description Create order is the ability to request the purchase of a product.
Actor Order Creator
Pre-Conditions Order Creator has been identified
Main flow
1. Order Creator selects ’order product’ action
2. System requests customer/product identification information
3. Order Creator provides customer/product identification information
4. System requests mailing information
5. Order Creator provides mailing information
6. System verifies mailing information
7. System requests order be submitted
8. Order creator submits order
9. System submits product order for processing
10. System confirms product order

Post-Conditions Purchase order is created

Alternative flows:
Product is not in stock
Product has been discontinued
A customer’s initial order is over RM200

© Muním Zabidi 65
Use Case Tips

A Good Use Case

Use simple grammar Common Mistakes:
Starts with a request from an actor to the Complex diagram
system No actor
From the actor’s point of view, not the Too much details
system’s “User types ID and password, clicks OK
Focuses on interaction, not internal or hits Enter"
system activities User provides name
User provides address
Doesn’t describe the GUI in detail User provides telephone number
Has 3-9 steps in the main flow Any step should lead to some progress
Is easy to read Not “User click the enter key”
Summary fits on a page

© Muním Zabidi 66
 User Stories

© Muním Zabidi 67
Traditional vs Agile Requirements

To understand the need for User Stories, we need to understand the difference between
requirements in traditional and agile methodologies.

Agile Requirements
Traditional Requirements
Agile requirements are intentionally
Traditional requirements are complete. incomplete.
Traditional requirements are fixed (or very Agile requirements emerge and triangulate
controlled). towards a solution.
Traditional requirements are written; signed Agile requirements are mostly verbal, with a
off before execution. little writing and are signed off after story
Traditional requirements are often measured completion.
by coverage, traceability and completeness. Agile requirements are iteratively measured by
the customer.

© Muním Zabidi 68
User Stories Why

User stories emphasize verbal communication.

Written language is often very imprecise, and there’s no guarantee that a customer and
developer will interpret a statement in the same way.
User stories are written so that each can be given an estimate of how difficult or
time–consuming it will be to develop.
Therefore, user stories can be used readily in project planning.
A story is implemented all in a single iteration of an agile project.
Therefore, teams to deliver quality software more quickly, which is what customers prefer

© Muním Zabidi 69
User Stories What

A user story describes a software feature from the customer (user) perspective.
Uses informal, natural language description
Used in Agile software development
Traditionally recorded on index cards

© Muním Zabidi 70
3 C’s of User Stories [Jef01]

Card Conversation Confirmation

The topic of the backlog item. Details requirements are Acceptance tests confirm the
The high-level description of the discovered after the backlog completed backlog are what the
desired system behavior. item has been pulled into a sprint. customer wants.
https://www.justinmind.com/blog/user-story-examples/
User Stories -> Epic -> Theme

Set of
Wishlist Theme
related epics

As a customer, I want to be able

Set of related
to have wishlists Epic
user stories
so that I can come back to buy products later

As a customer, I want to be able As a customer, I want to be able Smallest unit

User
to save products in my wishlist to view my wishlist in agile
story
so that I can view it again later so that I can buy items from it planning

Put 'Add to wishlist' Create page to

Create new to db to Add 'View wishlist' Elements
button on each display user's Task
store wishlist items link to homepage of a story
product page wishlist
INVEST
Bill Wake provides us with the INVEST acronym to help create good user stories [Wak03].

Letter Meaning Explanation

I Independent Stories should be as independent as possible. Stories which can
be worked on in any order allows for true prioritization of each and
every story.
N Negotiable A story is not a contract. A story IS an invitation to a conversation
and they should not be treated like a contract.
V Valuable A story should provide value to the end-user. If a story does not
have discernable value it should not be done. Period.
E Estimable A story has to be able to be estimated (to a good approximation)
or sized so it can be properly prioritized.
S Small Story should be sized appropriately so as to fit within an iteration.
They should not be too small or too the big.
T Testable Every story needs to be testable in order to be “done.” Testable
implies that the acceptance criteria can be written immediately.

© Muním Zabidi 74
 Activity Diagrams

© Muním Zabidi 75
Activity Diagrams at a Glance

Illustrates the flow of activities during the

execution of a use case
Can also be used to examine a business process
to identify its flow of events and requirements
Explicitly built around modeling software systems,
but there are also extensions for modeling other
kinds of systems, e.g. SysML and BPNM.

https://www.visual-paradigm.com/guide/
uml-unified-modeling-language/
Activity Diagram Elements

© Muním Zabidi 77
Basic Activity Diagram

View
book proposal

Tell account
[Accept proposal] Offer advance
cut check
Offer contract
to writer/agent

[Reject proposal] Do not

offer advance
Notify writer
Send rejection to begin work
to agent

Activity diagrams versus flowcharts:

Flowcharts are generic and more primitive. The standard is ISO 5807 but not all flowcharts
follow this standard.
Activity diagrams supports concurrency or parallel behavior.

© Muním Zabidi 78
Activity Diagrams with Swimlanes

When activity diagrams contain several

groups of related activities (belong to the
same objects, use cases etc) they can be
split into partitions known as swimlanes.

https://www.open.edu/openlearn/science-maths-technology/computing-ict/models-and-modelling/
content-section-7.1
Activity Diagrams with Swimlanes
Ticket Vending Machine Example
Activity is started by Commuter actor
who needs to buy a ticket. Ticket vending
machine will request trip information
from Commuter. This information will
include number and type of tickets, e.g.
whether it is a monthly pass, one way or
round ticket, route number, destination or
zone number, etc.
Based on the provided trip info ticket
vending machine will calculate payment
due and request payment options. Those
options include payment by cash, or by
credit or debit card. If payment by card
was selected by Commuter, another actor,
Bank will participate in the activity by
authorizing the payment.
 References

© Muním Zabidi 82
References I

[CB94] Dai Clegg and Richard Barker, Case method fast-track: A RAD approach (computer
aided system engineering), Addison-Wesley, 1994.
[GC87] Robert B Grady and Deborah L Caswell, Software metrics: establishing a
company-wide program, Prentice-Hall, Inc., 1987.
[IEE20] IEEE, 2020 IEEE SA Standards Style Manual, 2020,
https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf .
[Jef01] Ron Jeffries, Essential XP: Card, Conversation, Confirmation, 2001,
https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ .
[JSB11] Ivar Jacobson, Ian Spence, and Kurt Bittner, Use Case 2.0, 2011, https:
//www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf .
[Mil03] Randy Miller, Practical UML: A hands-on introduction for developers, 2003,
https://edn.embarcadero.com/article/31863.

© Muním Zabidi 83
References II

[SJB15] John W. Satzinger, Robert B. Jackson, and Stephen D. Burd, Systems analysis and
design in a changing world, 7 ed., Course Technology, 2015.
[Wak03] Bill Wake, INVEST in Good Stories, and SMART Tasks, 2003,
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ .

© Muním Zabidi 84