Unit2 SE Updated

Noida Institute of Engineering and Technology, Greater Noida
Software Requirement
Specification
Unit: 2
Software Engineering
Dr Poornima Tyagi
ACSE0603
Associate Professor
(B Tech VIth Sem) (CSE)
Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2

1
05/17/2024
Faculty Profile
FACULTY PROFILE
Name of Faculty: Dr. Poornima Tyagi
Designation & Department: Assistant Professor, CSE Dept.
Qualification: MCA, MTech & PhD
Experience: Have 12 years experience of teaching subjects

such as Cyber Security, DBMS, Software Engineering,
Software Project management.
05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 2

Evaluation Scheme
Dr. Poornima Tyagi Software Engineering ACSE0603

05/17/2024 3
Unit 2
Syllabus

Syllabus

Branch wise Applications
• Software engineering applications are new idea, device or process.

Innovations are the application of better solutions that meet new
requirements, in articulated needs or existing market needs.
• The exhaustive and widespread use of computers and the
improvements in database technology have provided large data.
• The emerging growth of data in databases has generated an urgent
need for efficient data mining techniques to discover useful
informational knowledge.
05/17/2024 Dr. Poornima Tyagi Software Engine 6

ering ACSE0603 Unit 2
Course Objective(unit-2)
• An understanding of software requirements and SRS document.

• An understanding of implementation issues such as software Quality Frameworks,
ISO 9000 Models, and SEI-CMM Model.

Course Outcome
Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

05/17/2024 8
2
Program Outcomes (PO)
• PO1: Engineering Knowledge

• PO2: Problem Analysis
• PO3: Design/Development of solutions
• PO4: Conduct Investigations of complex problems
• PO5: Modern tool usage
• PO6: The engineer and society
• PO7: Environment and sustainability
• PO8: Ethics
• PO9: Individual and team work
• PO10: Communication
• PO11: Project management and finance
• PO12: Life-long learning

05/17/2024 9
CO-PO Mapping
CO-PO Correlation Matrices
Correlation levels are taken 1, 2 and 3 as defined below:

1: Slight (Low) 2: Moderate (Medium) 3: Substantial (High)
Software Engineering (Code: AIT0401)
CO PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12
AIT0401.1 2 3 3 3 2 - - - - - 3 3
AIT0401.2 3 3 3 3 3 - - - - - 2 3
AIT0401.3 3 2 3 2 2 - - - - - 3 3
AIT0401.4 2 2 2 2 3 3 - 3 3 - 3 3
AIT0401.5 2 2 3 2 3 3 - 3 - 3 3 3

Program Specific Outcomes(PSO)
On successful completion of graduation degree the Engineering

graduates will be able to:
PSO1: The ability to identify, analyze real world problems and design
their ethical solutions using artificial intelligence, robotics,
virtual/augmented reality, data analytics, block chain technology,
and cloud computing.
PSO2:The ability to design and develop the hardware sensor devices
and related interfacing software systems for solving complex
engineering problems.
PSO3:The ability to understand inter disciplinary computing
techniques and to apply them in the design of advanced computing.
PSO4: The ability to conduct investigation of complex problem with
the help of technical, managerial, leadership qualities, and modern
engineering tools provided by industry sponsored laboratories.

05/17/2024 11
Unit 2
Program Educational Objectives
PEO1: To have an excellent scientific and engineering breadth so as to

comprehend, analyze, design and provide sustainable solutions for
real-life problems using state-of-the-art technologies.
PEO2:To have a successful career in industries, to pursue higher studies or
to support enterpreneurial endeavors and to face global challenges.
PEO3:To have an effective communication skills, professional attitude,
ethical values and a desire to learn specific knowledge in emerging
trends, technologies for research, innovation and product
development and contribution to society.
PEO4: To have life-long learning for up-skilling and re-skilling for
successful professional career as engineer, scientist, enterpreneur
and bureaucrat for betterment of society

5/17/2024 12
Unit 2
CO-PEO Mapping
Program Educational Objectives and Course Outcomes Mapping
CO PEO1 PEO2 PEO3 PEO4
CO1 3 3 - 3
CO2 3 2 2 3
CO3 2 3 - 2
CO4 3 1 - 3
CO5 3 3 - 3
*3= High *2= Medium *1=Low

Result Analysis
Subject Result = 100%

05/17/2024 14
Unit 2
End Semester Question Paper Templates
B TECH
(SEM-V) THEORY EXAMINATION 20__-20__
SOFTWARE ENGINEERING
Time: 3 Hours Total Marks:
100
Note: 1. Attempt all Sections. If require any missing data; then choose
suitably.
SECTION A
1. Attempt all questions in brief. 1 x 10 = 10
Q.No. Question Marks CO
1 2
2 2
. .
10 2

05/17/2024 15
2
SECTION A
2. Attempt all questions in brief. 2 x 5 = 10
1 2
2 2
. .
5 2

SECTION B
3. Attempt any five of the following: 5 x 6 = 30
1 6
2 6
. .
7 6
SECTION C
4. Attempt any one part of the following: 1 x 10 = 10
1 10
2 10

Prerequisite/Recap
• A Scripting Language
• A Version Control Tool
• Code Editors & IDEs (Integrated Development Environment)
• Databases
• Networking
• Software Development Life Cycle (SDLC)
• Basic Programming Skills
• Innovative Thinking.
• Enthusiasm to learn Management concepts.

05/17/2024 18
Stakeholders and Requirements (Bridging Content)
Stakeholder :. The term “stakeholder” in software engineering refers to people or

groups that are affected directly or indirectly by a software. In any case, they are
interested in the final product. Examples are end user, developer, tester, coder
etc.
• User Requirements
– User requirement are written for the users and include functional and
non-functional requirement.
• System Requirements
– System requirement are derived from user requirement.
– The user system requirements are the parts of software requirement and
specification (SRS) document.

05/17/2024 19
Unit 2
User Requirement Types
• Known Requirements :
– something a stakeholder believes to be implemented.
• Unknown Requirement :
– forgotten by the stakeholder because they are not needed right now
or needed only by another stakeholder.
• Undreamed Requirement :
– stakeholder may not be able to think of new requirements due to
limited domain knowledge.

05/17/2024 20
Unit 2
Type of Requirement
Known, unknown, undreamed requirements may be functional or non-

functional.
• Functional Requirements
– it is related to the expectations from the intended s/w.
– It describe what the s/w has to do.
– Sometimes it may also specify what the s/w should not do.
• Non-Functional Requirements
• It is mostly quality requirements that stipulate how well the
s/w does what it has to do.
• For user includes specification of performance, availability,
usability and flexibility.
• For developers are maintainability, portability and testability.

05/17/2024 21
2
Types of User Requirements
• Functional Requirements: These describe the specific functions or capabilities that the software system must perform.
Functional requirements typically define what the system should do in response to specific inputs and under certain
conditions. Examples include user authentication, data validation, and report generation.
• Non-functional Requirements: These specify the quality attributes or constraints that the system must meet, rather than
specific behaviors. Non-functional requirements often relate to aspects such as performance, scalability, reliability, security,
usability, and maintainability. Examples include response time, availability, and security measures like encryption.
• Business Requirements: These describe the high-level objectives or goals that the software system aims to achieve for the
organization or business. Business requirements provide the context for the project and help ensure that the software
solution aligns with the strategic objectives of the stakeholders.
• User Interface Requirements: These detail the characteristics of the user interface, including layout, navigation, and
interaction design. User interface requirements ensure that the software system is intuitive, user-friendly, and meets the
needs of its intended users.
• System Requirements: These specify the hardware, software, and network infrastructure needed to support the software
system. System requirements ensure that the software can be deployed and operated effectively in the intended
environment.
• Performance Requirements: These define the performance criteria that the software system must meet, such as response
time, throughput, and resource utilization. Performance requirements ensure that the software system can handle
expected workloads efficiently.
• Usability Requirements: These describe the characteristics of the software system that contribute to its ease of use and
user satisfaction. Usability requirements may include factors such as accessibility, learnability, and error recovery.
• Security Requirements: These outline the security measures that must be implemented to protect the software system
from unauthorized access, data breaches, and other security threats. Security requirements help ensure the confidentiality,
integrity, and availability of the system and its data.
• Regulatory Requirements: These specify the legal and regulatory standards that the software system must comply with,
such as industry regulations or government mandates. Regulatory requirements ensure that the software system meets
relevant legal obligations and industry standards.

Examples of Requirements
Functional Requirements Example:

1. Authentication of a user when he/she tries to log into the system and
Verification email is sent to user whenever he/she registers for the first
time on some software system.
2. System shutdown in the case of a cyber attack.
Non-functional Requirements Example:

3. Each request should be processed within 10 seconds.
4. The site should load in 3 seconds when the number of simultaneous users
are > 10000

05/17/2024 23
2
Case Study to understand the Requirements
A University wish to develop a software system for the student result

management of its M.Tech Program. A problem statement is to be prepared for
the software development company. The problem statement may give an
overview of the existing system and broad expectations from the new software
system.
Problem statement (prepared by Exam Division of University)
– University conduct 4-semester M.Tech program. Students are offered four
theory and two practical paper during I,II and IIIrd semester.
– In IV sem. Students have to give a seminar and submit a dissertation on
topic area of their interest.
– Evaluation of each theory subject is done out of 150 marks. 100 for
university conduct exam and 50 for sessional exam, attendance and
student assignment.
– Evaluation of practical exam is done out of 50. 25 for university exam and
25 for internal in which student prepared lab record, viva, attendance.
05/17/2024 24
Unit 2
Case Study
– Marks of IV sem. Dissertation is 450. 200 if for internal and 250 for
external.
– If total marks in each subject of a student is 50 % then student is
considered pass otherwise student is considered as failed.
– At any time, the latest information about subjects being offered in various
semesters and their credit points can be obtained from university website.
• It is required to develop a system that manage information about subject
offered in various sem. Students enrolled in various sem. Marks obtained by
students in different sem.
• The system should also have the ability to generate printable mark-sheets for
each student. Semester-wise detailed mark-lists and student performance
reports also need to be generated.

05/17/2024 25
Unit 2
Requirement Engineering (CO2)
• Requirements engineering (RE) refers to the process of defining,

documenting, and maintaining requirements in the engineering design
process.
• It describe the “What” of a system, not the “How”.
• It’s input is problem statement prepared by the customer.
• It produces one large document (SRS), written in natural language, contain
the description of what the system will do without describing how it will do.
It’s process consists four steps:

– Requirement Elicitation.
– Requirement Analysis.
– Requirement Documentation.
– Requirement Review.

05/17/2024 26
Unit 2
Requirement Engineering (CO2)

05/17/2024 27
2
Requirement Engineering Process (CO2)
1. Requirement Elicitation(Extraction)
– It is known as requirement gathering.
– Requirement is identified with the help of customer and
existing system process.
2. Requirement Analysis
– It starts with requirement elicitation.
– It perform to identify inconsistencies, defects, etc.
3. Requirement Documentation
– It is the end product of 1 and 2. known as SRS.
– Document provides the foundation of s/w design.
– SRS may act as a contract between developer and customer.
4. Requirement Review
– It is carried out to improve the quality of SRS.
– It may also be called as requirement verification.
05/17/2024 28
Unit 2
Requirement Elicitation (CO2)
• It is most important goal of RE to find out what users really need.

• It is ability that helps to understand the problem to be solved.
• It is conduct by asking que., writing down answers, asking other que., etc.
• Developers and users have different mind set, expertise and vocabularies so
there are chances of conflicts that may led to inconsistencies,
misunderstanding and omission of requirements .
• It requires the collaboration of several groups of participants who have
different background.

05/17/2024 29
Unit 2
Requirement Elicitation Methods
1. Interviews.
2. Brainstorming Sessions.
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment.
5. The use Case Approach.

05/17/2024 30
Unit 2
Interviews
Interviews :
Objective of conducting an interview is to understand the customer’s expectations
from the software.
It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility.
• Interviews maybe be open-ended or structured.

1. In open-ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes
a proper questionnaire is designed for the interview.

05/17/2024 31
Unit 2
Brainstorming Sessions
Brainstorming Sessions :
It is a group technique.
• It is intended to generate lots of new ideas hence providing a platform
to share views
• A highly trained facilitator is required to handle group bias and group
conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.

Facilitated Application Specification Technique(FAST)
Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they are
going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
• Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, team is divided into smaller sub-teams to
develop mini-specifications and finally a draft of specifications is written
down using all the inputs from the meeting.

Quality Function Deployment
Quality Function Deployment:

In this technique customer satisfaction is of prime concern, hence it emphasizes on
the requirements which are valuable to the customer.
3 types of requirements are identified –
• Normal requirements –
In this the objective and goals of the proposed software are discussed with the
customer. Example – normal requirements for a result management system
may be entry of marks, calculation of results, etc
• Expected requirements –
These requirements are so obvious that the customer need not explicitly state
them. Example – protection from unauthorized access.
• Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be
very satisfying when present. Example – when unauthorized access is detected,
it should backup and shutdown all processes.

05/17/2024 34
2
Quality Function Deployment is a methodical approach used in product

development to ensure that customer needs are accurately captured and
translated into specific product features and characteristics. It originated in
Japan in the 1960s and has since become a widely adopted practice in
various industries worldwide.
Identifying Customer Requirements:
The first step in QFD is to identify and prioritize customer requirements.
This involves gathering data through techniques such as surveys, interviews,
focus groups, and market research to understand what customers value and
expect from the product.
Developing the House of Quality (HOQ):The House of Quality is a key tool
in QFD. It is a matrix that visually represents the relationship between
customer requirements and technical features of the product.
The HOQ typically consists of the following components:
Customer Requirements: These are the needs, preferences, and
expectations of the customers. They are usually listed on the left side of the
matrix.
Technical Requirements: These are the specific characteristics or attributes of the product that will
satisfy the customer requirements. They are listed across the top of the matrix.
Relationship Matrix: This section of the HOQ shows the strength of the relationship between each
customer requirement and technical requirement. It is filled in based on input from cross-functional
teams and subject matter experts.
Prioritization Scales: These scales are used to assign relative importance or priority to each
customer requirement and technical requirement. They help in focusing efforts on the most critical
aspects of the design.
Translating Customer Requirements into Engineering Characteristics:
Once the House of Quality is completed, the next step is to translate customer requirements into
specific engineering characteristics or design parameters. This involves brainstorming and identifying
potential design solutions that address the technical requirements identified in the HOQ.
Implementing Design Changes: Based on the results of the QFD process, design changes and
improvements are implemented to align the product with customer needs and preferences. This may
involve refining existing features, adding new features, or modifying the product design to better
meet customer expectations.
Continuous Improvement: QFD is not a one-time activity but rather an iterative process that
involves continuous improvement. As customer needs and market conditions change, organizations
use feedback from customers and performance data to refine their products and processes, ensuring
ongoing satisfaction and competitiveness.

Quality Function Deployment :

The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
1. It is possible to achieve
2. It should be deferred and the reason for it
3. It is impossible to achieve and should be dropped off

05/17/2024 37
2
• 5 Points : Very Important

• 4 Points : Important
• 3 Points : Not Important but nice to have
• 2 Points : Not important
• 1 Points : Unrealistic, required further, exploration
• Final list of requirements categorize like:
• (i) It is possible to achieve
• (ii) It should be deferred & Why
• (iii) It is impossible and should be dropped from consideration
• First Category requirements will be implemented as per priority assigned
with every requirement.
05/17/2024 38
Use Case Approach
• This technique combines text and pictures to provide a better

understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they
only give a functional view of the system.
The components of the use case design includes three major things –
Actor, Use cases, use case diagram.
1. Actor –
It is the external agent that lies outside the system but interacts with it in
some way. An actor maybe a person, machine etc. It is represented as a
stick figure. Actors can be primary actors or secondary actors.
1. Primary actors – It requires assistance from the system to achieve a
goal.
2. Secondary actor – It is an actor from which the system needs
assistance.

05/17/2024 39
2
Use Case Approach
2. Use cases –
They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete
set of use cases specifies all possible ways to use the system.
3. Use case diagram –
A use case diagram graphically represents what happens when an actor
interacts with a system. It captures the functional aspect of the system.
1. A stick figure is used to represent an actor.
2. An ellipse is used to represent a use case.
3. A line is used to represent a relationship between an actor and a use
case.

05/17/2024 40
2
Use case Diagram
-- represents what happens when actor interacts with a system.

-- captures functional aspect of the system.
Relationship between
actors and use case
Use Case
Actor and/or between the
use cases.
-- Actors appear outside the rectangle.

--Use cases within rectangle providing functionality.
--Relationship association is a solid line between actor & use cases.

Use Case Template
Introduction: Describe a quick background of the use case.

Actors : List the actors that interact and participate in the use cases.
Pre Conditions : Pre conditions that need to be satisfied for the use
case to perform.
Post Conditions : Define the different states in which we expect the
system to be in, after the use case executes.

05/17/2024 42
Unit 2
Use Case Template
Flow of events
Basic Flow : List the primary events that will occur when this use
case is executed.
Alternative Flows: Any Subsidiary events that can occur in the
use case should be separately listed. List each such event as an
alternative flow. A use case can have many alternative flows as
required.
Special Requirements : Business rules will be used for writing test
cases. Both success and failures scenarios should be described.
Use Case relationships : For Complex systems Listing the relationships
between use cases also provides a mechanism for traceability

05/17/2024 43
Unit 2
Use Case Template
Use Case Guidelines
1. Identify all users.

2. Create a user profile for each category of users including all
roles of the users play that are relevant to the system.
3. Create a use case for each goal, following the use case
template maintain the abstraction throughout the use case.
4. Structure the use case.
5. Review and validate with users.

05/17/2024 44
2
Cont..

Login(Template)
Login
• 1.1 Introduction : This use case describes how a user logs into the
Result Management System.
• 1.2 Actors : (i) Data Entry Operator
(ii) Administrator/Deputy Registrar
• 1.3 Pre Conditions : None
• 1.4 Post Conditions :
If the use case is successful, the actor is logged into the
system. If not, the system state is unchanged.

05/17/2024 46
Unit 2
Login(Template)
1.5 Basic Flow : This use case starts when the actor wishes to login to
the Result Management system.
• (i) System requests that the actor enter his/her name and
password.
• (ii) The actor enters his/her name & password.
• (iii) System validates name & password, and if finds correct allow
the actor to logs into the system.

Login(Template)
• 1.6 Alternate Flows

– 1.6.1 Invalid name & password
If in the basic flow, the actor enters an invalid name and/or password, the system
displays an error message. The actor can choose to either return to the beginning
of the basic flow or cancel the login, at that point, the use case ends.
1.7 Special Requirements: None

1.8 Use case Relationships: None

Requirement Analysis (CO2)
• We analyze, refine and scrutinize gathered requirements to make

consistent & unambiguous requirements.
• Activity reviews all the requirement ands may Provide graphical
view of the entire system.
• May also interact with customer to resolve their confusion and find
priority of requirements.

05/17/2024 49
Unit 2
Steps of Requirement Analysis

05/17/2024 50
Unit 2
Context Diagram
A context diagram is a high-level view of a
system. It’s a basic sketch meant to define an
entity based on its scope, boundaries, and
relation to external components like
stakeholders.

Symbols used in Context Diagram
External Entity- an element in the system diagram
that inputs data into the information system and
retrieves processed data.
Process- refers to the entire process of the system.
This is responsible for processing and distributing
information to the entities of the system context
diagram.
Flow Line- this element depicts the flow of the
data within the system. It is supported by text to
show what type of data is being sent.

Benefits of using Context Diagram
• The diagram does not show any details regarding the technical structure.
• It is one of the best illustrations to present your business project. This way
you can clearly explain the project to an audience with no technical
knowledge.
• A system context diagram is an excellent tool for any line of business that
needs an automated system of services.

Development of Prototype(Optional)
• It is effective way to find out what the customer really want.

• We take customer feedback to continuously modify the prototype until
he/she is satisfied.
• It should be built quickly and at a relatively low cost.
• Due to its limitations and would not be acceptable in final system it is an
optional activity.
• Many organization are developing prototypes for better understanding
before the finalization of SRS.

Model the Requirement
• This process consists of various graphical representation of functions, data

entities, external entities and relationship between them.
• Graphical view help us to find incorrect, missing, and inconsistent
requirements.
• Such models includes
– Data flow diagram
– Entity Relationship Diagram(ERD)
– Data Dictionary
– Decision Table, etc.

05/17/2024 56
Unit 2
Finalize the Requirements
• After modeling the requirements, we will have better

understanding of the system behavior.
• Inconsistencies and ambiguities have been identified.
• Now we finalize the analyzed requirements and next step is to

document these requirements in a prescribed format

05/17/2024 57
Unit 2
Data Flow Diagrams(CO2)
• Also known as data flow graph or bubble chart.

• It shows the flow the data through a system.
• It represent a systems in terms of input data to the system, various
processing carried out on those data, and the output data generated by
the system.
• System may be an organization, a set of procedures, a computer H/W
system, a s/w system, etc.
• In DFD
– All names should be unique.
– It is not a flow chart. Arrow represent flowing of data without any order.
– Suppress logical decisions.
– Defer error conditions & handling until the end of the analysis.

DFD

05/17/2024 59
Unit 2
Operation in DFD
• Synchronous : if two bubble

are directly connected by a
data flow arrow i.e. they are
operate at the same speed.
• Asynchronous: if two bubble

are connected through a data
store then speed of operation
of the bubble are
independent.

05/17/2024 60
Unit 2
Developing DFD model of a system
• Step1: Construction of context diagram. It a top level DFD , usually

called 0 level DFD.(A level 0 DFD is called fundamental system model
or context model represents entire software element as a single
bubble with input and output data indicating by incoming &
outgoing arrows.)
• Step2: Construction of level1 DFD. Expend the process of context
diagram.
• Step3: Construction of lower level DFD. Decompose the process of
level 1 DFD recursively.

A case study of Root Mean Square Calculating System

2 and 3 Level DFD
05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 63

2
Data Dictionary
Data Dictionary is the major component in the structured
analysis model of the system. It lists all the data items appearing
in DFD. A data dictionary in Software Engineering means a file or
a set of files that includes a database’s metadata (hold records
about other objects in the database), like data ownership,
relationships of the data to another object, and some other data.
Case Tools is used to maintain data dictionary as it captures the
data items appearing in a DFD automatically to generate the
data dictionary.
Case tools: CASE illustrates a wide set of labor-saving tools that are used in
software development.

Data Dictionary
• It is an organized collection of all the data elements of the system

and their brief description
– Includes :
• Name of data item
• Aliases (other names for items)
• Description/Purpose
• Related data items
• Range of values
• Data flows
• Data structure definition

05/17/2024 65
Unit 2
Features of Data Dictionary
• It helps in designing test cases and designing

the software.
• It is very important for creating an order list
from a subset of the items list.
• It is very important for creating an order list
from a complete items list.
• The data dictionary is also important to find
the specific data item object from the list.

Uses of Data Dictionary
• Used for creating the ordered list of data items

• Used for creating the ordered list of a subset
of the data items
• Used for Designing and testing software in
Software Engineering
• Used for finding data items from a description
in Software Engineering

Importance of Data Dictionary:
• It provides developers with standard

terminology for all data.
• It provides developers to use different terms
to refer to the same data.
• It provides definitions for different data
• Query handling is facilitated if a data
dictionary is used in RDMS.

Advantages of Data Dictionary
• Consistency and Standardization: A data dictionary helps to ensure that
all data elements and attributes are consistently defined and named
across the organization, promoting standardization and consistency in
data management practices.
• Data Quality: A data dictionary can help improve data quality by
providing a single source of truth for data definitions, allowing users to
easily verify the accuracy and completeness of data.
• Data Integration: A data dictionary can facilitate data integration efforts
by providing a common language and framework for understanding data
elements and their relationships across different systems. Improved
Collaboration: A data dictionary can help promote collaboration between
business and technical teams by providing a shared understanding of data
definitions and structures, reducing misunderstandings and
communication gaps.
• Improved Efficiency: A data dictionary can help improve efficiency by
reducing the time and effort required to define, document, and manage
data elements and attributes.
Disadvantages of Data Dictionary
• Implementation and Maintenance Costs: Implementing and
maintaining a data dictionary can be costly, requiring significant
resources in terms of time, money, and personnel.
• Complexity: A data dictionary can be complex and difficult to manage,
particularly in large organizations with multiple systems and data
sources.
• Resistance to Change: Some stakeholders may be resistant to using a
data dictionary, either due to a lack of understanding or because they
prefer to use their own terminology or definitions.
• Data Security: A data dictionary can contain sensitive information, and
therefore, proper security measures must be in place to ensure that
unauthorized users do not access or modify the data.
• Data Governance: A data dictionary requires strong data governance
practices to ensure that data elements and attributes are managed
effectively and consistently across the organization.

Case study
Create a data dictionary of online bookstore (Book, Customer, Order, and
Order_Item) and their respective attributes in an online bookstore system. It
provides a clear overview of the data structure and relationships within the
system, facilitating development, maintenance, and usage.

• Book
– Attributes:
• Book_ID (Primary Key)

• Title
• Author
• Genre
• Price
• Publication_Year
• ISBN
• Description
• Customer
– Attributes:
• Customer_ID (Primary Key)
• Name
• Email
• Address
• Phone_Number
• Order
– Attributes:
• Order_ID (Primary Key)
• Customer_ID (Foreign Key)
• Date
• Total_Amount
• Order_Item
– Attributes:
• Order_Item_ID (Primary Key)
• Order_ID (Foreign Key)
• Book_ID (Foreign Key)
• Quantity
• Subtotal

Advantage
Advantage:
• Define data items unambiguously.
• Valuable reference in any organization because it provides
documentation.
• It is a good tool for different stakeholder to understand the
requirements and designs.
• It store the information of all data items that can link to all
phases of SDLC.
• It is an important step in building a database. Most of DBMS have
a data dictionary as a standard format.

05/17/2024 73
Unit 2
ER Diagram (CO2)
It is a detailed logical representation of data for an organization and

uses three main constructs.
• Entities
• Fundamental thing about which data may be maintained. Each
entity has its own identity.
• Entity Type is the description of all entities to which a common
definition and common relationships and attributes apply.

05/17/2024 74
Unit 2
ER Diagram
It is a detailed logical representation of data for an organization and

uses three main constructs.
• Entities
• Fundamental thing about which data may be maintained. Each
entity has its own identity.
• Entity Type is the description of all entities to which a common
definition and common relationships and attributes apply.

ER Diagram
Relationships
• A relationship is a reason for associating two entity types. Binary
relationships involve two entity types
• A CUSTOMER is insured by a POLICY.
• Relationships are represented by diamond notation in a ER
diagram

05/17/2024 76
Unit 2
ER Diagram
Degree of relationship

05/17/2024 77
2
Decision Table(CO2)
• It is a tabular form that presents a set of conditions and their

corresponding actions.
• There four portion of decision table.
Condition Condition
Alternatives
Actions Actions Entries

05/17/2024 78
2
Decision Table
• 2-Dim. Matrix:
• Row1 : for each possible actions.
• Row2: for each relevant conditions.
• One column for each combination of condition states.
– Upper rows specify the variables or conditions to be evaluated
and lower rows specify the corresponding actions to be taken
when an evaluation test is satisfied
– A column in a decision table is called a rule. It implies if a
condition is true then execute the corresponding action.

05/17/2024 79
Unit 2
Decision Table

Decision Table for Triangle Problem

Requirement Documentation (CO2)
• The two scenario create entirely different situation and establish

entirely different purposes for the document.
• First case SRS is used to define the needs and expectations of the
user. Second case ,SRS is written for different purpose and serve as
a contract document between customer and developer.

SRS Document(CO2)
• Requirement document is called software requirement specification(SRS). The SRS

is a specification for a particular software product program or set of program that
perform certain functions in a specific environment. It serves a number of
purposes depending on who is writing it. First the SRS could be written by the
customer of a system. Second the SRS could be written developer of a system.

Table of Contents
Table of Contents i
Revision History iii
1. Introduction 1
1.1 Purpose 1
1.2 Product Scope 1
1.3 Glossary 1
1.4 References 1
1.5 Overview 1
2. General Description 2
2.1 Product Perspective 2
2.1.1 System interfaces 2
2.1.2 User interfaces 2
2.1.3 Hardware interfaces 2
2.1.4 Software interfaces 2
2.2 Product Functions3
2.2.1 Enterprise Requirements 3
2.3 User Characteristics - Jon 7
2.4 Constraints 8
2.5 Assumptions and Dependencies 8
2.6 Apportioning of Requirements - Jon8
3. Specific Requirements 9
3.1 External Interfaces 9
3.2 Functions 12
3.2.1 Use Case: 1 Respond To Meeting Invitation 12
3.2.2 Use Case: 2 Initiate a meeting 14
3.2.3 System Functional Requirements 16
3.2.4 Nonfunctional Requirements 20
3.2.5 Deleted Requirements 24
3.2.6 System Non-functional Requirements 25
3.2.7 Deleted Requirements 25
4. Requirements Analysis – Paul & Shaun 25
4.1 Analysis Team and Roles - Paul 25
4.2 Analysis Process 26
4.3 Dependency Analysis 26
4.3.1 Enterprise Requirements Analysis 26
4.3.2 System Functional Requirements Analysis 27
4.3.3 System Nonfunctional Requirements Analysis 28
4.4 Issues Raised to SynergySoft - Shaun 29
4.5 Original Requirements Delivered by SynergySoft 30
4.5.1 ORIGINAL Enterprise Requirements: Stakeholders, Functional and Non-Functional Objectives 1
4.5.2 ORIGINAL System Requirements: Functional Requirements 1
4.5.3 ORIGINAL System Non-Functional Requirements 2

Characteristics of SRS
• Complete: The SRS should include all the requirements for the software
system, including both functional and non-functional requirements.
• Consistent: The SRS should be consistent in its use of terminology and
formatting, and should be free of contradictions.
• Unambiguous: The SRS should be clear and specific, and should avoid using
vague or imprecise language.
• Traceable: The SRS should be traceable to other documents and artifacts, such
as use cases and user stories, to ensure that all requirements are being met.
• Verifiable: The SRS should be verifiable, which means that the requirements
can be tested and validated to ensure that they are being met.
• Modifiable: The SRS should be modifiable, so that it can be updated and
changed as the software development process progresses.
• Prioritized: The SRS should prioritize requirements, so that the most important
requirements are addressed first.

• Testable: The SRS should be written in a way that allows the
requirements to be tested and validated.
• High-level and low-level: The SRS should provide both high-level
requirements (such as overall system objectives) and low-level
requirements (such as detailed functional requirements).
• Relevant: The SRS should be relevant to the software system that is
being developed, and should not include unnecessary or irrelevant
information.
• Human-readable: The SRS should be written in a way that is easy for
non-technical stakeholders to understand and review.
• Aligned with business goals: The SRS should be aligned with the overall
business goals and objectives of the organization, so that the software
system meets the needs of the business.
• Agile methodologies: Agile methodologies, such as Scrum and Kanban,
provide an iterative approach to requirements capturing and validation,
where requirements are captured and validated in small chunks of
functionality and feedback is gathered from the customer.
Organization of the SRS (CO2)
• IEEE has published guidelines and standards to organize an SRS.

• First two sections are same. The specific tailoring occurs in
section-3.
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
1.5 Overview

Organization of the SRS
2. The Overall Description

2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements

2.2 Product Functions

2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements

3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
4. External Interface Requirements
5. Non functional Requirements

Requirement validation (CO2)
• After completion of SRS Check the document for

– Completeness & consistency
– Conformance to standards
– Requirements conflicts
– Technical errors
– Ambiguous requirements
• Objective of req. validation is to certify the SRS doc., Is an acceptable doc.
Of the system to be implemented.
• It find the error in doc. And improves the quality of s/w development
process.
• Analysis: work with raw requirement as collected from various
stakeholder
• Validation: work with a final draft of the SRS doc. With negotiated
and agreed requirements.

05/17/2024 91
Unit 2
Requirement Validation

05/17/2024 92
Unit 2
Requirement Review (CO2)
• Plan review: review team is selected, time and place is fixed for
review meeting.
• Distributed SRS doc: each member should read doc. To find conflict,
inconsistencies, deviations and other problems.
• Organize review meeting: each member present his/her view,
problem are discussed and action on them are approved.
• Follow-up actions: chairperson of team checks that approved action
have been carried out
• Revise SRS doc: SRS doc. Is revised to reflect the approved actions

05/17/2024 93
Unit 2
Requirement Review Process

Management of User Need
User Requirement Document (URD) :

• It is used in SE, That specify the req. the use expect from software.
• After URD customer can not demand extra feature similarly
developer cannot claim the product ready until it does not meet
URD.
• Types of requirements:
– Enduring requirements: They are core requirements & are
related to main activity of the organization. Example: in library
management. System issue/return of a book, cataloging etc.
– Volatile requirements: likely to change during software
development lifer cycle or after delivery of the product .
.

05/17/2024 95
Unit 2
Management of User Need
• Reason for change are:

• Change in environment.
• Change in Technology.
• Change in policies.
• Change in customer’s expectations.

05/17/2024 96
2
Requirements Management
It is the process of documenting, analyzing, tracing, prioritizing, and controlling

requirement requirements throughout the development lifecycle of a project.
• Requirements Management : Process of understanding and controlling
changes to system requirements.
• Requirement change Mgmt. process can be applied in three Stages:
• Problem Analysis and Change Specification : change request made
for partial problem then change specification are analyzed in order to
validate the req. change
• Change Analysis and Costing: estimate cost of change then take
decision to implement it or not.
• Change Implementation: when decide to change in req. Req doc. Is
re-written or re-organized.

05/17/2024 97
Unit 2
Verification and Validation(CO2)
• The purpose of V & V is to confirm system specification and to meet the

requirement of system customers.
• Verification: represent the set of activities that are carried out to confirm that
the s/w correctly implemented the specific functionality.(are we building the
product right?)
• It is the process of determining whether the output of one phase of software
development conforms to that of its previous phase. Thus verification is
concerned with phase containment of errors
• Validation: represent set of activities that ensure that the s/w that has been
build is satisfying the customer requirements.(are we building the right
product?)
• It is the process of determining whether a fully developed system conforms to
its requirements specification. the aim of validation is that the final product be
error free.

05/17/2024 98
Unit 2
Software Quality Assurance(CO2)
• SQA is a process ensuring software products meet quality standards and

requirements.
• It is a set of activities that are designed to evaluate the process by which s/w
developed and/or maintained.
• The aim of this process is to develop high quality s/w product.
SQA objectives
• Defect Prevention: To identify and prevent defects or issues in the software
development process before they occur.
• Process Improvement: To evaluate and enhance the software development
process to make it more efficient, reliable, and effective.
– It involves analyzing processes, identifying bottlenecks, and implementing
improvements to optimize the development lifecycle.
• Compliance: software development follows industry standards, regulations,
and guidelines.
– It aims to comply with various quality frameworks, such as ISO 9001 or
CMMI, to maintain consistency, reliability, and interoperability.

05/17/2024 99
Unit 2
Software Quality Assurance(CO2)
Verification and Validation: SQA focuses on verifying that software meets the
specified requirements and validating that it functions as intended. It involves
conducting reviews, inspections, and testing to ensure that the software performs
accurately and reliably.
Risk Mitigation: SQA aims to identify potential risks and vulnerabilities in the software
and mitigate them through proactive measures. By conducting risk assessments and
implementing appropriate controls, SQA helps to prevent issues that could lead to
software failure or security breaches.
Customer Satisfaction: SQA strives to meet or exceed customer expectations by
delivering high-quality software. By continuously monitoring and assessing software
quality, SQA ensures that the end product meets the needs of the users, leading to
increased customer satisfaction.
Continuous Improvement: SQA promotes a culture of continuous improvement within
the software development organization. It involves collecting feedback, analyzing
metrics, and learning from past experiences to refine processes and enhance the
overall quality of software products.

SQA Plan (CO2)
• It consists various tasks which carried out by two groups:

– Group1: consist of s/w Engineers who do technical work.
– Group2: it is SQA group. Responsible to prepare SQA plan,
record keeping, analysis and reporting. It assist s/w team in
achieving a high quality end product.
• SQA plan provides a road map for SQA.
• SQA plan identifies:
– evaluations to be performed
– audits and reviews to be performed
– standards that are applicable to the project
– procedures for error reporting and tracking
– documents to be produced by the SQA group
– amount of feedback provided to the software project team

05/17/2024 101
Unit 2
SQA plan is a three stage process
• Stage 1: SQA team should write in detail activities related for

s/w requirements.
• Stage2: team should analyze in detail the preparation of the

development team for detailed build-up.
• Stage3: tackles the QA plan for detailed design and actual

product.(it is longest among three phases)

05/17/2024 102
2
Capability Maturity Model(CO2)
• It is not a SDLC model.

• It is a strategy for improving the software process, irrespective of the
actual life cycle model used.
• It was developed by S/W Engg. Institute(SEI) of Carnegie-Mellon Univ.
in 1996.
• It is an assessment that results in a five point/level grading scheme

05/17/2024 103
Unit 2
Maturity Levels
• Initial (Maturity Level 1)

• The ad hoc software process development.
• Very Few or no processes are defined and followed.
• Success of project depends on individual effort.
• Totally depends on current staff. When developer leave org., successor
face great difficulty to understand the process.
• No formal project management practices are followed.
• It not possible to predict accurate time and cost of s/w product.
• Since software production processes are not limited, different engineers
follow their process and as a result, development efforts become chaotic.
Therefore, it is also called a chaotic level.
• Repeatable (Maturity Level 2)
• Basic project management process are established to track cost,
schedule, and functionality.
• The necessary process discipline is in place to repeat earlier success on
project with similar application but process is not documented.
• In similar project success story of development can be repeated for
05/17/2024 another. Dr. Poornima Tyagi Software Engineering ACSE0603
Unit 2
105
CMM
Defined (Maturity Level 3)

– the methods for both management and development activities are defined and
documented.
– common organization-wide understanding of operations, roles, and responsibilities.
– All project use an documented and approved version of the organization standard s/w
process for developing and maintaining s/w.
– But the process and practices are not analyzed quantitatively.
Managed (Maturity Level 4)
– Both the s/w process and product are quantitatively understood and controlled.
– It focus on s/w metrics:
Product metrics: measure the features of the product being developed, such
as its size, reliability, time complexity, understandability, etc.
Process metrics: The software process and product quality are measured, and
quantitative quality requirements for the product are met.
– such as average defect correction time, productivity, the average number of
defects found per hour inspection, the average number of failures detected
during testing per LOC,

05/17/2024 106
Unit 2
CMM
Optimizing (Maturity Level 5)

– At this phase, process and product metrics are collected.
Process and product measurement data are evaluated for continuous
process improvement.
– Continuous process improvement Is enabled by quantitative
feedback from the process and from introducing innovative ideas
and technologies.
– Organization Is committed to continuous process improvement.
So best s/w Engg. & mgmt . Practices are used throughout the organization.

05/17/2024 107
Unit 2
KPAs
CMM provides a series of key areas on which to focus to take an organization
from one level of maturity to the next. Thus, it provides a method for gradual
quality improvement over various stages.

ISO 9000 (CO2)
• ISO was published in 1987 as a set of six standards, ISO 8402, ISO
900-1, ISO 9001, ISO 9002, ISO 9003 and ISO 9004-1
• It is a consortium of 120 countries to formulate and bring up
standardization and published its 9000 series of standard in 1987.
• It specify the guidelines for maintaining of quality system.
• It focused both operational aspect(process) and organizational
aspects(responsibilities, reporting etc.).
• ISO-9000 series of standards is a set of document dealing with

quality systems that can be used for quality assurance purposes.
05/17/2024 109
Unit 2
ISO 9000 (CO2)
ISO-9000 Series: it comprises following standard

1. ISO 9001: This is the most widely known and comprehensive standard within the
ISO 9000 family. It specifies the requirements for a QMS that an organization must
demonstrate to achieve certification. ISO 9001 outlines various processes and
procedures that organizations must establish and maintain to ensure quality across
all aspects of their operations.
2. ISO 9000: This standard provides an overview of the fundamentals and vocabulary
used in quality management and certification. It helps organizations understand the
concepts and principles underlying ISO 9001 and other related standards.
3. ISO 9004: Unlike ISO 9001, which focuses on the requirements for certification,
ISO 9004 provides guidelines for enhancing performance and improving the
efficiency and effectiveness of a QMS. It offers organizations a broader perspective
on quality management and continuous improvement.

05/17/2024 111
2
Key Principles of ISO 9000
• Customer Focus: Organizations should understand and meet customer requirements

to enhance customer satisfaction.
• Leadership: Top management should provide leadership and establish a clear vision
and direction for the organization's quality objectives.
• Engagement of People: Employees at all levels should be engaged and empowered to
contribute to the organization's success.
• Process Approach: Organizations should adopt a process-based approach to achieve
consistency and effectiveness in their operations.
• Continuous Improvement: Continuous improvement should be a constant goal, with
processes regularly monitored and refined.
• Evidence-Based Decision Making: Decisions should be based on the analysis of data
and information to ensure effectiveness and efficiency.
• Relationship Management: Organizations should build and maintain mutually
beneficial relationships with suppliers and other relevant parties.

Benefits of Implementing ISO 9000
• Improved Quality: ISO 9000 helps organizations establish robust processes to

ensure consistent quality in products and services, leading to fewer defects and
customer complaints.
• Enhanced Customer Satisfaction: By meeting customer requirements and
delivering high-quality products and services, organizations can enhance
customer satisfaction and loyalty.
• Increased Efficiency: ISO 9000 encourages organizations to streamline processes
and eliminate waste, leading to improved efficiency and reduced costs.
• Market Access: ISO 9000 certification can open doors to new markets and
opportunities, as many customers and regulatory bodies require suppliers to be
ISO 9000 certified.
• Competitive Advantage: ISO 9000 certification can differentiate organizations
from competitors and serve as a marketing tool to attract customers who
prioritize quality and reliability.
• Better Risk Management: By adopting a systematic approach to quality
management, organizations can identify and mitigate risks more effectively,
minimizing potential negative impacts on their operations.
Reasons that Software industry get ISO certification
• It is a symbol of customer confidence.

• It highlights weakness and suggests correction measure for
improvement.
• It makes process more focused, efficient and cost effective.
• It is a motivating factor for business organization.
• It helps to designing high quality repeatable s/w product.
• It facilitates the development of optimal processes and total quality
measurement.
• It emphasizes the need of proper documents.

05/17/2024 114
2
Steps to get Certification
1. Evaluation of Existing Quality Procedures.
2. Initiating Corrective Actions : If the company (ISO Steering Team) finds deficiencies in the
existing quality procedures, then there is a need to correct such deficiencies. Corrective Action
may include investigating causes of non – conforming products and identifying corrective action
to prevent recurrence.
3. Preparation of Quality Assurance Programme : the strategies, procedures, and resources

necessary to ensure that products or services meet quality requirements.
4. Preparation of Quality Manual : is a document that outlines the organization's quality

management system, including its policies, objectives, procedures, and responsibilities.
5. Selection of Certification Agency : The company must select an agency to provide ISO 9001
certification. The company may select Bureau of Indian Standards (BIS) or a foreign accredited
agency.

Steps to get Certification
6. Pre – assessment Meeting :a pre-assessment meeting is held between the

company's ISO steering team and the certification agency. This meeting aims to
clarify expectations, discuss the audit process, and address any concerns or questions
regarding the certification process.
7. Preliminary Visit : certification agency may conduct a preliminary visit to the

company's facilities to familiarize themselves with the organization's operations,
processes, and QMS documentation.
8. Actual Assessment Visit: Auditors examine documentation, interview personnel, and

observe processes to evaluate the effectiveness and implementation of the QMS.
9. Certifications : If the company's QMS meets the requirements of ISO 9001 during the
assessment, the certification agency issues ISO 9001 certification.
10. Surveillance: the certification agency conducts regular surveillance audits to ensure
ongoing compliance with ISO 9001 standards. These audits verify that the company
continues to maintain and improve its QMS over time.
Faculty Video Links, Youtube & NPTEL Video Links and
Online Courses Details
• https://nptel.ac.in/courses/106/105/106105182/
• https://www.youtube.com/watch?v=crz9WmoUoKc
• https://www.youtube.com/watch?v=rKG7mgVFCTM
• https://www.youtube.com/watch?v=WjwEh15M5Rw

Daily Quiz
1) Which one is not a step of requirement engineering?

(a) Requirements elicitation (b) Requirements analysis
(c) Requirements design (d) Requirements documentation
2) Requirements elicitation means

(a) Gathering of requirements (b) Capturing of requirements
(c) Understanding of requirements (d) All of the above
3) SRS stands for

(a) Software requirements specification (b) System requirements specification
(c) Systematic requirements specifications (d) None of the above
4) SRS document is for

(a) “What” of a system? (b) How to design the system?
(c) Costing and scheduling of a system (d) System’s requirement.
5) Requirements review process is carried out to

(a) Spend time in requirements gathering (b) Improve the quality of SRS
(c) Document the requirements (d) None of the above
Daily Quiz
6) Which one is not a type of requirements?

(a) Known requirements (b) Unknown requirements
(c) Undreamt requirements (d) Complex requirements
7) Which one is not a requirements elicitation technique?

(a) Interviews (b) The use case approach
(c) FAST (d) Data flow diagram.
8) Context diagram explains

(a) The overview of the system (b) The internal view of the system
(c) The entities of the system (d) None of the above
9) Outcome of requirements specification phase is

(a) Design Document (b) SRS Document
(c) Test Document (d) None of the above
10) IEEE standard for SRS is:

(a) IEEE Standard 837-1998 (b) IEEE Standard 830-1998
(c) IEEE Standard 832-1998 (d) IEEE Standard 839-1998

MCQ
– Which one is not a step of requirement engineering?

a) Requirements elicitation
b) Requirements analysis
c) Requirements design
d) Requirements documentation
– SRS stands for
a) Software requirements specification
b) System requirements specification
c) Systematic requirements specifications
d) None of the above
– SRS document is for
a) “What” of a system?
b) How to design the system?
c) Costing and scheduling of a system
d) System’s requirement.

MCQ
– Context diagram explains

a. The overview of the system
b. The internal view of the system
c. The entities of the system
d. None of the above
– DFD stands for

• Data Flow design
• Descriptive functional design
• Data flow diagram
• None of the above

MCQ
– Which is one of the most important stakeholder from the following ?

a) Entry level personnel
b) Middle level stakeholder
c) Managers
d) Users of the software
– The SRS document is also known as _____________ specification.

a) black-box
b) white-box
c) grey-box
d) none of the mentioned

Glossary Questions
Requirement Engineering Process

Elicitation, Analysis, Documentation
Review and Management of User Needs
Feasibility Study
Information Modelling
Decision Tables
SRS Document
IEEE Standards for SRS

05/17/2024 123
2
Weekly Assignment
1. What do you mean by formal and informal review?

2. What is SRS?
3. What is the purpose of requirement document?
4. What do you mean by use case diagram? Prepare a use case diagram for student
result management system and explain it all use case using different parameter in
its template.
5. What is requirement engineering process? Explain all the methods of requirement
elicitation.
6. What do you mean by data flow diagram? Discuss higher level to low level DFD
with suitable diagram.
7. What is the requirement review process? Explain it with suitable diagram.
8. How the modularity effect on software cost? Explain with suitable diagram.
9. What do you mean by SRS? Give the structure of SRS in IEEE format
10. What do you mean by requirement review?

Old Question Papers

Old Question Papers(CO1)

Old Question Papers(CO1)

Expected Questions for University Exam
1. State any two problems that may associated during Requirement

Analysis.
2. What do you mean by umbrella of activities in Software Quality
assurance?
3. Prepare a ER diagram for hotel management system and specify all
attribute of entities.
4. What are the difference between validation and verification?
5. What do you mean by data dictionary and decision table? Explain with
an example.
6. What do you mean Software Quality Assurance?
7. What do you mean by ISO 9000 series?
8. What do you mean by SEI-CMM model? Explain its all level with suitable
diagram in details.

Summary
• Software Requirement Specifications (SRS)

• Requirement Engineering Process
• Elicitation, Analysis, Documentation
• Review and Management of User Needs
• Feasibility Study, Information Modeling
• Data Flow Diagrams
• Entity Relationship Diagrams
• Decision Tables
• SRS Document
• IEEE Standards for SRS
• Software Quality Assurance
• Verification and Validation
• SQA Plans
• Software Quality Frameworks
• ISO 9000 Models
• SEI-CMM Model

References
1. R. S. Pressman, Software Engineering: A Practitioners Approach, McGraw

Hill.
2. Rajib Mall, Fundamentals of Software Engineering, PHI Publication.
3. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age
International Publishers.
4. Pankaj Jalote, Software Engineering, Wiley
5. Deepak Jain,” Software Engineering: Principles and Practices”,Oxford
University Press.
6. Munesh C. Trivedi, Software Engineering, Khanna Publishing House
7. N.S. Gill, Software Engineering, Khanna Publishing House

Unit2 SE Updated

Uploaded by

Copyright:

Available Formats

Unit2 SE Updated

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit2 SE Updated

Uploaded by

Copyright:

Available Formats

Noida Institute of Engineering and Technology, Greater Noida

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2

Name of Faculty: Dr. Poornima Tyagi

Designation & Department: Assistant Professor, CSE Dept.

Qualification: MCA, MTech & PhD

Experience: Have 12 years experience of teaching subjects

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 2

Dr. Poornima Tyagi Software Engineering ACSE0603

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 4

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 5

• Software engineering applications are new idea, device or process.

05/17/2024 Dr. Poornima Tyagi Software Engine 6

• An understanding of software requirements and SRS document.

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 7

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

• PO1: Engineering Knowledge

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2

CO-PO Correlation Matrices

Correlation levels are taken 1, 2 and 3 as defined below:

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 10

On successful completion of graduation degree the Engineering

Dr. Poornima Tyagi Software Engineering ACSE0603

PEO1: To have an excellent scientific and engineering breadth so as to

Dr. Poornima Tyagi Software Engineering ACSE0603

Program Educational Objectives and Course Outcomes Mapping

CO PEO1 PEO2 PEO3 PEO4

*3= High *2= Medium *1=Low

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 13

Subject Result = 100%

Dr. Poornima Tyagi Software Engineering ACSE0603

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 16

05/17/2024 Dr. Poornima Tyagi Software Engine 17

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2

Stakeholder :. The term “stakeholder” in software engineering refers to people or

Dr. Poornima Tyagi Software Engineering ACSE0603

Dr. Poornima Tyagi Software Engineering ACSE0603

Known, unknown, undreamed requirements may be functional or non-

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

05/17/2024 Dr. Poornima Tyagi Software Engine 22

Functional Requirements Example:

Non-functional Requirements Example:

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

A University wish to develop a software system for the student result

Dr. Poornima Tyagi Software Engineering ACSE0603

• Requirements engineering (RE) refers to the process of defining,

It’s process consists four steps:

Dr. Poornima Tyagi Software Engineering ACSE0603

Dr. Poornima Tyagi Software Engineering ACSE0603 Unit

• It is most important goal of RE to find out what users really need.

Dr. Poornima Tyagi Software Engineering ACSE0603

3. Facilitated Application Specification Technique (FAST)

4. Quality Function Deployment.

5. The use Case Approach.

Dr. Poornima Tyagi Software Engineering ACSE0603

• Interviews maybe be open-ended or structured.

Dr. Poornima Tyagi Software Engineering ACSE0603

05/17/2024 Dr. Poornima Tyagi Software Engineering ACSE0603 Unit 2 32

3= High 2= Medium *1=Low