Software Engineering (21CS05203)

Unit-4
Software Requirement
Engineering

Prof. Rajkumar Gondaliya

Computer Engineering Department
Darshan University, Rajkot
[email protected]
+91-9723232741
 Outline
Looping
 Requirement Engineering
 Software Requirements Specification
 Eliciting Requirements
 Developing Use case
 Requirement Modeling
Requirements analysis is hard
“The hardest single part What is Requirement Engineering?
“The seeds of major
of building a software
software disasters are Tasks and techniques that lead
system is deciding what
usually sown in the to an understanding of
to build. No part of the
first three months of requirements is called
work so cripples the
commencing the requirement engineering.
resulting system if done
software project.”
wrong.”

"Fred" Brooks Jr. is an American Capers Jones is an American

computer architect, software engineer, specialist in software
and computer scientist, best known for engineering methodologies
managing the development of IBM's
System/360 family of computers
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 3
 Requirement Engineering
It provides the appropriate mechanism for Requirements fall into two types
understanding Functional requirements Non-Functional requirements

What customer wants

Non-
Analyzing needs Assessing feasibility Functional
Functional
requirements
requirements
Negotiating a reasonable solution

Specifying solution unambiguously

Validating the specification

Managing requirements

Don't put what you want to do - before how you need to do it

#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 4
Functional requirements Non-functional requirements
Any requirement which specifies what the system Any requirement which specifies how the
Should do. system performs a certain function.
A functional requirement will describe a particular
A non-functional requirement will
behaviour of function of the system when certain
describe how a system should behave
conditions are met, for example: “Send email
and what limits there are on its
when a new customer signs up” or “Open a new
account”.
functionality.

Typical functional requirements Typical non-functional requirements

Business Rules Administrative functions Historical Data Response time Availability Regulatory
Throughput Reliability Manageability
Transaction corrections, Legal or Regulatory
adjustments and cancellations Requirements Utilization Recoverability Environmental
External Interfaces Reporting Requirements Authentication Static volumetric Maintainability Data Integrity

Authorization levels Scalability Serviceability Usability

Audit Tracking Capacity Security Interoperability

#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 5
Library Management System
Function Requirements Non-function Requirements
 Add Article: New entries must be entered in database  Safety Requirements: The database may get
 Update Article: Any changes in articles should be updated crashed at any certain time due to virus or
operating system failure. So, it is required to take
in case of update
the database backup.
 Delete Article: Wrong entry must be removed from system
 Security Requirements: We are going to develop
 Inquiry Members: Inquiry all current enrolled members to a secured database for the university. There are
view their details different categories of users namely teaching
 Inquiry Issuance: Inquiry all database articles staff, administrator, library staff ,students etc.,
Depending upon the category of user the access
 Check out Article: To issue any article must be checked rights are decided.
out
 Software Constraints: The development of the
 Check In article: After receiving any article system will system will be constrained by the availability of
reenter article by Checking required software such as database and
 Inquiry waiting for approvals: Librarian will generates all development tools. The availability of these tools
newly application which is in waiting list will be governed by
 Reserve Article: This use case is used to reserve any book
with the name of librarian, it can be pledged
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 6
Requirements Engineering Tasks
1 Inception 2 Elicitation (Requirement Gathering) 3 Elaboration

Roughly define scope Define requirements Further define requirements

A basic understanding The practice of collecting the Expand and refine
of a problem, people requirements of a system from requirements obtained from
who want a solution, users, customers and other inception & elicitation
the nature of solution stakeholders
Creation of User scenarios,
desired
extract analysis class and
business domain entities
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 7
Requirements Engineering Tasks Cont.
4 Negotiation 5 Specification

Reconcile conflicts Create analysis model

Agree on a deliverable It may be written document, set of graphical models, formal
system that is realistic for mathematical model, collection of user scenarios, prototype or
developers and customers collection of these
SRS (Software Requirement Specification) is a document that
is created when a detailed description of all aspects of software
to build must be specified before starting of project
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 8
Requirements Engineering Tasks Cont.
6 Validation 7 Requirements Management

Ensure quality of requirements It is a set of activities to identify, control &

trace requirements & changes to
Review the requirements specification for requirements (Umbrella Activities) at any
errors, ambiguities, omissions (absence) and time as the project proceeds.
conflicts

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 9
Elicitation is the Hardest Part! Project Inception
 Problems of scope During the initial project meetings, the following
 System boundaries are ill-defined tasks should be accomplished
 Customers will provide irrelevant information
 Problems of understanding  Identify the project stakeholders
 These are the folks we should be talking to
 Customers never know exactly what they
want  Recognize multiple viewpoints
 Customers don’t understand capabilities and  Stakeholders may have different (and conflicting)
limitations requirements
 Customers have trouble fully communicating
 Work toward collaboration
needs
 It’s all about reconciling conflict
 Problems of volatility
 Requirements always change
 Ask the first questions
 Who? What are the benefits? Another source?
 What is the problem? What defines success?
Other constraints?
 Am I doing my job right?

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 10
Collaborative Elicitation Elicitation work products
Collaborative elicitation should result in several work products

A bounded statement of scope A list of stakeholders

A description of the technical environment
A list of requirements and constraints
Any prototypes developed
A set of use cases
• Characterize how users will
One-on-one Q&A sessions interact with the system
rarely succeed in practice; • Use cases tie functional
collaborative strategies are requirements together
more practical

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 11
Quality Function Deployment (QFD)
 This is a technique that translates the needs of the customer into technical requirements for
software
 It emphasizes an understanding of what is valuable to the customer and then deploys these
values throughout the engineering process through functions, information, and tasks
 It identifies three types of requirements

Normal requirements: These requirements are the objectives and goals stated for a product or system
during meetings with the customer

Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them

Exciting requirements: These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 12
The requirement analysis model

Describe what the customer wants built

Purpose

System Information
Establish the foundation for the software design
System Function
Provide a set of validation requirements
System Behaviors

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 13
Analysis rule of Thumb Elements of the Requirements Model
 Make sure all points of view are Scenario-based Class Models
covered Models e.g.
 Every element should add value e.g. Class diagrams
Use cases Collaboration
 Keep it simple User Stories diagrams
 Maintain a high level of abstraction
Software
 Focus on the problem domain Requirements
 Minimize system coupling
 Model should provides value to all Behavioral Flow Models
stakeholders Models e.g.
e.g. DFDs
State diagrams Data models
Sequence diagrams

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 14
Elements of the Requirements Model Cont.
Scenario-based elements Behavioral elements
Describe the system from the user's point of view Use state diagrams to represent the state of the
using scenarios that are depicted (stated) in use system, the events that cause the system to change
cases and activity diagrams state, and the actions that are taken as a result of a
particular event. This can also be applied to each
Class-based elements class in the system.
Identify the domain classes for the objects Flow-oriented elements
manipulated by the actors, the attributes of these
classes, and how they interact with one another; Use data flow diagrams to show the input data that
which utilize class diagrams to do this. comes into a system, what functions are applied to
that data to do transformations, and what resulting
Use Case Diagram Activity Diagram Class Diagram output data are produced.

Diagram
State
Data Flow
Diagram
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 15
Analysis Modeling Approaches
Structured Analysis Object Oriented Analysis
• Models data elements • Models analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations

Techniques from both approaches are typically used in practice.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 16
Activity Diagram
An activity diagram visually presents a series of operation or flow of control in a system similar
to algorithm or a flowchart.

 An activity diagram is like a traditional flowchart in that it show the flow of control from step to
step.
 An activity diagram can show both sequential and concurrent flow of control.
 Activity diagram mainly focus on the sequence of operation rather than on objects.
 Activity diagram represent the dynamic behavior of the system or part of the system.
 An activity diagram shows ‘How’ system works.
 Activity diagram are most useful during early stages of designing algorithms and workflows.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 17
Elements of Activity Diagram
Activity Activity

 The main element of an activity diagram is the activity itself.

 An activity is a function/operation performed by the system.
 The elongated ovals show activities.
 An unlabeled arrow from one activity to another activity, that indicates that the first activity
must complete before the second activity begin.
[true] [false]
Branches
 If there is more than one successor to an activity, each arrow may be labeled with a condition
in square brackets. For e.g. [failure]
 As a notational convenience, a diamond shows a branch into multiple successors.
 The diamond has one incoming arrows and two or more outgoing arrows. Each with
condition.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 18
Elements of Activity Diagram Cont.
Initiation
 A solid circle with an outgoing arrow shows the starting point of an activity diagram.
 When an activity diagram is activated, control starts at the solid circle and proceeds via the
outgoing arrow toward the first activities.

Termination
 A bull’s eye – a solid circle surrounded by a hollow circle shows the termination point.
 The symbol only has incoming arrows.
 When control reaches a bull’s eye, the overall activity is complete and execution of the activity
diagram ends.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 19
Elements of Activity Diagram Cont.
Concurrent Activities
 System can perform more than one activity at a time.
 For e.g. one activity may be followed by another activity, then split into several concurrent
activities (a fork of control), and finally be combined into a single activity (a merge of control).
 A fork or merge is shown by a synchronization bar –a heavy line with one or more input arrows
and one or more output arrows.

Merge Fork

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 20
Example of Fork & Join
 An example of business flow activity of Process Order
order processing, based on the Example Receive Order
order is input parameter of the activity.
 After order is accepted and all required
information is filled in, payment is Fill Order Send Invoice
accepted and order is shipped. [priority order] [else]

 Note, that this business flow allows order

shipment before invoice is sent or Special Delivery Regular delivery
payment is confirmed.
Receive Payment

Close Order

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 21
Guideline for Activity Diagram
 Activity diagram elaborate the details of computation, thus documenting the steps needed to
implement an operation or a business process.
 Activity diagram can help developers to understand complex computations by graphically
displaying the progression through intermediate execution steps.
 Here is some advice for activity diagram.

Don’t misuse activity diagram

 Activity diagrams are intended to elaborate use case and sequence models so that a developer
can study algorithms and workflow.
 Activity diagrams supplement the object-oriented focus of UML models and should not be used
as an excuse to develop software via flowchart.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 22
Guideline for Activity Diagram
Level diagrams
 Activities on a diagram should be at a consistent level of details.
 Place additional details for an activity in a separate diagram.

Be careful with branches and conditions

 If there are conditions, at last one must be satisfied when an activity completes, consider using
an [else] condition.
 It is possible for multiple conditions to be satisfied otherwise this is an error condition.

Be careful with concurrent activities

 Means that the activities can complete in any order and still yield an acceptable result.
 Before a merge can happen, all inputs must first complete

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 23
How to Draw an Activity Diagram
 Step 1: Identify the various activities and actions your business process or system
 Step 2: Find a flow among the activities
 For e.g. in library management system, book issue is a one business process or a function.
Show we prepare a activity diagram for Book issue.
 Various activity in book issue process like…
 Check availability of book
 Validate the member
 Check No. of books issued by member
 Add book issue details to transaction
 Update no of book issued by member
 Update book status.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 24
Activity Diagram for Book Issue

Check availability book

[book not available] Alert “Book not
[book available] available”
Validate Member

Alert “not a valid [unauthorized user]

member” [authorized user]
No. of books issued to member
[max limit] Alert “No more book
can be issued”
[else]
Add book issue details to transaction

Update no of book issued to member Update book status

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 25
Swimlane Diagram
 In a business model, it is often useful to know which human department is responsible for an
activity.
 When design of the system is complete, the activity will be assigned to a person/department,
but at a high level it is sufficient to partition the activities among departments.
 You can show such a partitioning with an activity diagram by dividing in to columns and lines.
 Each column is called swim-lane by analogy to a swimming pool.
 Placing an activity within a particular swim-lane indicates that is performed by a person/
department.
 Lines across swim-lane boundaries indicate interaction among different person/department.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 26
How to Draw a Swimlane Diagram
 Step 1: Identify the various activities and actions your business process or system
 Step 2: Figure out which person/departments are responsible for the competition of activity.
 Step 3: Figure out in which order the actions are processed. 
 Step 4: Figured out who is responsible for each action and assign them a swimlane and group
each action they are responsible for under them

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 27
Swimlane Diagram for Book Issue
Librarian Library Management Software

Check availability book

[book not available] Alert “Book
[book available] not available”

Validate Member
[unauthorized user] Alert “not a
[authorized user] valid member”

No. of books issued to member

[max limit] Alert “No more book
[else] can be issued”

Add book issue details to transaction

Update no of book issued to Update book

member status

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 28
Class diagram
The purpose of class modeling is to describe objects in systems and different types of
relationships between them.

The class diagram is used to construct and visualize object-oriented systems.

 Class modeling is used to specify the structure of the objects, classes, or components that
exist in the problem domain or system.
 Class diagram provides a graphic notation for modeling classes and their relationships.
 Class is a blueprint of an object.
 An object is a concept, abstraction, or thing with an identity that has meaning for an
application.
 Class diagrams represent an overview of the system like classes, attributes, operations, and
relationships.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 29
Elements of Class Diagram (Class Name)
 The name of the class appears in the upper section.
 Class name should be meaningful.
 Class name should always be aligned center of the upper section.
Class Name  Class name should start with capital letters, and intermediate letter is
a capital.
Attributes
 Class name should be always bold format.
Operations  For e.g.:
Account Customer Employee

 Abstract class name should be written in italic format.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 30
Elements of Class Diagram (Class Name) Cont.
 For e.g. in the banking system, there are two types of accounts; one is a saving account and
another is a current account.
 Account is an abstract class and saving account and the current account is a subclass of
Account.
 The system can’t directly access the Account class. It is accessible by only saving accounts
and current accounts. Abstract class
Account italic font

Normal class
SavingAccount CurrentAccount non italic font

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 31
Elements of Class Diagram (Attributes)
 An attribute is a named property of a class that describes a value
held by each object of the class.
Class Name  The UML notation lists attributes in the second compartment of the
class box.
Attributes  The attribute name should be in the regular face, left align in the box
& use the lowercase letters for the first character.
Operations
 The data type for the attribute should be written after the colon.
 Accessibility of attribute must be defined using a member access
modifier.
 Syntax : accessModifier attributeName:dataType=defaultValue
 For e.g. in this example ‘–’ represents private access modifier
Account Customer Employee
- accountNumber:long - customerName:String - employeeName:String

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 32
Elements of Class Diagram (Access Modifiers)
 Public (+): Member accessible by all classes, whether these classes are in the same package or
in another package.
 Private (-): Member cannot be accessed outside the enclosing/declaring class.
 Protected (#): Member can be accessed only by subclasses and within a class.
 Package (~): Member can be accessible by all classes, within the package. Outside package
member not accessible.
 Static (underlined) : Member can be accessed using class name only. SavingAccount
 In example you can see how to use access specifier + accountNumber:long
+ name:String
# dob: Date
~ panNumber:String

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 33
Elements of Class Diagram (Operation)
 The operation is a function or procedure that may be applied to objects
Class Name in a class.
 The UML notation is to list operations in the third compartment of the
Attributes
class box.
Operations  The operation name in the regular face, left align the name in the box,
and use a lowercase letter for the first character.
 Optional detail, such as an argument list and result type, may follow
each operation name.
 The return type of method should be written after colon.
 Accessibility of operation must be defined using a member access
modifier.
 Syntax : accessModifier methodName(argumentList):returnType
For e.g.: you can see change phone number is a Account
method that accepts phone number as an argument
and return the int value as a response. + changePhoneNumber(phoneNumber:String):int
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 34
Generalization & Specialization
 Generalization is the process of Vehical
extracting shared characteristics from + no of wheels:int
two or more classes and combining them +start() : void
into a generalized superclass +stop() : void
 Shared characteristics can be attributes +applyBreak() : void

Specialization
+refilllFule() : int

Generalization
or methods.
 Represents an "is-a" relationship
 For example, a car is a vehicle and a truck
is a vehicle. In this case, vehicle is the
general thing, whereas car and truck are Car Truck
the more specific things.
 Specialization is the reverse process of +parkAtHome() : void + loadGoods() : void
Generalization means creating new sub- + unloadGoods() : void
classes from an existing class.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 35
Generalization & Specialization
 For example in a bank, any
Customer opens an account. Account
 The account can be either a + accountNo:long
+ balance:double
savings account or a current +debitAmount(amount:double): void
account. In saving account, +creditAmount(amount:double) : int
+getBalance(accountNo:long) : double
customer earns fixed interest on
the deposit. But this facility is
not available in the current
account. SavingAccount CurrentAccount
+ interestRate:double
+ isTransactionLimitOut(accountNo:long) : int

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 36
Link and Association Concepts
 Link and associations are the means for establishing relationships among objects and classes.
 A link is a physical or conceptual connection among objects.
 An association is a description of a group of links with common structure and common semantic
& it is optional.
 Aggregation and Composition are the two forms of association. It is a subset of association.
 Means they are specific cases of association. In both aggregation and composition object of
one class "owns" object of another class, but there is a minor difference.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 37
Aggregation
Aggregation is a subset of association. it is a collection of different things.
It is more specific than an association.
It represents ‘has a’ relationship.
Aggregation implies a relationship where the child is independent of its parent.
 For e.g.: Here we are considering a car and a
wheel example. A car cannot move without a
wheel.
Car Wheel
 But the wheel can be independently used with
the bike, scooter, cycle, or any other vehicle.
 The wheel object can exist without the car
object, which proves to be an aggregation
relationship.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 38
Composition

The composition is a part of the aggregation. It represents the dependency between a parent
and its children, which means if the parent is discarded then its children will also discard.

It represents ‘part-of’ relationship.

In composition, both the entities are dependent on each other.

 For e.g.: Person class with Brain class, Heart Person

class, and Legs class.
 If the person is destroyed, the brain, heart, and
legs will also get discarded.

Brain Heart Legs

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 39
Multiplicity
 Multiplicity is the specification of the number of instances of one class that may be related to
the instance of another class.
 Multiplicity constrains the number of a related object.
 You can use multiple associations between objects.
 Some typical type of multiplicity:
Multiplicity Option Cardinality
0..1 No instances or one instance
1..1 1 Exactly one instance
0..* * Zero or more instances

1..* At least one instance

5..5 5 Exactly 5 instances

m..n At least m but no more than n instances

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 40
Example Of Multiplicity
One to One Association
has
Account Holder 1 1
Cheque Book One account holder has one cheque book

Many to Zero or One Association

belong
Students Class Students belong to at most one class.
* 0..1

Many to Many Association

withdraw
Account Holder * *
ATM Every account holder can withdraw money from all ATMs.

One to One or Many Association

have
Bank 1 1..*
Branch The bank should have at least one branch.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 41
Class Diagram Of Bank Management System
*
Bank
- name : string *
- code: string ha
ve
ve
+manageBranch();
ha

* 1..*
ATM Branch Account
- location : string manage - branchName : string 1 have 1..* ~ accountNumber: string
- manageBy: string * * - branchCode: string - balance: number
+transaction(); + manageAccount():void +debitAmount(amount:double): void
+ transaction():init 1..2 +creditAmount(amount:double) : int
*
* +getBalance(accountNo:long) : double

e
ag
tra

an
ve
ns

ha
m
ac
tio

*
n

Customer
- name: string 1 CurrentAccount SavingAccount
- address: string
*
- dob: date - interestRate:double
- panNumber: string + isTransactionLimitOut(accountNo:long) : int
+ manageAccount():void
+ transaction():init

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 42
Class Diagram Of Library Management System
Librarian 1 manage Member
- name:string workFor *
~ mName: string
- contactNo: number 1
membership - mContact: number
+ addLibrarian():void 1 * - mType: string
* - mNoOfBookIssued: int
+ updateInfo():int Library
+ removeLibrarian(id:int):int - id:int
+ login(uname:string,pass:string):int + addMember():void
- name:string + udateMember():int
1
request + issueBook(bookID:int):void
1 1 + returnBook(bookID:int):void
Book
manage

have 1…* + registration():void

- authorName:string + authentication(mID:int):int
- publisherName:String Material 0…3
- materialID:int
*
QestionPaper + addMaterial():void
- subject:string + updateMaterial():int
+ removeMaterial(bookID:int):int Student
- examName:String Staff
+ issueMaterial(bookID:int):void
- name:string - enrNo:int
+ returnMaterial(bookID:int):void
- name:string
CD/DVD + payFine():int
- type:string
- topic:String

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 43
Sequence Diagram
A Sequence diagram shows the participants (Objects) in an interaction and the sequence of
message among them.

 A sequence diagram shows the interaction of a system with its actors to perform all or part of a
use case.
 Sequence diagram represent the dynamic communication between object during execution of
task.
 Each use case requires one or more sequence diagram to describe its behavior.
 Each sequence diagram shows a particular behavior sequence of the use case.
 It is best to show a specific portion of a use case and not attempt to be too general.
 You can draw a separate sequence diagram for each task.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 44
Components of Sequence Diagram
Object - Class Roles or Participants Object : Class

 Class roles describe the way an object will behave in context.

 Use the UML object symbol to illustrate class roles, but don't list object attributes.

Activation or Execution Occurrence

 Activation boxes represent the time an object needs to complete a task.
 When an object is busy executing a process or waiting for a reply message, use
a thin gray rectangle placed vertically on its lifeline.
Lifeline
 A lifeline represents a Object in an interaction.
 When that object's lifeline ends, you can place an X at the end of its lifeline to
X
denote a destruction occurrence.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 45
Components of Sequence Diagram Cont.
Messages
 Messages are arrows that represent communication between objects.
 Use the following arrows and message symbols to show how information is transmitted
between objects.
Synchronous message
 Represented by a solid line with a solid arrowhead.
 This symbol is used when a sender must wait for a response to a message before it continues.
 The diagram should show both the call and the reply.
Asynchronous message
 Represented by a solid line with a lined arrowhead.
 Asynchronous messages don't require a response before the sender continues.
 Only the call should be included in the diagram.
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 46
Components of Sequence Diagram Cont.
Reply message
 Represented by a dashed line with a lined arrowhead.
 these messages are replies to calls.

Delete message X

 Represented by a solid line with a solid arrowhead, followed by an X.

 This message destroys an object.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 47
Guideline for Sequence Diagram
Prepare at least one scenario per use case Abstract the scenarios into sequence diagrams.
 The steps in the scenario should be  The sequence diagrams clearly show the
logical commands, not individual button contribution of each actor.
clicks.
 It is important to separate the contribution of
 You can specify the exact syntax of input. each actor as a prelude to organizing
 Start with the simplest mainline behavior about objects.
interaction - no repetitions, one main
activity, and typical values for all Divide complex interactions
parameters.  Break large interactions into their constituent
 If there are substantially different tasks and prepare a sequence diagram for
mainline interactions, write a scenario for each of them.
each.
Prepare a sequence diagram for each error condition.
 Show the system response to the error condition.
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 48
Steps to Draw a Sequence Diagram
Step-1 Select one scenario
Step-2 Identify the necessary set of the objects. Who is taking part ?
Step-3 Identify the necessary interactions/steps.
Step-4 Describe the message exchange between object.
Step-5 Identify the sequence of interactions and who starts Interactions.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 49
Example: Sequence Diagram for Book Issue
 Book issue is a one business process or a function in Library Management System.
 Necessary objects for book issue process are Librarian, Book, Member and Transaction .
 Member class object starts the interaction.
 Various interactions in book issue process are

1 Request for a book

2 Check availability of book
3 Validate the member
4 Check No. of books issued by member
5 Add book issue details to transaction
6 Update no of book issued by member
7 Update book status
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 50
Sequence Diagram for Book Issue

L:Librarian B:Book MR: Member

1. Request for a book
2. Check availability of book

3. Book available rack no.

4. Validate Member
5. Response for validation
6. Check no of book issued

7. Book can be issued

8. Update book status

9. Update member status

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 51
State diagram
A state diagram is a graph whose nodes are states and whose directed arcs are transitions
between states.

A state diagram specifies the state sequences caused by event sequences.

 The state diagram is a standard computer science concept that relates events and state.
 Events represent external stimuli.
 States represent value of objects.
 All objects in a class execute the state diagram for that class, which models their common
behavior.
 The UML notation for a state diagram is a rectangle with object name in a small pentagonal tag
in the upper left corner.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 52
Components of state diagram
Initial State
 A solid circle with an outgoing arrow shows the initial state.
Final State OR

 A bull’s eye – a solid circle surrounded by a hollow circle/encircled X shows the termination
point.
State
State
 Drawn as a rounded box containing the name of the state.
 State names must be unique within the scope of the state diagram.
 Our convention is to list state name in boldface, center the name near the top of the box, and
capitalize the first letter.
event(attribs) [condition]
Transition/Event
 Drawn as a line from the origin state to the target state.
 An arrowhead points to the target state.
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 53
Components of state diagram
event(attribs) [condition]
Guard condition
 A guard condition is a Boolean expression that must be true in order for a transition to occur.
 A guarded transition fires when its event occurs.
 Optionally listed in square brackets after an event.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 54
How to draw a state diagram
 Step 1: Identify the important objects.
 Step 2: Identify the possible states in which the object can exist.  
 Step 3: Identify the initial state and the final terminating states.
 Step 4: Label the events which trigger these transitions.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 55
State diagram for library management system
 Identify the important objects
 Book
 CD/DVD
 News Paper
 Librarian
 Member
 Identify the states of Book’s Object
 Available
 Issue
 Return
 Renew
 Identify the events / transition
 Book issued to user
 Submit the book
 Request to issue same book
 Completion of exam / end of the Semester
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 56
State diagram of book

Book

Book issued to user

Available Issue
s
D ay

Request to issue same book

o of ook
b
ok N t he
o n
Submit the book

R B etur

Book re-issue
] O R
xam nt to
o f e wa
t i on User
le R
o mp d O
c te
fter ple
[A Com

Return Renew

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 57
Example: State diagram of Bank Automated Teller Machine (ATM)
 This is an example of UML behavioral state diagram showing Bank Automated Teller Machine
(ATM) top level state machine.
 ATM is initially turned off. After the power is turned on, ATM performs startup action and enters
Self Test state.
 If the test fails, ATM goes into Out of Service state, otherwise there is trigger less transition to
the Idle state. In this state ATM waits for customer interaction.
 The ATM state changes from Idle to Serving Customer when the customer inserts banking or
credit card in the ATM's card reader.
 On entering the Serving Customer state, the entry action readCard is performed.
 Note, that transition from Serving Customer state back to the Idle state could be triggered by
cancel event as the customer could cancel transaction at any time.
 Serving Customer state is a composite state with sequential substates Customer
Authentication, Selecting Transaction and Transaction.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 58
State diagram of Bank Automated Teller Machine (ATM)
Bank ATM

turn off / shut-down turn off / shut-down

off

turn on /
startup
successfully failure
Self Test

turn on /
restart
failure
service Out of
Idle Maintenance Service
service
cancel

card inserted remove card failure

serving customer

Customer Selecting
Transaction
Authentication Transaction

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 59
Example: State diagram of Online Order
 Here is just another example of how an online ordering system might look like.
 On the event of an order being received, we transit from initial state to Unprocessed order state.
 The unprocessed order is checked.
 If the order is rejected, we transit to the Rejected order state.
 If the order is accepted and we have the items available, we transit to the fulfilled order state.
 However if the items are not available, we transit to the Pending order state.
 After the order is fulfilled, we transit to the final state. In this example, we merge the two states
i.e. Fulfilled order and Rejected order into one final state.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 60
State diagram of Online Order

Order
order received

ked Unprocessed [ac

c ept
C hec ] Ch
e ct] e ck
[rej ed

Rejected ilable Accepted

it e
va

ms
a
ot
en

ar
ea
r
sa

va
m

il
ite

ab
le
items are available
Pending Fulfilled

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 61
Data flow diagram
 A data flow diagram (DFD) is a graphical representation of the "flow of data” through an
information system.
 It includes data inputs and outputs, data stores, and the various sub processes, the data moves
through.
 Before actually creating your data flow diagram, you’ll need to determine whether a physical or
logical DFD best suits your needs.
 Yourdon and Coad type data flow diagrams are usually used for system analysis and design,
while Gane and Sarson type DFDs are more common for visualizing information systems.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 62
Symbols and Notations Used in DFD
External Entity
Entity is an outside system that sends or receives data, communicating with the system being
diagrammed. They are the sources and destinations of information entering or leaving the
system.

 External Entity External Entity

Yourdon and Coad Notation Gane and Sarson Notation
Data Store
A data store does not generate any operations but simply holds data for later access. Data
stores could consist of files held long term or a batch of documents stored briefly while they
wait to be processed.

Data Store Data Store

Yourdon and Coad Notation Gane and Sarson Notation
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 63
Symbols and Notations Used in DFD
Process
An activity that changes or transforms data flows. Since they transform incoming data to
outgoing data, all processes must have inputs and outputs on a DFD.
Process
Process

Yourdon and Coad Notation Gane and Sarson Notation

Data Flow
Movement of data between external entities, processes and data stores is represented with an
arrow symbol, which indicates the direction of flow.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 64
Rules for designing DFD
 No process can have only output or only input. The process must have both input and output.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 65
Rules for designing DFD
 There should not be a direct flow between data stored and external entity. The flow should be
go through a process.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 66
Rules for designing DFD
 No data should move directly between external entities. The data flow should go through a
process.

   

   

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 67
 Logical data flow diagram Physical data flow diagram
 Logical data flow diagrams focus on what  Physical data flow diagrams focus on how
happens in a particular information flow things happen in an information flow.
 What information is being transmitted, what  Physical DFD specify the software,
entities are receiving that info, what general hardware, files, and people involved in an
processes occur. information flow.
 The processes described in a logical DFD  A detailed physical data flow diagram can
are business activities, A logical DFD facilitate the development of the code
doesn’t delve into the technical aspects of a needed to implement a data system.
process or system.
 Non-technical employees should be able to
understand these diagrams.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 68
Example of logical data flow diagram
 Assume the process of cash deposit in bank
1.0
Payment prepare
Customer
deposit
tap

Receipt summary

2.0
Compare
cash and
tape

Validate receipt

3.0
Deposit
Prepare Bank
deposit

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 69
Example of physical data flow diagram
 Assume the process of cash deposit in bank

Cash 1.0
Customer
Clerk

Cash and
register tape

2.0
Cashier

Deposit slip
and cash

Bank

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 70
Data flow diagram levels
 Data flow diagrams are also categorized by level. Starting with the most basic, level 0, DFDs
get increasingly complex as the level increases.
 Level 0 DFDs, also known as context diagrams. It provides a basic overview of the whole
system.
 It shows the system as a single high-level process, with its relationship to external entities.
 DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram.
 You will highlight the main functions carried out by the system, as you break down the high-
level process of the Context Diagram into its sub processes.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 71
DFD Level-0 (Context Diagram) For LMS
 Assume all process of library.
Request for book
Member
Issue book

Library Return book

Request for generating report Management
System Search book
Issue and return
book report generated Result of searching book

Manage member account

Library Staff
Manage book database

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 72
DFD Level-1 For LMS

Book request 1.0

Issue Book
Library card book

Book Book Selves

Member
ook
B
2.0
Return
Book book

earc h q ue r y
S List of titles
Book request by name 3.0 title
Search author
Result by book name book List of author
Search query

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 73
DFD Level-2 For LMS

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 74
SRS (Software Requirements Specification)

Software Requirement Specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.

SRS is also helping the clients to understand their own needs.

SRS Contains

A complete information description A detailed functional description

A representation of system behaviour

An indication of performance requirements and design constraints

Appropriate validation criteria

Other information suitable to requirements
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 75
Characteristics of a Good SRS
 SRS should be accurate, complete, efficient, and of high quality, so that it does not affect the
entire project plan.
 An SRS is said to be of high quality when the developer and user easily understand the
prepared document.
 Characteristics of a Good SRS:

Correct Unambiguous Complete

SRS is correct when all user SRS is unambiguous SRS is complete when the
requirements are stated in the when every stated requirements clearly define
requirements document. requirement has only what the software is required
one interpretation. to do.
Note that there is no specified
tool or procedure to assure the
correctness of SRS.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 76
Characteristics of a Good SRS Cont.
Ranked for Importance/Stability Modifiable
All requirements are not equally important, hence The requirements of the user can
each requirement is identified to make differences change, hence requirements
among other requirements. document should be created in such
Stability implies the probability of changes in the a manner that those changes can be
requirement in future. modified easily.

Traceable Verifiable Consistent

SRS is traceable when the SRS is verifiable when the SRS is consistent when the
source of each requirement is specified requirements can be subsets of individual
clear and facilitates the verified with a cost-effective requirements defined do not
reference of each requirement process to check whether the conflict with each other.
in future. final software meets those
requirements.
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 77
Problems Without SRS
 Without developing the SRS document, the system would not be properly implemented
according to customer needs.
 Software developers would not know whether what they are developing is what exactly is
required by the customer.
 Without SRS, it will be very difficult for the maintenance engineers to understand the
functionality of the system.
 It will be very difficult for user document writers to write the users’ manuals properly without
understanding the SRS.

#21CS05203 (SE)  Unit 4 – Software Requirement

Prof. Rajkumar B. Gondaliya 78
Standard Template for writing SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Document Conventions 3.2 System Feature 2 (and so on)
1.3 Intended Audience and Reading Suggestions 4. External Interface Requirements
1.4 Project Scope 4.1 User Interfaces
1.5 References 4.2 Hardware Interfaces
2. Overall Description 4.3 Software Interfaces
2.1 Product Perspective 4.4 Communications Interfaces
2.2 Product Features 5. Other Nonfunctional Requirements
2.3 User Classes and Characteristics 5.1 Performance Requirements
2.4 Operating Environment 5.2 Safety Requirements
2.5 Design and Implementation Constraints 5.3 Security Requirements
2.6 User Documentation 5.4 Software Quality Attributes
2.7 Assumptions and Dependencies
6. Other Requirements
Appendix A: Glossary | Appendix B: Analysis Models | Appendix C: Issues List
#21CS05203 (SE)  Unit 4 – Software Requirement
Prof. Rajkumar B. Gondaliya 79
 Software Engineering (21CS05203)

Thank
You

Prof. Rajkumar Gondaliya

Computer Engineering Department
Darshan University, Rajkot
[email protected]
+91-9723232741