SOFTWARE

ENGINEERING
UNIT-II
Requirements Analysis and Specification
 REQUIREMENT ENGINEERING

• It is a description of features and functionalities of the target

system
• It is a description about what the system should do
• Requirement Engineering (RE) refers to the process of defining,
documenting, and maintaining requirement in the software
development process
• It consists of four parts
• Feasibility Study
• Requirement Elicitation / Gathering
• Software Requirement Specification (Functional + Non-functional )
• Software Requirement Validation

• These all four phase combinedly known as software management

REQUIREMENT ENGINEERING
PROCESS
FEASIBILITY STUDY
 TECHNICAL FEASIBILITY

• Technical Feasibility analyses and evaluates the project’s current

resources, including hardware and software along with the
technical requirements of the proposed system.

• In simple words, a technical feasibility study gives a report on

whether there exist required resources and new technologies
which will be used for proposed software development.

• Additionally, a technical feasibility study examines the technical

skills of the software development team, the viability of using
current technology, the ease of maintaining and upgrading the
technology of choice, and other factors.
 ECONOMIC FEASIBILITY

• Economic feasibility in terms of software development helps

companies to examine the development costs and financial
gains

• Economic feasible means the cost incurred in new software

development must exceed its benefits.

• Additionally, the total cost of the software project, including

any unplanned expenses, must be known beforehand.
 LEGAL FEASIBILITY

• Legal feasibility is one of the most important types of

feasibility studies in project management because, even if
money is abundant, each country’s laws must allow the
legal implementation of the project.

• Legal requirements include data protection acts (Digital

Personal Data Protection Act [DPDP Act 2023]), social
media law (privacy, defamation, content moderation,
intellectual property rights) , zoning laws (Land and
Building Acquisitions Act ) , and so on.
 OPERATIONAL FEASIBILITY

• Operational feasibility investigates how a new project will affect

your company’s daily processes, what procedures should be
implemented, and what efforts should be made to keep it running.

• For Example : Assume you’re launching a global e-commerce

platform. Then, in each country, you must have local warehouses,
service teams, and even local websites (Country based).

(To Advertise your software globally and locally so that different level
of users can come to purchase from the website like:- Distributor,
Retailer, Consumers ) .
 SCHEDULING FEASIBILITY

• Scheduling feasibility is a type of feasibility that helps

organization to set realistic deadlines for delivery of
software including other deliverables.

• A scheduling feasibility cannot be performed without

extensive knowledge of Technical, Economic, Legal, and
Operational feasibility.
 REQUIREMENT ELICITATION/
REQUIREMENT GATHERING
• Approach of requirement gathering
• Observation Reports ( User Observation)
• Questionnaires ( Stakeholders- meeting , Survey )
• Use cases
• User Stories
• Requirement Workshop
• Prototyping
• Role Base Requirement ( Assign Different Roles in team )
 SOFTWARE REQUIREMENT
SPECIFICATION (SRS)
• SRS is a description of a software system to be
developed
• It showcases the functional and non-functional
requirements of the software to be developed
• It may include set of use cases that describe user
interactions that the software must provide to the user
for perfect interaction.
• The software Estimation is done based on the SRS
document planned with functional and non-functional
requirements.
 SOFTWARE REQUIREMENT
SPECIFICATION (SRS)
• SRS document must include
• Introduction
• Purpose of document ( Why this software development is important)
• Intended Audience ( Who is going to use this SRS document)
• Scope ( Who will use the developed software )
• Definition ( Role based Access Definitions)
• References
• Overall Description
• User Interface
• System Interface ( Hardware + Software Descriptions)
• Constraints in User interface or System interface
 SOFTWARE REQUIREMENT
SPECIFICATION (SRS)
• SRS document must include
• System Features and Requirements
• Functional Requirements
• Non-Functional Requirements
• Use Cases
• External Interface Requirements
• Deliver For Approval ( Delivered to different teams for
approval including stakeholders)
 SOFTWARE REQUIREMENT
SPECIFICATION
• Functional Requirements
• Requirements which are related to functional working
aspect of software comes into this category
• Example : Login Page, Registration Page, etc.

• Non-functional Requirements
• Non-functional requirements are expected characteristics of
target software.
• Example: Security, Privacy, Scalability, Configuration,
Recovery, Accessibility, etc.
 USER REQUIREMENT
SPECIFICATIONS (URS)
• Once the software is delivered ( deployed ) to customer (
market) then user should get below features
• Easy and simple to operate
• Quick Response
• Effectively handling operational errors
• Customer supports

• URS is the contractual agreement between the

Organization and Stakeholders in terms of what user’s
will get from the system.
 SOFTWARE REQUIREMENT
VALIDATION
• Requirements validation techniques are essential processes
used to ensure that software requirements are complete,
consistent, and accurately reflect what the customer wants.

• These techniques help identify and fix issues early in the

development process, reducing the risk of costly errors later on.

• By thoroughly validating requirements, teams can ensure that

the final product meets user needs and expectations.
 SOFTWARE REQUIREMENTS
VALIDATION TECHNIQUES
• Test Case Generation
• Prototyping
• Requirement Reviews
• Automated Consistency analysis – CASE Tools is used
• Walk- through – Taking opinions from other people or
team
• Simulations
• Checklist for validations
 DATA FLOW DIAGRAM (DFD)
OR BUBBLE CHART
• A graphical tool useful for communicating with users,
managers, and other personnel (Analysts).
• Uses for analysis existing as well as proposed system
• Focus on the movement of data between external
entities and process, and between process to data
stores.
• This is very simple technique to understand the system
by visualizing data and its flow between the modules.
 WHY DFD

• Provides an overview of
• What data a system processes
• What transformation are performed on data
• What types of data are stored in the system
• What types of results are produced on data

• The graphical nature makes DFD as a good

communication tools between
• User and Analysts
• Analysts and System Designer
 DFD ELEMENTS

• Source / sink Rectangle

• Data Flow Arrow

• Processes Eclipse

• Data Stores Parallel Lines

 EXTERNAL ENTITIES

• External entities can be source and sink

• Source - > Entities that supply data to the system
• Sink -> Entities that receive data from the system
• It is represented by rectangle
• They either supply or receive the data to/from the
system
• They do not process data
 DATA FLOW

• Marks movement of data through system – a pipeline to

carry data

• Connects the process, external entities, and data stores

• Generally unidirectional, if data flows with both

directions, double-headed arrow can be used
 PROCESSES

• Circle represents process

• Straight line with incoming arrows are input data flows
• Straight line with outgoing arrows are output data flows
• Labels are assigned to data flows

Stores demand
notes Issue slip
Stores
 DATA STORES

• A data store is a repository of data

• Data can be written into the data store. This is depicted
by the incoming arrow
• Data can be read from the data stores. This is depicted
by an outgoing arrow
• External entities can not read and write data to/from the
data stores directly.
 RULES OF DATA FLOW

Data can flow from Data can’t flow from

External entity to process External entity to external entity

Process to external entity External entity to stores

Process to store and back Store to external entity

Process to process Store to store

 DECOMPOSITION OF DFD

• A system is too complex to be shown in a single DFD

• Decomposition is the iterative process of breaking down
data flow diagram to create more details
• Level ‘0’ data flow diagram may be exploded into
successive low levels of details. The next level of details
would be a level ‘1’ data flow diagram
• The DFD becomes linked together in a hierarchy which
would fully document the system
 LEVEL -0 DFD

Request Check
Admissio
USER ADMIN
n
Response Response
 LEVEL-1 DFD

Report
Request Generatio
Perform
Intake n
USER
Process
Response Check

Information Data Stores ADMIN

Update
Module
Maintain
Informatio
n (CRUD) Search Details of Admissions
 LEVEL-2 DFD
Generat
e
Receive Reports
Admissio
Request n Form
Data Store
Verify ADMIN
USER
Forms
Data Store
Maintain
Admission
Response
Informatio
Check lists of
n
Admission Search Details
Details of Admissions
 USE CASE DIAGRAM

• A Use Case Diagram in Unified Modeling Language (UML) is a visual

representation that illustrates the interactions between users (actors)
and a system.

• It captures the functional requirements of a system, showing how

different users engage with various use cases, or specific
functionalities, within the system.

• Use case diagrams offer a high-level view of a system’s behavior,

helping stakeholders, developers, and analysts understand its operation
and the relationships between processes from the user’s perspective.
FLIGHT BOOKING SYSTEM
 MODULE DESIGN
(LAYERED APPROACH)

Good Design
M1

M2 M3

M4 M5 M6
 MODULE DESIGN
(LAYERED APPROACH)

Bad Design
M1

M2 M3

M4 M5 M6
 TRANSFORMATION OF DFD
MODEL INTO STRUCTURE CHART
• Two strategies exists to guide transformation of a DFD into structure
chart
• Transform Analysis
• Transaction Analysis

• Transform Analysis ( Same Data and Same Process)

• Transform Analysis divides DFD into 3 parts
• Input
• Process
• Output

• Transaction Analysis (Different Data and different process)

• Transform Analysis divides DFD into 3 parts
• Input
• Process
• Output
TRANSACTION STRUCTURE
CHART

Different Input
(Based on Condition)
TRANSFORM STRUCTURE
CHART

Same Input

Different
Input
 STRUCTURE CHART

• Structure chart is an important design technique which

shows all components in a hierarchal format
• It shows following properties
• Sequence : Orders of components are invoked (one after
another)
• Selection : Under what condition a module is invoked
• Iteration : how often a component is repeated
 SHORTCOMING OF
STRUCTURED CHART
• By examining of structure chart
• We can not say whether a module calls another module just
once or many times

• Also by looking at structure chart

• We can not tell the order in which the different modules are
invoked ( It means that which module will start first and
then sequence will be maintained)
 STRUCTURE CHART

Patron:- refers to a person who uses the library's services and resources,
essentially meaning a library user.
 FLOW CHART VS STRUCTURE
CHART
• It is a difficult to identify modules of a software from its
flow chart representation
• Data interchange among the modules is not represented
in a flow chart
• Sequential ordering of task inherent in a flow chart is
suppressed in a structure chart
 DATA DICTIONARY

• Data dictionary contains information about the data

(metadata)
• Data dictionary contains information about the following
• Name of all the tables and their schema
• Details about all the tables in the database, such as their
owners, security constraints, when they were created, etc.
• Physical information about the tables such as where they
are stored and how
• Table contains such as primary key and foreign key, etc.
DATA DICTIONARY EXAMPLE
 DATA DICTIONARY

• Item to be defined in data dictionary

• Data Element : Attribute which can not be broken further
(simple attribute)
• Data Structure :- (Group of Data elements which is inter-
related) Composite Attributes
• Data Flow & Data Stores: It showcase data flow diagram
(DFD)
 DATA DICTIONARY

• Advantage
• improved data consistency, clarity in data definitions,
easier maintenance, and better data quality by
documenting data elements and their relationships.

• Disadvantage
• Maintaining a data dictionary in potential complex ( For
large systems it is very difficult particularly when regular
updates are done).
 ER-DIAGRAM

• ER Diagram is used to represent logical or conceptual

view of database
• ER diagram is by default represented in 3NF
• ER Diagram consists of Entity and Attributes
• Entity : It is a physical or logical representation of an
object
• Attributes: It shows property of an entity
 TYPES OF ATTRIBUTES

• Single Vs Multivalued attributes

(Single :- Reg no , Multi-valued Attribute: phone number, color)

• Simple Vs Composite Attribute

(Simple :- Age, Composite : Name-(First, Middle, Last)

• Stored Vs Derived Attributes

(Stored- DOB , Derived : Age)

• Key Vs Non-key Attribute

(key – Reg no, Non-key : salary)

• Complex Attribute -> (Composite + Multivalued)

(Address-Phone)
ER DIAGRAM NOTATIONS
 RELATIONSHIP CARDINALITY

• One to One

Work Department
Employee s for

EmpID Ename Eaddress DeptID Dname DLocatio

n
E1 Ram Ranchi D1 IT Ranchi
E2 Akash Bhopal D2 Productio Bhopal
n
E3 Raman Delhi
D3 HR Delhi
 RELATIONSHIP CARDINALITY

• One to Many

Customer Gives Order

CID Cname CCity OID Oname Cost

C1 Ram Ranchi O1 Shoes 1000

C2 Akash Bhopal O2 Shirt 2000

C3 Raman Delhi O3 Jeans 3000

 RELATIONSHIP CARDINALITY

• Many to Many

Student Study Course

SID Sname SAddres CID Cname CCredit

s
C1 Math 4
S1 Ram Ranchi
C2 Physics 4
S2 Akash Bhopal
C3 Chemistry 4
S3 Raman Delhi
 DECOMPOSITION

• The Tables which is made after Modeling of ER Diagram

must follow the decomposition rules
• It should be lossless
• It should preserve dependency

• Decomposition is used in Database to ensure consistency

and integrity of data
• True Decomposition also removes anomalies from the
A tableB C A B B C
1 2 1 1 2 2 1
2 2 2 2 2 2 2
3 3 2 3 3 3 2
 DECOMPOSITION
A B C A C B C
1 2 1 1 1 2 1
2 2 2 2 2 2 2
3 2 3 2
3 3 2

A B C A B A C
1 2 1 1 2 1 1
2 2 2 2
2 2 2
3 3 3 2
3 3 2
 IF TABLE IS DECOMPOSED
WITH FOREIGN KEY
• Rules to be followed- A successful decomposition of
Table
Referenced Table (PK) Referencing Table (FK)

Insert Record (No Violation) Insert Record ( May cause

Violation)
Delete Record ( May cause Delete Record ( No Violation)
Violation)
Update Record (May cause Update Record (May cause
Violation) Violation)
 DEPENDENCY PRESERVATION

Q1) R (A, B, C, D)
F.D = { A->B, B->C, C->D, D->B}
Relation ‘R’ is decomposed into R1 (A,B), R2 ( B,C) , R3 (B,D)
Does this decomposition preserve dependency ?

Q2) R (A, B, C, D)
F.D = { AB->D, D->A}
Relation ‘R’ is decomposed into R1 (A,D), R2 ( B,C,D)
Does this decomposition preserve dependency ?
UML DIAGRAMS VIEW
 UML DIAGRAMS

• Class Diagram : it shows set of classes and their

relationships.
• Object Diagram : It shows set of objects and their
relationships
• Component Diagram: It shows logical grouping of
elements and their relationships
• Deployment Diagram: It shows set of computational
resources (nodes) that host each component
 UML DIAGRAMS

• Use case Diagram : it shows High level behaviors of the

system, user goals, external entities-actors
• Sequence Diagram : It focus on the time ordering of the
system
• Collaboration Diagram: It focus on structural organization of
objects and message
• State chart diagram : Event driven state changes of the
system
• Activity Diagram : It shows flow of control between activities
 PETRI NETS

• Petri nets were invented by Carl Adam Petri in 1939 at

the age of 13. This work was the foundation for his 1962
doctoral dissertation entitled Kommunikation mit
Automaten.
• Petri nets have been used in a variety of fields including
computer science, chemistry, and biology.
• He retired from the Theoretical Foundation of Computer
Science group at the University of Hamburg in 1991.
 WHY PETRI NETS

• Petri nets are a graphical for representing a system in

which there are multiple independent activities in
progress at the same time (Concurrent Operation and
Activity).
• The ability to model multiple activities differentiates Petri
nets from finite state machines.
• In a finite state machine there is always a single
“current” state that determines which action can next
occur.
• In Petri nets there may be several states any one of
which may evolve by changing the state of the Petri net.
 PETRI NETS REPRESENTATION

• A Petri net consists of four elements: places, transitions,

edges, and tokens.
• Graphically, places are represented by circles, transitions
by rectangles, edges by directed arrows, and tokens by
small solid (filled) circles.
PETRI NETS MACHINES
 PETRI NETS

• Advantage
• ability to visually represent complex concurrent systems
with clear distinction between states and transitions.
• Disadvantage
• It has potential complexity when modeling large
systems, difficulty in analyzing complex behaviors of the
system.
UNIT –II (COMPLETED)

THANK YOU