GITAAUTONOMOUS COLLEGE, BHUBANESWAR

(Affiliated to BPUT, Odisha)

Assignment 2

Subject Name: SOFTWARE ENGINEERING Dept: CSEAI

Name of Faculty: JAYANTA KUMAR MISHRA
Branch: CSEAI Semester: VI

Part I
01 Short Answer Type Questions (2 Marks) Module BL CO
1 Write the features of good software design. 2 1 2
A well-designed software system should have the following
characteristics:
1. Modularity – The system is divided into smaller,
manageable components.
2. Maintainability – Easy to update and modify without
affecting the whole system.
3. Scalability – Can handle growth in users, data, or
features.
4. Efficiency – Optimized use of system resources like
memory and processing power.
5. Reusability – Components can be reused in different
applications.
6. Security – Protects data and functions from
unauthorized access.
7. Simplicity – Easy to understand and implement

2 What do you mean by cohesion and coupling? 2 1 2

These are key concepts in software design that define how
modules interact:
1. Cohesion – Measures how closely related and
focused the functions within a module are.
o High cohesion is desirable, meaning the
module performs a single, well-defined task.
o Example: A login module that only handles
user authentication.
2. Coupling – Measures the dependency between
different modules.
o Low coupling is preferable, meaning
modules interact minimally.
o Example: A database module that interacts
with an API but does not rely on its internal
logic.
Good software design aims for high cohesion and low
 coupling for better maintainability and reusability.

3 What do you mean by high level and detailed design? 2 2 2

1. High-Level Design (HLD):
o Provides an overview of the system architecture.
o Defines major modules, components, and their
interactions.
o Uses block diagrams, data flow diagrams
(DFD), and system architecture diagrams.
o Example: A high-level design for an e-
commerce site might include modules like User
Management, Payment Processing, and Order
Management.
2. Detailed Design (Low-Level Design - LLD):
o Describes how each module or component
works internally.
o Includes algorithms, database schema, class
diagrams, and function definitions.
o Example: The detailed design of the payment
module would specify encryption methods, API
calls, and validation processes.
HLD gives an overview, while LLD provides in-depth
implementation details.
Part II
02 Focused – Short answer type Questions (4 Marks) Module BL CO
1(a) Discuss Object Oriented Analysis (OOA) and modeling in 2 1,2 2
detail.
Object-Oriented Analysis (OOA):
Object-Oriented Analysis (OOA) is a method of analyzing
a problem domain to develop a software system using
objects, which represent real-world entities. OOA focuses
on identifying objects, their attributes, and their
interactions in a system.
Key Steps in OOA:
1. Identifying Objects – Determine the main entities
(e.g., Student, Course, Teacher in a university
system).
2. Defining Attributes – Identify object properties
(e.g., Student has Name, Roll Number, and Course).
3. Establishing Relationships – Define how objects
interact (e.g., A Student enrolls in a Course).
4. Behavior Identification – Determine object actions
using methods/functions.
Object-Oriented Modeling (OOM):
Object-Oriented Modeling (OOM) represents the structure
and behavior of a system using object-oriented concepts.
The main models used in OOM include:
1. Class Diagram: Represents objects, attributes, and
relationships.
2. Use Case Diagram: Shows system interactions
with users (actors).
 3. Sequence Diagram: Describes object
communication in a sequence.
4. State Diagram: Represents object states and
transitions.
Example: In an ATM system, the objects could be User,
Account, ATM Machine, and actions like Withdraw
Money, Check Balance would be methods of these
objects.

(b) Describe the methods to transform the DFD model into structure 2 1 2
chart.
A Data Flow Diagram (DFD) represents the data flow within a
system, while a Structure Chart (SC) is a hierarchical
breakdown of the system's modules. The transformation process
involves the following steps:
Steps to Convert DFD to Structure Chart:
1. Identify Main Modules:
o Each process in DFD is mapped to a module in
the structure chart.
o Example: A process "Verify Login" in DFD
becomes a module VerifyLogin() in the
structure chart.
2. Define Submodules:
o Break down complex processes into
submodules for better modularity.
o Example: A process "Process Order" can be
split into Validate Order, Calculate Price, and
Update Inventory modules.
3. Determine Data Flow:
o Define how data passes between modules using
arrows and parameters.
o Example: The Login module passes a
username and password to the Authentication
module.
4. Establish Control Flow:
o Identify decision-making elements and map
them using conditional branches in the
structure chart.
o Example: A decision box for "Is Password
Correct?" leads to either Grant Access or
Show Error.
5. Refine and Optimize:
o Remove redundant modules and improve code
reusability.
o Ensure high cohesion and low coupling among
modules.
Example:
For a Library Management System, the DFD process "Issue
Book" would be transformed into a structure chart with modules
like:
 Check Book Availability()
 Validate User()
 Update Records()
 This structured approach makes the system modular,
maintainable, and efficient. 🚀

Part – III

03 Long Answer type Questions (10 Marks) Module BL CO

1 a) What is SRS? What are the different categories of user of 2 1,2 2
SRS? Explain the features of a good SRS document, bad
SRS document and its contents.

Definition of SRS
A Software Requirement Specification (SRS) is a formal
document that outlines the functional and non-functional
requirements of a software system. It serves as an
agreement between stakeholders, ensuring a clear
understanding of the project’s scope and requirements.

Categories of Users of SRS

Different stakeholders use the SRS document for various
purposes:
1. Customers/Clients – Understands the project scope
and expected functionality.
2. Project Managers – Plans and allocates resources
based on requirements.
3. Developers – Uses it as a blueprint to write code
and develop the system.
4. Testers/QA Team – Validates the system against
specified requirements.
5. Technical Writers – Prepares user manuals based
on SRS specifications.
6. Designers – Uses the SRS to create system
architecture and UI/UX design.

Features of a Good SRS Document

A good SRS should have the following characteristics:
1. Correctness – Free from errors and ambiguities.
2. Completeness – Covers all functional and non-
functional requirements.
3. Consistency – No contradictions within the
document.
4. Unambiguous – Clearly defined requirements
without vague statements.
5. Verifiable – Each requirement must be testable.
6. Modifiable – Easy to update when requirements
change.
7. Traceability – Requirements should be linked to
their source.
8. Feasibility – The requirements should be realistic
and achievable.
Features of a Bad SRS Document
 A poorly written SRS can cause project failures due to:
1. Incomplete Requirements – Missing essential
features.
2. Ambiguous Statements – Unclear definitions
leading to misinterpretation.
3. Inconsistencies – Contradictory requirements.
4. Lack of Prioritization – No differentiation
between critical and optional features.
5. Unverifiable Requirements – Cannot be tested or
validated.

Contents of an SRS Document

A standard SRS document contains the following sections:
1. Introduction
o Purpose of the system
o Scope of the project
o Definitions and abbreviations
2. Overall Description
o System overview
o User characteristics
o Constraints
3. Functional Requirements
o Detailed description of system features
4. Non-Functional Requirements
o Performance, security, usability, reliability
5. External Interface Requirements
o UI, hardware, software, and communication
interfaces
6. Assumptions and Dependencies
o External factors affecting system behavior

b) Illustrate functional and non functional requirements in 2 1,2 2

Software Engineering.
1. Functional Requirements
Functional requirements define the features and
operations a system must perform. They describe what the
system should do in response to inputs.
Examples of Functional Requirements:
 User login authentication with username &
password.
 A banking system must process transactions
(withdrawals, deposits).
 An e-commerce website should allow users to add
items to the cart.
 A library system must track issued books and
return dates.

2. Non-Functional Requirements
Non-functional requirements define the quality attributes
of the system, focusing on how the system performs rather
 than what it does.
Examples of Non-Functional Requirements:
 Performance: The system should load within 2
seconds.
 Scalability: Must support 1 million users
concurrently.
 Security: Data should be encrypted using AES-
256.
 Usability: UI should be user-friendly and
accessible.
 Reliability: System uptime should be 99.9%.

Conclusion
 SRS is essential for defining project scope and
guiding development.
 Good SRS is clear, complete, and verifiable,
while a bad SRS can lead to misunderstandings
and project failure.
 Both functional and non-functional requirements
are crucial for a successful software system.

NB : BL – Blooms Level 1, 2, 3, CO – Course Outcome, PO – Program Outcome, PSO – Program Specific

Outcome