Introduction to

SRS

Subject : Software Engineering

Course: Bachelor of Computer Science &

Bachelor of Computer Engineering

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• Software Requirement Specification

• Description of the software to be developed

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
• establishes the basis for an agreement between customers and contractors or suppliers on how
the software product should function.
• It’s a rigorous assessment of requirements before the more specific system design stages, and its
goal is to reduce later redesign.
• Provide a realistic basis for estimating product costs, risks, and schedules.
• If used appropriately, software requirements specifications can help prevent software project failure.
• It lists sufficient and necessary requirements for the project development.
• To derive the requirements, developer needs to have clear and thorough understanding of the
products under development.
• This is achieved through detailed and continuous communications with the project team and
customer throughout the software development process
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

Data Model

Functional
Model
Behavioral
Model

The SRS is composed of the outer layer of the behavioral model, the
functional model, then the data model.
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
important

• Section One
– Overview document for executives describing the system from a
management perspective

• Section Two
– General Description describing the system from a user and system
perspective in general terms.

• Section Three
– Detailed document for users and developers describing the system
in detailed terms.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

Table of Contents

I. Introduction

II. General Description

III. Functional Requirements

IV. Non Functional Requirements

V. System Architecture

VI. System Models

VII. Appendices

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

I. Introduction II. General Description

A Purpose A Product Perspective

B Scope B Product Functions

C Definition, Acronyms, or C User Characteristics

Abbreviations
D General Constraints
D References
E Assumptions
E Overview

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

• Correct • Complete

• Precise • Organized

• Unambiguous • Verifiable

• Consistent • Understandable

• Modifiable • Traceable

• Design Independent • Annotated

• Concise

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
Correct -
specifies every true requirement known at that time and no incorrect
specifications - no wrong data
Precise -
remember this must eventually turn to executable code, fuzzy words in
requirements are not acceptable - fuzzy words
Unambiguous
each requirement has only one interpretation - English interpretation
Complete -
everything included behavior (methods, use cases, systems, subsystems,
business rules) and data (objects, attributes

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

Verifiable: is the software built what was specified in the SRS

Consistent: conflicting terms, characteristics

Understandable
question: are formal specifications understandable, are informal
specifications understandable
Modifiable: changing requirements easily modified when specifying,
designing, coding, implementing
Traceable: can I locate the SRS origin of software components.

Design Independent: SRS should not specify a particular design

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

I. Introduction

A Purpose

B Scope

C Definition, Acronyms, or Abbreviations

D References

E Overview

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
A. Purpose

• The purpose of this Software Requirements Specification document.

• Intended audience of this document.

The purpose of the Software Requirements Specification

document is to clearly define the system under development, namely the
Video Rental System (VRS). The intended audience of this document
includes the owner of the video store, the clerks of the video store, and the
end users of the VRS. Other intended audience includes the
development team such as the requirements team, requirements analyst,
design team, and other members of the developing organization.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
B. Scope

• Origin of need
• who and what triggered the request for this software development activity
• gives developers an understanding of the goals for the proposed system
• High-level description of the system functionality
• defined for the system
• usually in list separated by commas
• Goals of proposed system

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
B. Scope

• Goals are general purposes of a system.

• They are mostly fuzzy and non measurable.
• A typical goal would be things like
✓ Increase customer satisfaction
✓ Make “xyz” easier for the customer
✓ Improve customer relationships

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
B. Scope

The owner of a local video store wanted to create a new business plan where
everything about renting a video (except the picking up and returning of videos)
was done online. Therefore, the new VRS will allow the following functionality
online: to search for videos, to become members, to rent videos, to modify
membership information, and to pay overdue fees. The store personnel may use the
VRS to process the rented or returned videos, to add or remove videos to/from his
store’s video inventory and to update video information. The VRS is intended to
increase the owner’s profit margin by increasing video sales with this unique
business approach and by allowing him to reduce the staffing needed in his stores.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
C. Definitions, Acronyms..

• As you begin to define a system, you will encounter words which need definition and
general usage acronyms. These should be documented for new personnel and for
clarity of all concerned parties.

MIU – Manipal International University

CS - Computer Science
MSES - Masters in Software Engineering Science
DOE - Department of Education
….
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
I. Introduction
D. References
• Many references may be used to define existing systems, procedures (both new and
old), documents and their requirements, or previous system endeavors. These
references are listed here for others.

• If any of these references are provided in the appendices, it should be noted here.

Clerk - Personnel staff who is working in a video store

Customer - Anyone who interacts with the VRS with becoming a
member
Functional requirement - A service provided by the software system
Member - Anyone who registers with the VRS to acquire
membership in the video store

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 References

• Shari Lawrence Pfleeger, Joanne M. Atlee “Software Engineering Theory and

Practice” 4th edition Pearson 2010
• Roger S. Pressman “Software Engineering A Practioner’s Approach 6th edition
McGraw-Hill 2005
• Ian Sommerville “Software Engineering 9” 9th edition Pearson 2010
• Pankaj Jalote “ An Integrated approach to Software Engineering” 3rd edition
Springer 2005
• Rajib Mall “Fundamentals of Software Engineering” 3rd edition PHI learning 2009

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

I. Introduction
E. Overview

• This section defines the organization of the entire document.

• It will lay the framework for reading the document.

Section 2 of the SRS describes the product in more detail. Section 3

provides a complete list of the functional requirements of the
intended system. Section 4 provides the non-functional
requirements. Section 5 shows the class diagram, and Section 6 the
use case diagram. The appendices appear next.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
Section I of SRS
I.A Purpose Paragraph form

I.B Scope of the System Specified Paragraph form

I.C Definitions, Acronyms, and Abbreviations Table form or bulleted list

I.D References to Supporting Documents Bulleted list

I.E Overview of rest of SRS Paragraph form

Software Engineering,MIU
MIU
(Ts.)SSSSSS Shameem
Copyright © 2015 Pearson Education, Inc.
(Ts.) Shameem Software Engineering,
 Software Requirements Specification

II. General Description

A Product Perspective

B Product Functions

C User Characteristics

D General Constraints

E Assumptions

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II General Description
A. Product Perspective
• Defines the relationship this product has in the entire spectrum of products.
• Defines who will be responsible for the product and what business purpose it serves.
• Also defines what interfaces it may have to other systems.

The VRS is a web-based system. The system interfaces with two other
systems, the owner’s email system, the video distributor’s video system,
and the browsers used by VRS customers. The system provides a secure
environment for all financial transactions and for the storing and
retrieving of confidential member information.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
B. Product Functions

• This section lists the major functions of the system.

• Provides a summary of all the functions of the software.
• The functions should be organized in a way that makes the list of
functions understandable to the customer or to anyone else reading
the document for the first time.
• This section should be consistent with the functional requirements defined
in Section III.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
B. Product Functions
The VRS allows customers to search the video inventory provided by this video
store. To rent videos through the VRS, one must register as a member using the VRS. Upon
becoming a member and logging into the VRS, the VRS provides the functionality for
renting videos, modifying membership information, and paying overdue fines.
The clerks of the video store use VRS to process the return of rented videos. The
owner of the video store uses VRS to add new videos into the system, remove videos from
the system, and modify video information.
The VRS sends emails to members concerning video rentals. One day before a
rented video is due to be returned, VRS emails the member a reminder of the due date for
the video(s). For any overdue videos, VRS emails the member every 3rd day with overdue
notices. At the 60-day limit for outstanding videos, VRS debits the member’s credit card
with the appropriate charge and notifies the member of this charge.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
C. User Characteristics

• List the users involved with the proposed system including the general
characteristics of eventual users (for example, educational background,
amount of product training).
• List the responsibility of each type of user involved, if needed.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
C. User Characteristics
The three main groups of VRS users are customers, members, and store
personnel. A customer is anyone who is not a member. The customer can only search
through the video inventory. The amount of product training needed for a customer is
none since the level of technical expertise and educational background is unknown. The
only skill needed by a customer is the ability to browse a website.
Member is someone who has registered with VRS. A member can rent videos
and pay fees online. As with a customer, these activities require no product training since
the level of technical expertise and educational background of a member is unknown. The
only skill needed by a member is the ability to browse a website.
The store personnel are divided into two groups: the clerk-level personnel and
owner-level personnel. Their educational level is unknown and both group needs little to
no training.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
D. General Constraints
• In this section, the constraints of the system are listed.
• They include hardware, network, system software, and software constraints.
• It also includes user constraints, processing constraints, timing constraints, and
control limits.

This system provides web access for all customer and member functions. The
user interface will be intuitive enough so that no training is required by
customers, members, or store personnel. All online financial transactions and the
storage of confidential member information will be done in a secure environment.
Persistent storage for membership, rental, and video inventory information will be
maintained.
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
II. General Description
E. Assumptions and Dependencies

• This includes assumptions made at the beginning of the development effort as well as
those made during the development.
• List and describe each of the factors that affect the requirements stated in the SRS.
• These factors are not design constraints on the software but any changes to
them can affect the requirements in the SRS.
• For example, an assumption might be that a specific operating system will be
available on the hardware designated for the software product. If the OS is
not available, the SRS would then have to change.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

Section II of SRS

• II.A Product Perspective • Paragraph form

• II.B Product Functions • Paragraph form

• II.C User Characteristics • Paragraph form

• II.D General Constraints • Paragraph form

• II.E Assumptions and Dependencies • Paragraph form

Software Engineering,MIU
MIU
(Ts.)SSSSSS Shameem
Copyright © 2015 Pearson Education, Inc.
(Ts.) Shameem Software Engineering,
 Software Requirements Specification

III. Functional Requirements

• Functional requirements are those business functions which are included in

this software under development.
• It describes the features of the product and the needed behavior.
• The functional requirements are going to be written in narrative form
identified with numbers.
• Each requirement is something that the system SHALL do.
• Brief design rationale for any requirement can be provided, which might
require some explanation for how and/or why the requirement was derived.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Functional Requirement
• Any requirement which specifies what the system should do.

• describe a particular behavior of function of the system when certain conditions are met

• example:

– “Send email when a new customer signs up” or

– “Open a new account”.

– “Display the name, total size, available space and format of a flash drive connected to
the USB port.” “add customer” and “print invoice”.

– A functional requirement for an everyday object like a cup would be: “ability to contain
tea or coffee without leaking”.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Functional Requirement
Typical functional requirements include:

– Business Rules

– Transaction corrections, adjustments and cancellations

– Administrative functions

– Authentication

– Authorization levels

– Audit Tracking, Legal or Regulatory Requirements

– Certification Requirements

– Reporting Requirements

– Historical Data
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

IV. Non Functional Requirements

• Non functional requirements are properties that the system must have
such as performance, reusability, usability, user friendliness, etc.

• The same format as the functional requirements is to be used for the

non-functional requirements.
• Brief design rationale for any requirement can be provided, which
might require explanation for how and/or why the requirement
was derived.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Non-Functional Requirement
• Any requirement which specifies how the system performs a certain function.

• Describe how a system should behave and what limits there are on its
functionality.

– Functional requirements describe what the system should do.

• Specify the system’s quality attributes or characteristics.

• example:

– “Modified data in a database should be updated for all users accessing it

within 2 seconds.”

– A non-functional requirement for the cup mentioned previously would be:

“contain hot liquid without heating up to more than 45°C”.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Non-Functional Requirement
Typical non-functional requirements include:

– Performance – for example: response time, throughput,

utilization, static volumetric • Serviceability
– Scalability • Security
– Capacity • Regulatory
– Availability • Manageability

– Reliability • Environmental

– Recoverability • Data Integrity

– Maintainability • Usability
• Interoperability
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

V. System Architecture

• This section presents a high-level overview of the anticipated system architecture

using a class diagram.
• It shows the fundamental objects/classes that must be modeled with the system
to satisfy its requirements.
• Each class on the diagram must include the attributes related to the class.
• All the relationships between classes and their multiplicity must be shown on the
class diagram.
• The classes specified in this document only are those directly derived from the
application domain.
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification

VI. System Models

• This section presents the use case diagram for the system under
development.
• The use case diagram should be a complete version containing all the use
cases needed to describe the functionality to be developed.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Software Requirements Specification
VII. Appendixes

Appendix A. Data dictionary

Appendix B. Raw use case point analysis

Appendix C. Screens and reports with navigation matrix.

Appendix D. Scenario analysis tables

Appendix E. Screens/reports list

Appendix F and following. Other items needed

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 UML Designs Tools
• Unified Modelling Language (UML) Diagrams

Some of the Free/Opensource UML design tools.

• https://www.modelio.org/
• https://www.eclipse.org/papyrus/index.php#applications
• https://umbrello.kde.org/
• http://www.umldesigner.org/overview/
• https://www.bouml.fr/index.html
• http://cruise.site.uottawa.ca/umple/

• https://www.smartdraw.com/ (license account)

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Database Design Tools
• Database Diagrams (and UML diagram)

Some of the Free/Opensource design tools.

• https://app.diagrams.net/
• https://www.lucidchart.com/pages/
• https://creately.com/tour/
• https://www.archimatetool.com/
• https://sparxsystems.com/
• https://www.toadworld.com/products/toad-data-modeler
• https://erwin.com/products/erwin-data-modeler/ (license account)

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 type 1 SRS Designs__ Flowchart
• Diagrammatic representation of sequence of logical steps of a program/module.
• Diagram that depicts a process, system or computer algorithm.
• Flowcharts use simple geometric shapes to depict processes and arrows to show relationships
and process/data flow.
• Widely used in multiple fields to document, study, plan, improve and communicate often complex
processes in clear, easy-to-understand diagrams.
• Sometimes called by more specialized names such as Process Flowchart, Process Map,
Functional Flowchart, Business Process Mapping, Business Process Modeling and
Notation (BPMN), Workflow diagram, or Process Flow Diagram (PFD).
• Related to other popular diagrams, such as Data Flow Diagrams (DFDs) and Unified
Modelling Language (UML) Activity Diagrams, etc.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram
• Flow diagram is a collective term for a diagram representing a flow or set of dynamic
relationships in a system.
• The term flow diagram is also used as synonym of the flowchart, and sometimes as counterpart
of the flowchart.
• There are numerous types of flow diagram.
• System Flow Diagram is basically a graphical and sequential representation of the major steps
involved in a systematic process.
• A SFD(System Flow Diagram) shows what kind of information will be input to and output
from the system, where the data will come from and go to, and where the data will be stored.
• It gives a clear idea about the whole process, say it an application or a normal data flow.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
IMPORTANT

SRS Designs_
Flowchart

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 HOW TO CREATE FLOWCHART? VERY IMPORTANT

SRS Designs__ Flow Diagram

ATM

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

Steps to Creating a Workflow Diagram

1. Pick the Process to Graph

2. Gather Information

3. Design the Workflow

4. Analysis and Improvements

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

E-Commerce

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

Employee On-boarding

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__
Flow Diagram

Cash Withdraw

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Technical support

SRS Designs__
Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT

SRS Designs__
Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

Content Marketing

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS
Designs__
Flow
Diagram

IMPORTANT

Online purchase

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Flow Diagram

IMPORTANT

Customer Service

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram
Process Flowchart

• Simplest (and most straightforward)

type.
• Just map the process chronologically
(what follows what).

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram
BPMN • Business Process modelling Notation
• Specific way of creating flowchart diagrams.
• BPMN uses standardized symbols and elements.
• Makes it easier for other people or companies to understand the
diagram.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Flow Diagram

Swimlane

• Functions just about the same as a

regular flowchart.
• The process is split into different
departments.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
type 2
SRS Designs__ State Transition Diagram
IMPORTANT

• State Transition diagram, State diagrams, State machines, and State-chart Diagrams.
• A state diagram shows the behavior of classes in response to external stimuli.
• Models the dynamic flow of control from state to state of a particular object within a system.
• Describes behavior of a single object in response to series of events in system.
• Used to represent condition of the system or part of system at finite instances of time.
• It’s a behavioral diagram.
• Shows what actions leads to change of the system, and how.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram
VERY IMPORTANT

• Difference between state diagram and flowchart –

o State diagram portrays various changes in state of the class and not Show conditions

the processes or commands causing the changes.

o Flowchart portrays the processes or commands that on execution
Show steps/action
change the state of class or an object of the class.

o Flowchart illustrates processes that are executed in the system that

change the state of objects.
o State diagram shows the actual changes in state, not the processes or
commands that created those changes

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram
Basic components
• Initial state – represent the initial state of a System or a class.

• State – represents the conditions or circumstances of an object of a class

at an instant of time.

• Transition – change of control from one state to another, and also showing
the event which causes the change in state.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram
Basic components
• Fork – represents the parent state splitting into
two or more newly created concurrent states.

• Join – two or more states concurrently converge

into one on the occurrence of an event or events.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram
Basic components
• Self transition – state of the object does not change upon the occurrence
of an event.

• Composite state – represents state with internal activities.

• Final state – represent the final state in a state machine diagram.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram

Main purposes of using State chart diagrams;

• To model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram

Steps to draw a state diagram –

• Identify the initial state and the final terminating states.
• Identify the possible states in which the object can exist (boundary values
corresponding to different attributes guide us in identifying different states).
• Label the events which trigger these transitions.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram

State diagram for user verification

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram

State diagram for an online order

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__
State Transition
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ State Transition Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs_
State Transition
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
type 3
SRS Designs__ Sequence Diagram

• A sequence diagram is the most commonly used interaction diagram.

Interaction diagram –
• Used to show the interactive behavior of a system.
• Visualizing the interactions in a system can be difficult; so different types of interaction
diagrams are used to capture various features and aspects of interaction in a system.
Sequence Diagrams –
• Simply depicts interaction between objects in a sequential order i.e. the order in which
these interactions take place.
• Describe how and in what order the objects in a system function.
• Also called as Event diagrams, event scenarios.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Purpose of Sequence Diagram;
• Model high-level interaction between active objects in a system
• Model the interaction between object instances within a collaboration that
realizes a use case
• Model the interaction between objects within a collaboration that realizes
an operation
• Either model generic interactions (showing all possible paths through the
interaction) or specific instances of a interaction (showing just one path
through the interaction)

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
• Sequence Diagrams show elements as they interact over time.
• They are organized according to object (horizontally) and time (vertically).

Object Dimension
• The horizontal axis shows the elements that are involved in the interaction
• Objects involved in the operation are listed from left to right according to when they
take part in the message sequence.
• Elements on the horizontal axis may appear in any order

Time Dimension
• The vertical axis represents time proceedings (or progressing) down the page.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram

Sequence Diagram Notations –

Actors – represents a type of role where it interacts with the system and its
objects.
• an actor is always outside the scope of the system.
• actors depict various roles including human users and other external
subjects.
• multiple actors in a sequence diagram are allowed.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Sequence Diagram Notations –

Lifelines – A named element which depicts an individual participant.

• Each instance in a sequence diagram is represented by a lifeline.
• Lifeline elements are located at the top in a sequence diagram.
• Standard naming for lifeline – Instance Name : Class Name
• Lifeline shown as a rectangle called head with its name and type, located on top of a
vertical dashed line (stem).
• For Unnamed instance, lifeline’s name is left blank.
• Difference between a lifeline and actor – A lifeline always portrays an object
internal to the system whereas actors are used to depict objects external to the system.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__Sequence Diagram

Sequence Diagram Notations –

Messages – Communication between objects.

• Messages appear in a sequential order on the lifeline.
• Lifelines and messages form the core of a sequence diagram.

Synchronous messages – waits for reply before interaction can move forward.
• Sender waits until receiver has completed the processing of the message.
• Caller continues only when it knows that the receiver has processed the previous
message i.e. it receives a reply message.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Sequence Diagram Notations –

Asynchronous Messages – does not wait

for a reply from the receiver.
• moves forward irrespective of receiver processing previous message or not.

Create message – instantiate a new object in the sequence diagram.

• Situations when a particular message call requires the creation of an object.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Sequence Diagram Notations –

Self Message – send a message to itself.

Reply Message – show the message being sent from the receiver to the sender.
• Interaction moves forward only when a reply message is sent by the receiver.

Delete Message – delete an object, and deallocate memory

• Destroys occurrence of the object in the system.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Sequence Diagram Notations –

Found Message – represent a scenario where unknown source

sends message.

Lost Message – when the recipient is not known to the system.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
Sequence Diagram Notations –

Guards – used for conditions.

• To restrict the flow of messages on pretext of a condition being met.
• Represents the constraints attached to system or particular process.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram

sequence diagram with different types of messages

Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram

actor interacting with a seat reservation system

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
scenario where a self message is used

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
scenario where found message is used

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
scenario where lost message is used

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
IMPORTANT EXAMPLE:

Emotion based music player:

1.Firstly the application is opened by the user.
2.The device then gets access to the web cam.
3.The webcam captures the image of the user.
4.The device uses algorithms to detect the face and predict the mood.
5.It then requests database for dictionary of possible moods.
6.The mood is retrieved from the database.
7.The mood is displayed to the user.
8.The music is requested from the database.
9.The playlist is generated and finally shown to the user.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Sequence Diagram
IMPORTANT EXAMPLE
sequence diagram for an emotion based music player

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

SRS Designs__
Sequence
Diagram

ATM

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

SRS Designs__
Sequence Medical Report
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
type 4 SRS Designs__ Use Case Diagram
• Use case diagram is a dynamic or behavior diagram (captures behavior of the system when it is
running/operating).
• Only static behavior is not sufficient to model a system rather dynamic behavior is more important
than static behavior.
• In UML, there are many diagrams available to model the dynamic nature and use case diagram is
one of them.

• It models the functionality of a

system using actors and use cases.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram

• Use case diagrams consists of actors, use cases and their relationships.

• Use cases are set of actions, services, & functions that system needs to perform.

• A "system" is something being developed or operated (ex. web site).

• “Actors" are people or entities operating under defined roles within the system,

i.e. the internal or external factors/agents for making interaction.

• A single use case diagram captures a particular functionality of a system.

o To model the entire system, a number of use case diagrams are used

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram
• Purpose of use case diagram is to capture the dynamic aspect of a system.
• Use case diagrams are valuable for visualizing the functional requirements of a system that will translate
into design choices and development priorities.
• Identify any internal or external factors that may influence the system and should be taken into
consideration.
• Provide a good high level analysis from outside the system.
• Specify how the system interacts with actors without worrying about the details of how that
functionality is implemented
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Show the interaction among the requirements are actors.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram
Actor
• Individuals involved with the system, defined according to their roles.
• Can be a human or other external system.
Use Case
• Describes how actors uses a system to accomplish a particular goal.
• Initiated by a user to fulfill goals describing the activities and variants involved in attaining the goal.
Relationship : Relationships between and among the actors and the use cases.
System Boundary: Defines the system of interest in relation to the world around it.

Packages: Logical categorization of use

cases into related subsystems.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Use Case
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Five (5) relationship types in a use case diagram;

• Association between actor and use case.
• Generalization of an actor.
• Extend between two use cases.
• Include between two use cases.
• Generalization of a use case.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram
<<include>> Use Case

<<extend>> Use Case

Abstract and generalized Use Case

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Association Between Actor and Use Case

• Straightforward; and present in every use case diagram.
• 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.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship
Generalization of an Actor
• Generalization of an actor means that one actor can inherit the role of the other actor.

• Descendant inherits all the use cases of the

ancestor.
• Descendant has one or more use cases that
are specific to that role.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Extend Relationship Between Two Use Cases

• Extends the base use case and adds more functionality to the system.

• Extending use case is dependent on the extended (base) use case.

• Extending use case is usually optional and can be triggered conditionally.

• Extended (base) use case must be meaningful on its own. It should be

independent and must not rely on the behavior of the extending use case.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

• “Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case.
• Extending use case is triggered only for deposits over 10,000 or when the age is over 55.

Extend Relationship
Between Two Use Cases

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Include Relationship Between Two Use Cases

• Include relationship show that the behavior of the included use case is part of the

including (base) use case.

• Reuse the common actions across multiple use cases.

• The base use case is incomplete without the included use case.

• The included use case is mandatory and not optional.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Include Relationship Between Two Use Cases

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram Relationship

Generalization of a Use Case

• Similar to the generalization of an actor.

• The behavior of the ancestor is inherited by the descendant.

• Used when there is common behavior between two use cases and also specialized

behavior specific to each use case.

• Example; in previous banking example, there might be a use case called “Pay Bills”;

which can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Use Case
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Actors - Guidelines for Better Use Cases

• Meaningful business relevant names for actors.

• Primary actors should be to the left side of the diagram.

• Name the Actors as per roles (not positions) – In a hotel both front office executive

and shift manager can make reservations (“Reservation Agent”).

• External systems are actors.

• Actors don’t interact with other actors.

• Place inheriting actors below the parent actor.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Use Cases - Guidelines for Better Use Cases

• Names begin with a verb (its an action).

• Name should be descriptive (should give required information).

o Example: “Print Invoice” is better than “Print”.

• Highlight the logical order.

• Place included use cases to the right of the invoking use case.

• Place inheriting use case below parent use case.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Relationship - Guidelines for Better Use Cases

• Arrow points to the base use case when using <<extend>>

• <<extend>> can have optional extension conditions

• Arrow points to the included use case when using <<include>>

• Both <<extend>> and <<include>> are shown as dashed arrows.

• Actor and use case relationship don’t show arrows.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram

• A use case is normally described at the system functionality level and specifies
the function or the service that the system provides for the user.

• A business use case is described in technology-free terminology which

treats the business process as a black box and describes the business process
that is used by its business actors.

• Business use case represents how the work to be done manually in the
currently situation, and it is not necessarily done by the system or intend to
be automated in the scope of target system.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram
IMPORTANT EXAMPLE

Business use case

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Use Case Diagram

ATM use case

diagram example

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
type 5 SRS Designs__ Class Diagram

• Class diagram is a graphical notation used to construct and visualize object oriented
systems.
• A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's:
o classes,
o their attributes,
o operations (or methods),
o and the relationships among objects

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

• A Class is a blueprint for an object.

• Objects and classes go hand in hand (one can’t exist/function without other).
• Classes are used to create objects.
o Class describes what an object will do.
• Classes describe the type of objects, while objects are usable instances of classes.
• Each Object was built from the same set of blueprints and therefore contains the same
components (properties and methods).

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram
Example

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Class diagram can help in−

• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

• A class represent a concept which encapsulates state (attributes) and

behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Class Visibility
• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram
Parameter Directionality
• Each parameter in an operation (method) may be denoted as
in, out or inout which specifies its direction with respect to the caller.
• Directionality is shown before the parameter name

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

A diagram can be interpreted from various perspectives:

• Conceptual: represents the concepts in the domain
• Specification: focus is on the interfaces of Abstract Data Type (ADTs) in software
• Implementation: describes how classes will implement their interfaces

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Relationships between classes

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Inheritance Example - Shapes:

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Inheritance (or Generalization):

SubClass1 and SubClass2 are derived from SuperClass.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Association

• Associations are relationships between classes in a UML Class Diagram.

• They are represented by a solid line between classes.

• Associations are typically named using a verb or verb phrase which

reflects the real world problem domain

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Dependency
• A special type of association.
• An object of one class might use an object of another class in the code of a method.
o If the object is not stored in any field, then this is modeled as a dependency
relationship.
• Exists between two classes if changes to the definition of one may cause changes to
the other (but not the other way around).
• Class1 depends on Class2

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram
Aggregation

• A special type of association.

• It represents a "part of" relationship.
• Class2 is part of Class1.
• Many instances (denoted by the *) of Class2 can be associated with Class1.
• Objects of Class1 and Class2 have separate lifetimes.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram

Composition

• A special type of aggregation where parts are destroyed when the whole is destroyed.
• Objects of Class2 live and die with Class1.
• Class2 cannot stand by itself.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram __ Order System
IMPORTANT EXAMPLE

• A

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Class Diagram __ GUI

• A

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
Class Diagram _
hotel
management
system

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Class Diagram __ ATM system
IMPORTANT EXAMPLE

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 Class Diagram __ Banking System
IMPORTANT EXAMPLE

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
 type 6 SRS Designs__ Activity Diagram
• The Unified Modelling Language includes several subsets of diagrams,
o Structure diagrams, interaction diagrams, and behaviour diagrams.
• Activity diagrams, along with Use-Case and State Transition diagrams, are
considered behaviour diagrams.
• They describe what must happen in the system being modelled.
• Stakeholders have many issues to manage, so it's important to communicate
with clarity and brevity.
• Activity diagrams help people on the business and development sides of an
organization come together to understand the same process and behaviour.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram
Benefits:
• Demonstrate the logic of an algorithm.
• Describe the steps performed in a UML use case.
• Illustrate a business process or workflow between users and the system.
• Simplify and improve any process by clarifying complicated use cases.
• Model software architecture elements, like method, function, and operation.
• Identify candidate use cases, through the examination of business workflows
• Identify pre- and post-conditions (the context) for use cases
• Model workflows between/within use cases
• Model complex workflows in operations on objects
• Model in detail complex activities in a high level activity Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Components:
• Action: A step in the activity wherein users or software perform a given task.
• Decision node: A conditional branch in the. It includes a single input and two or more
outputs.
• Control flows: Another name for the connectors that show the flow between steps.
• Start node: Symbolizes the beginning of the activity.
• End node: Represents the final step in the activity.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Activity diagram symbols:

• Start: Represents beginning of a process or workflow.

• Activity: Indicates activities that make up a modelled process.

• Connector: Shows directional flow, or control flow, of the activity with incoming and

outgoing arrows.

• Joint / Synchronization bar: Combines two concurrent activities and re-introduces

them to a flow where only one activity occurs at a time.

• Fork: Splits a single activity flow into two concurrent activities.

Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Activity diagram symbols:

• Decision: Represents a decision.

• Note: Allows diagram creators/collaborators to communicate additional messages
that don't fit within diagram itself (more clarity/specification)
• Send signal: Indicates a signal is being sent to a receiving activity
• Receive signal: Demonstrates acceptance of an event.
• Shallow history pseudostate: Represents a transition that invokes the last
active state.
• Option loop: Allows the creator to model a repetitive sequence within the
option loop symbol.
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Activity diagram symbols:

• Flow final: Represents end of a specific process flow; NOT the end of all flows in an activity.

• Condition text: Placed next to a decision marker to let you know under what condition an
activity flow should split off in that direction.

• End: Marks end state of an activity, and represents the completion of all flows of a process.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__
Activity Diagram

Example__Sample

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__
Activity Diagram

Example__
login page

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__
Activity Diagram

Example__
Banking System

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

SRS Designs__ Activity Diagram

Example__Word process to create a document:
• Open the word processing package.
• Create a file.
• Save the file under a unique name within its directory.
• Type the document.
• If graphics are necessary, open the graphics package, create the graphics, and paste the graphics into
the document.
• If a spreadsheet is necessary, open the spreadsheet package, create the spreadsheet, and paste the
spreadsheet into the document.
• Save the file.
• Print a hard copy of the document.
• Exit the word processing package.
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

SRS Designs__
Activity Diagram

Example__
Word processor

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 IMPORTANT EXAMPLE

SRS Designs__ Activity Diagram

Example__Processing an order:

• Once the order is received, the activities split into two parallel sets of
activities. One side fills and sends the order while the other handles the billing.
• On the Fill Order side, the method of delivery is decided conditionally.
Depending on the condition either the Overnight Delivery activity or the
Regular Delivery activity is performed.
• Finally the parallel activities combine to close the order

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
IMPORTANT EXAMPLE

SRS Designs__Activity Diagram

Example__Process Order

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram
IMPORTANT EXAMPLE

Example__Student enrollment:

• An applicant wants to enroll in the university.

• The applicant hands a filled out copy of Enrollment Form.
• The registrar inspects the forms.
• The registrar determines that the forms have been filled out properly.
• The registrar informs student to attend in university overview presentation.
• The registrar helps the student to enroll in seminars
• The registrar asks the student to pay for the initial tuition.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__Activity Diagram
IMPORTANT EXAMPLE

Example__Student Enrollment

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram_Swimlane
• Group activities performed by same actor or activities in a single thread.

Example: Staff Expenses Submission

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Activity Diagram

Example:
meeting a new client using

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
type 7 SRS Designs__ ER Diagram

• An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how

“entities” such as people, objects or concepts relate to each other within a system.
• ER Diagrams are most often used to design or debug relational databases in the
fields of software engineering, business information systems, education and
research.
• Also known as ERDs or ER Models.
• Uses a defined set of symbols such as rectangles, diamonds, ovals and connecting
lines to depict the interconnectedness of entities, relationships and their attributes.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Weak Entity
• A weak entity is an entity that depends on the existence of another entity.
• i.e. an entity that cannot be identified by its own attributes.
• It uses a foreign key combined with its attributed to form the primary key.
o The order item will be meaningless without an order so it depends on
the existence of the order.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

ER Diagram Symbols and Notations

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram
Relationship
• Relationships are represented by diamond-shaped box.
• Name of the relationship is written inside the diamond-box.
• All the entities (rectangles) participating in a relationship, are connected to it by a line.

Binary Relationship and Cardinality

• A relationship where two entities are participating is called a binary relationship.
• Cardinality is the number of instance of an entity from a relation that can be associated
with the relation.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ ER Diagram

Best Practices for Developing Effective ER Diagrams

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.
• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
type 8
SRS Designs__ Data Flow Diagram

• A Data Flow Diagram (DFD) is traditional visual representation of the

information flows within a system.
• DFD can be manual, automated, or combination of both.
• Shows how information enters and leaves the system, what changes the
information and where information is stored.
• DFD shows the scope and boundaries of a system as a whole.
• Used as a communications tool between a systems analyst and any person
who plays a part in the system that acts as the starting point for
redesigning a system.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

• Begins with a context diagram as the level 0 of DFD diagram, a simple representation of the
whole system.
• To elaborate further from that, a level 1 diagram with lower level functions decomposed
from the major functions of the system is drawn.
• This could continue to evolve to become a level 2 diagram when further analysis is required.
• Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very
common.
• Decomposing particular function for further levels really depending on the complexity that
function.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram
External Entity
• An external entity can represent a human, system or subsystem.
• Where certain data comes from or goes to.
• External to the system, in terms of the business process; hence preferably drawn on the
edge of a diagram

Process
• A business activity or function.
• Where the manipulation and transformation of data takes place.
• A process can be decomposed to finer level of details, for representing how data is being
processed within the process.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Data Store
• Represents the storage of persistent data required and/or produced by the process.
• Examples of data stores: membership forms, database table, etc.

Data Flow
• Represents the flow of information.
• Direction of flow represented by an arrow head that shows at the end(s) of flow
connector.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

• Depending on the methodology DFD symbols vary slightly.

o Gane and Sarson

o Yourdon and Coad

• However, the basic ideas remain the same.

• There are four basic elements of a data flow diagram: processes, data

stores, external entities, and data flows.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

• Level 0 DFDs, also known as context flow diagram (CFD).

• Most basic data flow diagrams.
• Provides a broad view that is easily digestible but offers little detail.
• Level 0 data flow diagrams show a single process node and its connections
to external entities.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

• Level 1 DFDs are still a general overview, but they go into more detail than a

context diagram.

• In a level 1 data flow diagram, the single process node from the context

diagram is broken down into subprocesses.

• As these processes are added, the diagram will need additional data flows and

data stores to link them together.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

• Level 2+ DFDs simply break processes down into more detailed

subprocesses.

• In theory, DFDs could go beyond level 3, but they rarely do.

• Level 3 data flow diagrams are detailed enough that it doesn’t usually make

sense to break them down further.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Data Flow
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ DFD__Steps

The process can be broken down into 5 steps:

1. Identify major inputs and outputs in your system

2. Build a context diagram

3. Expand the context diagram into a level 1 DFD

4. Expand to a level 2+ DFD

5. Confirm the accuracy of your final diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ DFD__Guidelines

Stating the type of data with D, M and T.

• Letter 'D' (default) is used to represent persistent computerized data, which is
probably most common kind of data type in typical information system.
• Besides, data can also be held for a short time in temporary (transient data;
represented by letter 'T‘)
• Sometimes, data is stored without the use of a computer (called manual data;
and is represented by letter 'M‘).
• Finally, data can be is stored without using computer and also is held for a short
time; called manual transient data, and is represented by T(M).

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ DFD__Guidelines
• Be aware of the level of details
• Don't overdraw; Don't let it get too complex
• Don't mix up data flow and process flow
• Process labels should be verb phrases; data stores are represented by nouns
• A data store must be associated to at least a process
• An external entity must be associated to at least a process
• DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's useful in
identifying the processes when discussing with users
• Data stores should not be connected to an external entity, otherwise, it would mean that you're
giving an external entity direct access to your data files
• Data flows should not exist between 2 external entities without going through a process
• A process that has inputs but no outputs is considered to be a black-hole process
Copyright © 2015 Pearson Education, Inc.
(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Data Flow
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Customer Service System

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
SRS Designs__
Data Flow
Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram
IMPORTANT EXAMPLE

Food Ordering System

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram
IMPORTANT EXAMPLE

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Securities Trading Platform

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram

Level 2 DFD

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram
IMPORTANT EXAMPLE

Supermarket App Example

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS Designs__ Data Flow Diagram
IMPORTANT EXAMPLE

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU
 SRS

• DFD Data flow diagram

• ER Entity Relation d.

• Use Case d.
• State Transition d.
• Sequence d.
• Activity d.
• Workflow d.
• Class d.

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem
 Software Requirements Specification

Table of Contents

I. Introduction

II. General Description

III. Functional Requirements

IV. Non Functional Requirements

V. System Architecture

VI. System Models

VII. Appendices

Copyright © 2015 Pearson Education, Inc.

(Ts.) SSS Shameem Software Engineering, MIU