SOFTWARE ENGINEERING LAB

PRACTICAL FILE
(BCS651)

GL BAJAJ INSTITUTE OF TECHNOLOGY AND

MANAGEMENT, GREATER NOIDA

BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE AND ENGINEERING

Session: 2024-2025

SUBMITTED BY: SUBMITTED TO:

Name: Haneen Ajaz Ms.Palak Shandil

Section: 3C (Assistant Professor)
Semester: 6th
Roll No.: 2201920100128
Group: G1
 INDEX
Date of Date of Grades Faculty
S.No. Name of practicals Page No.
Practical Submission /Remark Signature

1. Prepare an SRS document in line with

the IEEE recommended standards.

2. Draw the use case diagram and specify

the role of each of the actors. Also
state the precondition, post condition
and function of each use case.
3. Draw the activity diagram.

4. Identify the classes. Classify them as

weak and strong classes and draw the
class diagram.
5. Draw the sequence diagram for any
two scenarios.

6. Draw the collaboration diagram.

7. Draw the state chart diagram.

8. Draw the component diagram

9. Perform forward engineering in java.

(Model to code conversion)

10. Perform reverse engineering in java.

(Code to Model conversion)

11. Draw the deployment diagram.

 EXPERIMENT 1

AIM: To develop a structured Software Requirements Specification (SRS) that defines the
functional and non-functional aspects of a software system, ensuring comprehensive documentation
for all stakeholders.

REQUIREMENTS:
 Understand what the system needs to do.
 Identify the system’s features and limitations.
 Define how well the system should perform.
 Make sure the system follows industry rules and best practices.

THEORY: A Software Requirements Specification (SRS) document is a critical element in

software engineering, serving as the foundation for system design, implementation, and validation.
It ensures that all stakeholders have a shared understanding of the software's purpose, functionality,
and constraints. By clearly defining requirements, the SRS reduces development risks, enhances
communication, and provides a basis for future modifications and maintenance. An effective SRS
improves software quality by addressing all technical, functional, and business aspects of the
system

1. INTRODUCTION
1.1 Purpose

The purpose of this Software Requirements Specification (SRS) document is to define the
requirements for the software system, ensuring a clear understanding among all stakeholders. .

1.2 Document Conventions

This document follows standard conventions, including:

 Functional requirements are prefixed as FR (e.g., FR-1, FR-2).

 Non-functional requirements are prefixed as NFR.
 Diagrams follow UML notation.
 Keywords such as MUST, SHOULD, and MAY indicate requirement priority.
1.3 Intended Audience and Reading Suggestions

Developers: To understand the system architecture and implementation.

Testers: To design test cases and verify functionality.

Project Managers: To track progress and ensure deliverables align with requirements.

1.4 Project Scope

The software system aims to (briefly describe the goal of the software, e.g., automate a process,
enhance user experience, integrate with an existing system, etc.). It will include features such as
(list key features, e.g., user authentication, data processing, analytics, reporting, etc.). The system
will be designed to be scalable, secure, and efficient.

1.5 References
 IEEE 830-1998: Software Requirements Specification Standard
 UML 2.0 for System Modeling (Include any books, articles, or relevant documentation)

2. Overall Description

2.1 Product Perspective

IEEE 830-1998: Software Requirements Specification Standard

UML 2.0 for System Modeling

2.2 Product Functions

The software provides the following core functionalities:

 User Management (registration, login, role-based access).

 Data Processing (collecting, storing, and retrieving information).
 Reporting & Analytics (visual representation of system insights).

2.3 User Characteristics The target users include:

 Administrators (full access, system configuration).

 End-users (limited access, ability to interact with features).
 (Other relevant user groups, such as support staff, managers, etc.). Users are expected to
have (basic/intermediate/advanced) technical expertise.
2.4 Constraints

The software must support (browser compatibility, platform restrictions, etc.).

 Response time should be (mention expected response times).
 Compliance with (GDPR, HIPAA, or other legal regulations).

2.5 Assumptions and Dependencies

 The system assumes a stable internet connection.

 It depends on third-party APIs, databases, cloud services.
 Users must have valid credentials for authentication.

3. Specific Requirements

3.1 Functional Requirements

Functional Requirements define the specific behaviours, operations, and actions that a software
system must perform to meet user needs. These requirements outline what the system should do,
including inputs, processes, and expected outputs.

 User-Centric – Focuses on how users interact with the system.

 Task-Oriented – Specifies operations the system should support.
 Well-Defined Inputs and Outputs – Clearly states expected results for given inputs.
 Preconditions and Post conditions – Describes the system state before and after a function
executes.
 Verifiable – Must be testable through functional testing.

Examples of Functional Requirements:

 User Authentication: The system must allow users to register and log in securely.
 Data Management: Users should be able to create, read, update, and delete (CRUD) records.
 Payment Processing: The system should integrate with payment gateways to process
transactions.
 Reporting: Generate reports based on user activity and data analytics.
3.2 External interface requirements: Define how the software system interacts with users,
hardware, and other software components. This section ensures compatibility, usability, and
efficiency across various interfaces.

3.2.1 User Interfaces: User interfaces describe how users interact with the system. The design
should focus on usability, responsiveness, and accessibility.

Key Requirements:

 Web-based UI: Developed using React.js for a responsive experience across devices.
 Mobile UI: Available for Android and iOS with a native-like experience.
 Dark Mode & Accessibility: Support for color-blind users, screen readers, and keyboard
navigation.

3.2.2 Hardware Interfaces

Hardware interfaces define how the software interacts with physical devices and hardware
components.

Key Requirements:

 Processor Compatibility: Supports Intel and AMD-based architectures.

 Memory Requirements: Minimum 4GB RAM, 2GHz CPU for smooth functioning.
 Storage Requirements: At least 50MB of disk space required for installation.

3.2.3 Software Interfaces

Software interfaces define the interaction between the system and external software, including
databases, APIs, and third-party integrations.

Key Requirements:

 Database Support: Compatible with MySQL, PostgreSQL, and MongoDB.

 Authentication Service: Uses Google Firebase or OAuth for secure login.
 API Integrations: RESTful APIs for data exchange with external systems.
 Operating System Compatibility: Supports Windows, macOS, and Linux for desktop users.
 Third-Party Tools: Integration with payment gateways, cloud storage services, and analytics
platforms.
3.3 Performance Requirements

Performance requirements define how efficiently the system should function under different
conditions. It ensures smooth user experience and system responsiveness.

Key Performance Metrics:

 Concurrent Users: The system must support 5,000 simultaneous users without lag.
 Response Time: Page loads should not exceed 2 seconds under normal conditions.
 Data Processing Speed: Queries should return results within 1 second for standard requests.

3.4 Design Constraints

Design constraints define the limitations and guidelines developers must follow during system
development.

Major Constraints:

 Technology Stack: The system must be built using React.js for the frontend and Node.js for
the backend.
 Database Compatibility: The system should work with MongoDB and MySQL.

3.5 Security Requirements

Security requirements define how the system protects user data and prevents unauthorized access.

Key Security Features:

 Data Encryption: All sensitive data must be AES-256 encrypted.

 Authentication: Support for multi-factor authentication (MFA).
 Role-Based Access Control (RBAC): Access must be restricted based on user roles.
 Secure Data Transmission: Use TLS 1.3 for encrypting communication.

3.6 Other Requirements

These requirements include additional system features that improve usability and compliance.

Additional Features:

 Multi-language Support: Users should be able to switch between languages.

 Automatic Backups: Data backups must occur every 24 hours.
 AI-powered analytics should offer predictive insights from user behaviour.
4. Appendices

This section contains additional materials that support the document, such as:

 Diagrams & Charts: Wireframes, system architecture diagrams, flowcharts.

 API Documentation: Details on third-party service integration.

5. Glossary

This section defines technical terms and acronyms used in the document:

 API (Application Programming Interface): A set of rules that allows different software
applications to communicate.
 RBAC (Role-Based Access Control): A security mechanism that restricts system access
based on user roles.
 TLS (Transport Layer Security): A protocol that ensures secure data transmission.
 GDPR (General Data Protection Regulation): A European regulation on data protection and
privacy.
 EXPERIMENT 2

AIM: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

REQUIREMENT: Ms Word Figures and shapes

THEORY: A Use Case Diagram is a behavioural diagram in UML (Unified Modelling Language)
that represents the interactions between users (actors) and a system. It provides a high-level view of
how a system works and what functionalities it provides.

Key Components of a Use Case Diagram

1. Actors:
1) External entities (users, systems, or devices) that interact with the system.
2) Represented as stick figures.
2. Use Cases:
1) Specific functionalities or tasks performed by the system.
2) Represented as ovals.
3. Relationships:
1) Association: Link between an actor and a use case (simple line).
2) Include: One use case includes another (dashed arrow with <<include>>).
3) Extend: A use case extends another in specific conditions(dashed arrow with
<<extend>>).

The given Use Case Diagram represents an Online Shopping System with five actors:

ACTORS AND THEIR ROLES:

1. Web Customer: A primary actor who interacts with the system via a web interface.

 Registered Customer → A sub-actor under Web Customer who browses and

purchases items.
 New Customer → A sub-actor under Web Customer registering in the system.

2. Service Authenticator: A secondary actor ensuring secure login and access control.
3. Identity Provider: A secondary actor responsible for managing authentication and user
identity.
4. Credit Payment Service: A secondary actor processing online transactions.
5. PayPal: A secondary actor facilitating payments as an external service provider.
This Use Case Diagram for an Online Shopping System illustrates how various users engage with
the system, highlighting each use case's preconditions, post conditions, and functions to ensure
seamless operation.
 EXPERIMENT 3

AIM: Draw an activity diagram.

REQUIREMENT: Ms Word Figures and shapes

THEORY: Activity diagrams visually represent the flow of control in a system, illustrating the
sequence of activities and their dependencies. They help in understanding whether actions occur
sequentially or concurrently and identify what triggers specific events.

 An activity diagram starts from an initial node and ends at a final node, highlighting
different decision points and possible paths.
 These diagrams are commonly used in business process modelling, software design, and
workflow automation to represent system behaviour over time.
 They include actions, decisions, forks, joins, and loops, making them useful for analysing
complex processes.

ACTIVITY DIAGRAM NOTATIONS (UML):

 Start Node – Represents the beginning of the activity, depicted as a filled black circle.
 Action/Activity (▭) – A task or process in the workflow, shown as a rounded rectangle (e.g.,
"Search for hotels").
 Decision Node (◇) – A diamond shape that indicates a decision point where the flow branches
based on conditions (e.g., "Is room available?").
 Arrow (➝) – Represents the flow of control between activities, directing the sequence of actions.
 Merge Node (◇) – Similar to a decision node but used to merge multiple alternate flows back
into one.
 Fork Node (──▮ ──) – A thick horizontal or vertical bar that splits a process into parallel tasks
(e.g., "Process Payment" and "Update Room Status" happening simultaneously).
 Join Node (──▮ ──) – The counterpart of a fork node, merging multiple parallel processes back
into a single flow.
 Swimlane – A sectioned area in the diagram that separates responsibilities, clarifying roles such
as "Customer", "System", or "Hotel Staff".
 End Node – Marks the conclusion of the process, shown as a filled black circle with an
outer border.
This figure below describes the Business process for meeting a new client using an activity
Diagram with Swimlane.

ACTORS (SWIMLANES):

1. Sales Person – Responsible for initiating contact with the client and setting up
appointments.
2. Consultant – Manages client interactions and prepares proposals.
3. Corporate Technician – Responsible for preparing the meeting environment.
KEY ELEMENTS IN THE DIAGRAM:

Start Node (Filled black circle)

 The process begins when the Sales Person calls the client to set up an appointment.

Actions/Activities (Rectangles):

1. Sales Person Actions:

 Call Client and Set-up Appointment – The Sales Person contacts the client to schedule a
meeting.
 Send Follow-up Letter – A follow-up letter is sent to the client after the appointment setup.

2. Consultant Actions:

 Prepare a Laptop – If the appointment is offsite, the Consultant prepares a laptop for the
meeting.
 Meet with the Client – The Consultant conducts the client meeting.
 Create Proposal – If a problem statement is identified during the meeting, the Consultant
drafts a proposal.
 Send Proposal to Client – The Consultant sends the prepared proposal to the client.

3. Corporate Technician Actions:

 Prepare a Conference Room – If the appointment is onsite, the Corporate Technician

prepares a conference room.

Flow (Arrows):

 The sequence of actions follows the decision points such as whether the appointment is
onsite or offsite.
 If there is no problem statement, the process ends after the follow-up letter.
 If a problem is identified, the proposal is created and sent to the client.

End Node (Filled black circle with a border)

 The process ends when the Consultant sends the proposal to the client.