Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
16 views26 pages

Sre File Ap

Uploaded by

russojimpv04
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views26 pages

Sre File Ap

Uploaded by

russojimpv04
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

SWE501: Software Requirement Engineering

Lab Practical File

Submitted towards the partial fulfillment of the requirements of


the award of the degree of

Master of Technology
In
Software Engineering

Submitted by
ADITYA PANDEY
24/SWE/10
1st SEM, 1st YEAR

Submitted to
Dr. Abhilasha Sharma
Associate Professor
Department of Software Engineering

Delhi Technological University


(Formerly Delhi College of Engineering)
Bawana Road, New Delhi - 110042
2024
INDEX
S.No. Experiment Name P.No. Date Remarks
1 Write The Problem 1-3
Statement Of Video Library
Management System
2 4-6
Design Use Case Diagram
Of Video Library
Management System

3 7-12
Use Case Description for
Video Library Management
System

4 13-16
Draw Data Flow
Diagram (DFD) of the
given Video Library
Management System
5 17-18
Draw ER Diagram for the
Video Library Management
System

6 19-24
Design Software
Requirement Specification
according to IEEE standard
for the given case study
‭EXPERIMENT 1‬

‭AIM‬‭- Write The Problem Statement Of The Case Study‬

‭1. Theory‬
‭ he theory behind writing a problem statement involves understanding how a clear and precise‬
T
‭problem statement forms the foundation of a successful solution. Definition of a problem‬
‭statement: The problem statement is a concise description of the issues that need to be‬
‭addressed. It identifies the gap between the current state and the desired future state.‬
‭Characteristics of a good problem statement: Clarity: The statement should be free of ambiguity‬
‭and precisely define the problem. Stakeholder focus: It should address the needs and‬
‭challenges of all stakeholders involved in the hospital (patients, doctors, nurses, admin staff).‬
‭Scope: The problem statement should be neither too broad nor too narrow. Problem‬
‭Identification: Discuss how understanding the operational inefficiencies and patient care delays‬
‭in a hospital can lead to formulating a concrete problem. Linking to the solution: The problem‬
‭statement should naturally lead to a structured solution that can be implemented.‬

‭ ‬‭Video Library Management System (VLMS)‬‭is a software‬‭application designed to automate‬


A
‭and streamline the operations of a video library. Its primary goal is to efficiently manage video‬
‭inventory, customer data, rental transactions, and return processes. The system aims to replace‬
‭traditional manual methods of cataloging and managing videos, which often lead to‬
‭inefficiencies, data loss, and poor customer service.‬

I‭n a video library, keeping track of hundreds or thousands of videos, their availability, and their‬
‭rental status can be tedious. Customers may encounter difficulties locating desired videos or‬
‭face delays due to misplaced items. Meanwhile, librarians struggle to manage loan records, late‬
‭returns, fines, and inventory updates. A VLMS addresses these issues by providing an‬
‭organized platform where librarians can easily manage video rentals and returns, view the‬
‭status of each video in real time, and generate reports on library usage and inventory.‬

‭ ey features of a VLMS include a video catalog system, customer management, borrowing and‬
K
‭returning functionalities, notifications for overdue videos, and reporting tools for usage statistics.‬
‭It may also offer search and recommendation features to improve the customer experience.‬
‭2. Requirements‬

‭a) Functional Requirements‬

‭●‬ V ‭ ideo Inventory Management‬‭: A centralized database to store details of all videos‬
‭(e.g., title, genre, release date, availability).‬
‭●‬ ‭Customer Management‬‭: Keep track of registered users, their borrowing history, and‬
‭personal information.‬
‭●‬ ‭Borrow and Return Management‬‭: Automated process for borrowing videos, tracking‬
‭due dates, and returning items.‬
‭●‬ ‭Overdue Notifications‬‭: Send reminders to customers‬‭for overdue videos.‬
‭●‬ ‭Fines Calculation‬‭: Automatically calculate late fees‬‭based on overdue days.‬
‭●‬ ‭Search and Recommendation System‬‭: Allow customers‬‭to search for videos based on‬
‭genre, title, or actor and provide personalized recommendations.‬
‭●‬ ‭Report Generation‬‭: Provide detailed reports on video‬‭availability, borrowing statistics,‬
‭and customer activity.‬

‭b) Non-Functional Requirements‬

‭●‬ U ‭ sability‬‭: The system should be easy to use for both‬‭customers and staff, with intuitive‬
‭navigation.‬
‭●‬ ‭Scalability‬‭: The system should support the library’s‬‭growth, allowing more videos,‬
‭customers, and transactions to be added over time.‬
‭●‬ ‭Security‬‭: Ensure that customer data and video information‬‭are protected with‬
‭role-based access controls and encryption.‬
‭●‬ ‭Performance‬‭: The system should be fast and responsive,‬‭even during peak usage.‬
‭●‬ ‭Reliability‬‭: The system should operate consistently‬‭without downtime, ensuring‬
‭customers can access the service at any time.‬

‭3. Problem Statement‬

‭ he current management of video libraries using manual or semi-digital processes is inefficient,‬


T
‭prone to errors, and unable to keep pace with the increasing volume of videos and users. As‬
‭libraries expand their inventory, tracking the status of videos, managing customer data, and‬
‭handling returns and late fees becomes increasingly cumbersome. These challenges result in‬
‭inaccurate data, lost videos, poor customer service, and an inability to provide a seamless‬
‭experience to customers. Therefore, a modern Video Library Management System is required to‬
‭automate inventory tracking, manage customer accounts, streamline rental and return‬
‭processes, and offer additional services like overdue notifications and reporting. This system will‬
‭improve the overall efficiency of library operations and enhance the customer experience.‬
‭Key Problems to Address:‬
‭1.‬ ‭Video Inventory Management:‬
‭○‬ ‭Difficulty in tracking the availability of videos manually.‬
‭○‬ ‭Misplacement of items leading to delays for customers.‬
‭2.‬ ‭Customer Management Challenges:‬
‭○‬ ‭Lack of automated tracking of borrowing history and customer activity.‬
‭○‬ ‭Errors in updating customer information or loan records.‬
‭3.‬ ‭Rental and Return Process Inefficiencies:‬
‭○‬ ‭Manual tracking of due dates increases the chances of overdue returns.‬
‭○‬ ‭Complexity in calculating fines for late returns.‬
‭4.‬ ‭Communication and Notifications:‬
‭○‬ ‭No proper mechanism to send reminders for overdue items.‬
‭○‬ ‭Lack of personalized recommendations or notifications to customers.‬
‭5.‬ ‭Reporting and Analytics:‬
‭○‬ ‭No system to generate reports on inventory status, customer behavior, or library‬
‭usage.‬
‭○‬ ‭Administrative staff face challenges in keeping data consistent and accurate.‬

‭Conclusion‬
‭ he problem statement was developed to highlight the challenges of managing video libraries‬
T
‭manually. The proposed‬‭Video Library Management System‬‭(VLMS)‬‭aims to automate‬
‭operations, reduce inefficiencies, and enhance the overall user experience. This system will‬
‭address the identified issues by providing features like inventory management, customer‬
‭tracking, overdue notifications, and reporting tools, ultimately leading to smoother operations‬
‭and improved service quality.‬
‭EXPERIMENT 2‬
‭AIM‬‭- Design Use Case Diagram Of The Case Study‬

‭Theory‬

‭Definition of a Use Case Diagram‬

‭ Use Case Diagram is a visual representation that shows how different actors (users or‬
A
‭external systems) interact with a system to achieve specific goals or sets of goals. It focuses on‬
‭the functional requirements of the system, identifying the different processes it supports and‬
‭how users engage with those processes.‬

‭Actors:‬

‭1.‬ U ‭ ser‬‭: Represents a library member who can perform‬‭various actions related to‬
‭accessing and interacting with videos.‬
‭2.‬ ‭Librarian‬‭: Represents a staff member responsible for‬‭managing the library's video‬
‭resources and generating reports.‬

‭Use Cases:‬

‭1.‬ ‭Log in‬


‭○‬ ‭Description‬‭: The User and Librarian log into the system‬‭to access their‬
‭respective functionalities. This use case ensures that only authorized users can‬
‭perform actions within the system.‬
‭2.‬ ‭Search Video‬
‭○‬ ‭Description‬‭: The User can search for videos by title,‬‭genre, or other criteria. This‬
‭functionality allows the User to find videos of interest in the library catalog.‬
‭3.‬ ‭Renting Video‬
‭○‬ ‭Description‬‭: The User can borrow a video from the‬‭library. This use case allows‬
‭Users to rent videos for a specified period and is linked to video availability.‬
‭4.‬ ‭Video Catalog‬
‭○‬ ‭Description‬‭: The User can browse the video catalog to see available videos.‬
‭This use case shows Users a list of all videos in the library, including details like‬
‭title, genre, and availability.‬
‭5.‬ ‭Feedback‬
‭○‬ ‭Description‬‭: The User can provide feedback on the videos or the library's‬
‭services. This use case allows Users to leave comments or suggestions for‬
‭improvement.‬
‭6.‬ ‭Comments‬
‭○‬ ‭Description‬‭: The User can comment on specific videos. This use case allows‬
‭Users to leave reviews or share their thoughts on a particular video with other‬
‭Users.‬
‭7.‬ ‭Video Upload‬
‭○‬ ‭Description‬‭: The Librarian can upload new videos to‬‭the library’s collection. This‬
‭use case allows the Librarian to add new video content for Users to access.‬
‭8.‬ ‭Video Update‬
‭○‬ ‭Description‬‭: The Librarian can update details of existing‬‭videos, such as title,‬
‭genre, or availability. This use case keeps the video information current and‬
‭accurate.‬
‭9.‬ ‭Video Delete‬
‭○‬ ‭Description‬‭: The Librarian can remove outdated or‬‭damaged videos from the‬
‭library catalog. This use case helps the Librarian maintain the quality of available‬
‭content.‬
‭10.‬‭Generate Report‬
‭○‬ ‭Description‬‭: The Librarian can generate reports about‬‭various aspects of the‬
‭library, such as user activity, rented videos, and overdue returns. This use case‬
‭helps the Librarian monitor and manage the library effectively.‬

‭Relationships:‬

‭1.‬ A ‭ ssociations‬‭: Each actor is connected to their respective‬‭use cases to indicate which‬
‭functionalities they can access.‬
‭2.‬ ‭Includes/Extends‬‭: Although not explicitly shown in‬‭the provided diagram, some‬
‭potential relationships could be:‬
‭○‬ ‭Include‬‭: "Log in" could be included in other actions,‬‭as it is a prerequisite for‬
‭accessing other functionalities.‬
‭○‬ ‭Extend‬‭: "Comments" could extend "Video Catalog," as‬‭Users may need to view‬
‭a video in the catalog before leaving a comment on it.‬

‭Requirements for Creating the Use Case Diagram‬

‭1.‬ S ‭ ystem Functionality Analysis‬‭: Determine the video‬‭library's functional needs,‬


‭including video management, member interactions, and reporting.‬
‭2.‬ ‭Stakeholder Identification‬‭: Identify the actors involved, such as members (users) and‬
‭librarians (administrators).‬
‭3.‬ ‭Use Case Tools‬‭: Utilize UML diagramming tools or drawing software to design the use‬
‭case diagram.‬
‭4.‬ ‭Research‬‭: Study existing use case diagrams of similar systems to understand common‬
‭design patterns and avoid potential errors.‬
‭EXPERIMENT 3‬
‭AIM‬‭- Use Case Description for Video Library Management‬
‭System‬

‭Theory‬

I‭n software engineering, use case descriptions help describe how a system responds to‬
‭interactions from external actors, detailing each scenario and providing step-by-step behavior‬
‭for achieving a specific goal. This textual representation of a use case defines the interactions‬
‭between an actor and the system, showing how the system will respond to the user’s actions.‬

‭ efinition of a Use Case Description‬‭: A use case description‬‭is a structured narrative that‬
D
‭defines interactions between an actor and the system to achieve a specific goal. It describes‬
‭how the system will behave in response to various user actions.‬

‭1) Purpose of a Use Case Description:‬

‭●‬ D ‭ etailed Insight‬‭: It provides detailed information‬‭about system functionality, aiding‬


‭developers and stakeholders in understanding its operations.‬
‭●‬ ‭Guidance for Development‬‭: It serves as a foundation‬‭for further design, testing, and‬
‭implementation.‬
‭●‬ ‭Behavior Clarification‬‭: It helps outline the expected‬‭behavior of the system in different‬
‭scenarios, ensuring smooth interaction with users.‬

‭Components of a Use Case Description:‬

‭‬ U
● ‭ se Case Name‬‭: The title of the use case (e.g., "Borrow‬‭Video").‬
‭●‬ ‭Actors‬‭: External entities that interact with the system‬‭(e.g., Members, Librarians).‬
‭●‬ ‭Preconditions‬‭: The state of the system before the‬‭use case begins (e.g., the member‬
‭must be logged in).‬
‭●‬ ‭Basic Flow (Main Success Scenario)‬‭: A step-by-step outline of typical interaction,‬
‭describing how the actor achieves their goal.‬
‭●‬ ‭Alternative Flows‬‭: Variations in the interaction if certain conditions arise (e.g., if a video‬
‭is unavailable).‬
‭●‬ ‭Postconditions‬‭: The state of the system once the use case is successfully completed.‬
‭●‬ ‭Exceptions‬‭: Error conditions that could occur and how the system should handle them‬
‭(e.g., invalid input, system failure).‬
‭2) Benefits of Use Case Descriptions:‬

‭●‬ C ‭ larity‬‭: Provides a clear guide for developers and testers on system behavior in specific‬
‭situations.‬
‭●‬ ‭Error Handling‬‭: Identifies potential issues and outlines how the system should respond.‬
‭●‬ ‭Scenarios and Alternatives‬‭: Enhances system robustness‬‭by identifying not only the‬
‭main path but also alternative flows.‬

‭Requirements for Developing Use Case Descriptions:‬

‭●‬ U ‭ nderstanding of Use Case Diagrams‬‭: Develop a use‬‭case diagram first, identifying‬
‭key actors and their interactions with the system.‬
‭●‬ ‭System Knowledge‬‭: A thorough understanding of the‬‭Video Library Management‬
‭System, including user login, video borrowing, searching, uploading, and managing‬
‭accounts.‬
‭●‬ ‭Stakeholder Collaboration‬‭: Gather information from‬‭stakeholders (e.g., library‬
‭members, librarians) to ensure all possible flows and conditions are covered.‬
‭●‬ ‭Use Case Template‬‭: A structured template that defines‬‭the use case elements (name,‬
‭actors, preconditions, etc.).‬
‭●‬ ‭Documentation Tool‬‭: A tool like a text editor or project management software to‬
‭document and refine use case descriptions.‬

‭Use Cases Descriptions‬

‭Use Case Description for Log In‬


‭ escription‬‭: This use case manages the authentication‬‭of users, including members and‬
D
‭librarians, to access the system.‬

‭Actors‬‭: Member, Librarian‬

‭Preconditions‬‭:‬

‭‬ T
● ‭ he system is online and operational.‬
‭●‬ ‭The actor must have valid login credentials.‬
‭Basic Flow:‬

‭ .‬
1 ‭ he actor enters their username and password.‬
T
‭2.‬ ‭The system verifies the credentials.‬
‭3.‬ ‭If valid, the system grants access based on the actor's role.‬
‭4.‬ ‭The actor is directed to the main dashboard.‬

‭Alternative Flow:‬

‭●‬ ‭If the credentials are incorrect, the system displays an error and prompts for re-entry.‬

‭ xceptions:‬
E
‭If the system is down, login will not be possible, and an error message will be displayed‬

‭Use Case Description fo‬‭r‬‭Search Video‬


‭Actors‬‭: Member, Librarian‬

‭Preconditions‬‭:‬

‭‬ T
● ‭ he system is online and operational.‬
‭●‬ ‭The actor must have valid login credentials.‬

‭Postconditions‬‭:‬

‭●‬ ‭The actor is successfully logged in and granted access based on their role.‬

‭Basic Flow‬‭:‬

‭ .‬
1 ‭ he actor enters their username and password.‬
T
‭2.‬ ‭The system verifies the credentials.‬
‭3.‬ ‭If valid, the system grants access based on the actor's role.‬
‭4.‬ ‭The actor is directed to the main dashboard.‬
‭Alternative Flow‬‭:‬

‭●‬ ‭If the credentials are incorrect, the system displays an error and prompts for re-entry.‬

‭Exceptions:‬

‭●‬ I‭f the system is down, login will not be possible, and an error message will be‬
‭displayed.‬

‭Use Case Description for‬‭Borrow Video‬


‭Description‬‭: This use case allows members to borrow‬‭a video from the library.‬

‭Actors‬‭: Member‬

‭Preconditions‬‭:‬

‭‬ T
● ‭ he member must be logged in.‬
‭●‬ ‭The member must have no outstanding overdue videos or fines.‬

‭Postconditions‬‭:‬

‭‬ T
● ‭ he video is marked as borrowed by the member.‬
‭●‬ ‭The member's borrowing record is updated.‬

‭Basic Flow‬‭:‬

‭ .‬
1 ‭ he member searches for and selects a video to borrow.‬
T
‭2.‬ ‭The system verifies the member’s eligibility to borrow.‬
‭3.‬ ‭The system updates the video’s status to "borrowed."‬
‭4.‬ ‭The borrowing details are saved in the member’s record.‬
‭5.‬ ‭A confirmation message is displayed to the member.‬
‭Alternative Flow‬‭:‬

‭●‬ I‭f the video is currently borrowed by another member, the system notifies the member‬
‭and may offer a reservation option.‬

‭Exceptions‬‭:‬

‭●‬ I‭f the member has overdue videos or fines, borrowing is denied, and a message is‬
‭displayed.‬

‭Use Case Description for‬‭Renew Video‬


‭Description‬‭: Allows members to extend the rental period‬‭of a borrowed video.‬

‭Actors‬‭: Member‬

‭Preconditions‬‭:‬

‭‬ T
● ‭ he member must be logged in.‬
‭●‬ ‭The video is currently borrowed by the member.‬

‭Postconditions‬‭:‬

‭●‬ ‭The video’s due date is extended.‬

‭Basic Flow‬‭:‬

‭ .‬
1 ‭ he member selects the video to renew.‬
T
‭2.‬ ‭The system checks the availability for renewal.‬
‭3.‬ ‭The system updates the due date for the video.‬
‭4.‬ ‭The member receives a renewal confirmation.‬

‭Alternative Flow‬‭:‬

‭●‬ ‭If the video has pending reservations, the renewal request may be denied.‬

‭Exceptions‬‭:‬

‭●‬ ‭If there is a system error during renewal, the action fails, and the member is notified.‬
‭Use Case Description for‬‭Generate Reports‬
‭ escription‬‭: Allows librarians to generate reports‬‭on library activities, such as video inventory‬
D
‭and overdue videos.‬

‭Actors‬‭: Librarian‬

‭Preconditions‬‭:‬

‭●‬ ‭The librarian must be logged in.‬

‭Postconditions‬‭:‬

‭●‬ ‭The report is generated and can be viewed or exported.‬

‭Basic Flow‬‭:‬

‭1.‬ T ‭ he librarian selects the type of report to generate (e.g., inventory, borrowing‬
‭statistics).‬
‭2.‬ ‭The system processes and compiles the requested data.‬
‭3.‬ ‭The report is generated and displayed to the librarian.‬
‭4.‬ ‭The librarian can print or export the report if needed.‬

‭Alternative Flow‬‭:‬

‭●‬ I‭f insufficient data is available for the selected report type, the system displays a‬
‭message indicating incomplete data.‬

‭●‬ ‭Exceptions‬‭:‬
‭○‬ ‭If the system encounters a processing error, report generation fails, and the‬
‭librarian is notified.‬

‭Conclusion‬
‭Use case description for each use case was made.‬
‭EXPERIMENT 4‬

‭AIM‬‭-‭D
‬ raw Data Flow Diagram (DFD) of the given case study‬

‭Theory:‬

‭The theory behind Data Flow Diagrams (DFDs) involves understanding how data moves‬
‭through a system, interacting with processes, data stores, and external entities. DFDs provide‬
‭a high-level visualization of how information is exchanged within a system.‬

‭Definition of a Data Flow Diagram:‬

‭A Data Flow Diagram (DFD) is a graphical representation that illustrates how data flows through a‬
‭system, showing where data comes from, how it is processed, and where it goes. DFDs are used to‬
‭model the system's functionality and the interactions between different components (processes, data‬
‭stores, and external entities).‬

‭Levels of DFDs:‬

‭●‬ ‭Level 0 DFD:‬


‭A high-level overview that shows the entire system as a single process with external entities‬
‭that provide inputs and receive outputs. It doesn’t go into detail about the system’s internal‬
‭processes.‬
‭●‬ ‭Level 1 DFD:‬
‭Breaks down the main process of the Level 0 DFD into sub-processes, showing how data is‬
‭processed at a more granular level.‬

‭Components of a Data Flow Diagram:‬

‭1.‬ ‭Processes:‬
‭Represent the functions or activities that transform data. In a Video Library Management‬
‭System, examples might include:‬
‭○‬ ‭"Register User"‬
‭○‬ ‭"Search Video"‬
‭○‬ ‭"Rent Video"‬
‭○‬ ‭"Add/Remove Video"‬
‭○‬ ‭"Generate Report"‬
‭2.‬ ‭Data Flows:‬
‭Arrows that show how data moves between processes, external entities, and data stores. For‬
‭example:‬
‭○‬ ‭"User Details" flows from the "Register User" process to the "User Database."‬
‭○‬ ‭"Video Information" flows from the "Add Video" process to the "Video Catalog."‬
‭3.‬ ‭Data Stores:‬
‭Represent where data is stored in the system, such as databases. In a Video Library‬
‭Management System, these could be:‬
‭○‬ ‭"User Database" (stores user details)‬
‭○‬ ‭"Video Catalog" (stores video information like title, genre, and availability)‬
‭○‬ ‭"Transaction Records" (stores rented videos and their due dates)‬
‭4.‬ ‭External Entities:‬
‭These are sources or destinations of data that interact with the system but are outside its‬
‭control. For example:‬
‭○‬ ‭Users (Members):‬‭Interact with the system to rent‬‭videos, search the catalog, and‬
‭provide feedback.‬
‭○‬ ‭Librarian (Admin):‬‭Manages the video catalog, adds‬‭or removes videos, and‬
‭generates reports.‬

‭Requirements:‬

‭●‬ ‭Understanding of the System’s Workflow:‬


‭Knowledge of how data moves through the video library system, from user registration to‬
‭video renting and managing transactions.‬
‭●‬ ‭Access to System Requirements:‬
‭Detailed requirements or specifications of the video library system that outline key processes‬
‭and interactions with data.‬
‭●‬ ‭Stakeholder Input:‬
‭Consultation with library staff and members to understand how the video library system is‬
‭used in real scenarios.‬
‭●‬ ‭DFD Tool:‬
‭A diagramming tool (like Microsoft Visio, Lucidchart, or any UML/DFD software) to create‬
‭and refine the data flow diagram.‬
‭●‬ ‭Process Identification:‬
‭Clearly define the core processes of the system, such as user registration, video catalog‬
‭management, video renting, and transaction tracking, to create an accurate DFD.‬

‭Level 0 Data Flow Daigarm‬


‭Level 1 Data Flow Daigarm‬
‭EXPERIMENT 5‬
‭AIM‬‭-‭D
‬ raw ER Diagram for the Video Library Management System‬

‭Theory:‬

‭ n Entity-Relationship (ER) Diagram is a graphical representation of the entities, attributes,‬


A
‭and relationships within a system. It is a fundamental tool used in database design to‬
‭visually model data and its interactions. In an ER diagram, entities represent real-world‬
‭objects or concepts, attributes define the properties of those entities, and relationships‬
‭depict the connections between entities. ER diagrams are essential for understanding how‬
‭different components of a system are interrelated and help in building a well-structured‬
‭database. They provide a clear blueprint for implementing a database system, ensuring‬
‭data integrity and efficient management.‬

‭Requirements:‬

‭ o draw an ER Diagram for a Video Library Management System, the following‬


T
‭requirements are needed:‬

‭●‬ U ‭ nderstanding of System Data: A thorough understanding of the entities involved in‬
‭the video library system and how they interact with each other.‬
‭●‬ ‭Consultation with Stakeholders: Interact with library staff and users to understand the‬
‭data needs of the system, ensuring all necessary entities are captured.‬
‭●‬ ‭Database Design Principles: Knowledge of how to structure a database efficiently,‬
‭ensuring proper normalization and minimizing redundancy.‬
‭●‬ ‭Diagramming Tools: Use of software tools such as Microsoft Visio, Lucidchart, or any‬
‭ERD design tool to create the diagram.‬
‭●‬ ‭Identification of Entities and Relationships: Carefully identify the key entities (such as‬
‭User, Video, Transaction) and their relationships, ensuring accuracy in cardina‬‭lity.‬

‭ER DIAGRAM‬

‭Entities:‬

‭1.‬ ‭User:‬‭Represents the members of the video library who rent videos.‬
‭○‬ ‭Attributes:‬
User_ID (Primary Key)‬
‭ Name‬
‭,‬‭ Email‬
‭,‬‭ Address‬
‭,‬‭ Membership Number‬
‭,‬‭ ‭,‬
Password‬

‭2.‬ ‭Video: Represents the videos in the library catalog.‬
‭○‬ ‭Attributes:‬
Video_ID (Primary Key)‬
‭ Title‬
‭,‬‭ Genre‬
‭,‬‭ Release Year‬
‭,‬‭ Director‬
‭,‬‭ ‭,‬
Availability Status‬
‭ Duration‬
‭,‬‭ Language‬
‭,‬‭
‭3.‬ ‭Transaction: Represents the rental transactions where a user rents a video.‬
‭○‬ ‭Attributes:‬
Transaction_ID (Primary Key)‬
‭ Rent Date‬
‭,‬‭ Return Date‬
‭,‬‭ User_ID‬
‭,‬‭
(Foreign Key)‬
‭ Video_ID (Foreign Key)‬
‭,‬‭ Status (Rented/Returned)‬
‭,‬‭
‭4.‬ L
‭ ibrarian: Represents the library staff who manage the video catalog and oversee‬
‭transactions.‬
‭○‬ ‭Attributes:‬
Librarian_ID (Primary Key)‬
‭ Name‬
‭,‬‭ Email‬
‭,‬‭ Phone Number‬
‭,‬‭ Password‬
‭,‬‭
‭EXPERIMENT 6‬
‭ IM‬‭:‬‭Design Software Requirement Specification according to‬
A
‭IEEE standard for the given case study‬

‭Theory‬
‭1). Introduction‬

‭ he Software Requirement Specification (SRS) is a comprehensive document that defines the‬


T
‭expected functionality, constraints, and interactions of a software system. The IEEE standard for‬
‭SRS (IEEE 830-1998, now ISO/IEC/IEEE 29148:2018) provides a framework for writing‬
‭high-quality, clear, and complete requirements for a software project.‬

‭2). Definition of an SRS‬

‭ detailed document that describes what the software system should do, its features, functions,‬
A
‭constraints, and interactions with users or external systems. The SRS serves as a contract‬
‭between the client (stakeholders) and the development team, ensuring that both parties have a‬
‭shared understanding of the system requirements.‬

‭3). Importance of an SRS‬

‭●‬ C ‭ larity and Communication‬‭: It provides clear communication‬‭of system expectations to‬
‭developers, testers, and stakeholders.‬
‭●‬ ‭Foundation for Development and Testing‬‭: The SRS is‬‭used to guide the design,‬
‭development, and validation of the system.‬
‭●‬ ‭Avoid Scope Creep‬‭: Helps prevent miscommunication‬‭or the addition of unplanned‬
‭features during the project lifecycle.‬

‭4) IEEE Standard Components of an SRS:‬

‭ ‬ I‭ntroduction‬‭: Explains the purpose, scope, and overview of the system.‬



‭●‬ ‭Overall Description‬‭: Provides an overview of the system, including its objectives, user‬
‭classes, and assumptions.‬
‭●‬ ‭Specific Requirements‬‭:‬
‭○‬ ‭Functional Requirements‬‭: Defines all functions that the system should provide.‬
‭For example, patient registration, appointment scheduling, and billing.‬
‭○‬ N ‭ on-Functional Requirements‬‭: Describes system qualities like performance,‬
‭security, usability, and maintainability.‬
‭○‬ ‭External Interfaces‬‭: Details how the system interacts with external systems‬
‭(such as payment gateways, insurance systems, or databases).‬
‭○‬ ‭System Features‬‭: Describes each feature in detail, including its purpose, inputs,‬
‭outputs, and how it interacts with other features.‬
‭○‬ ‭Constraints and Assumptions‬‭: Describes limitations on the design or‬
‭development, such as technology choices, budget constraints, or regulatory‬
‭compliance.‬

‭Requirements‬

‭●‬ U ‭ nderstanding of the System‬‭: Knowledge of the system's‬‭workflows, including patient‬


‭registration, appointment scheduling, medical record management, and billing‬
‭processes.‬
‭●‬ ‭Consultation with Stakeholders‬‭: Engage with hospital staff, doctors, and‬
‭administrators to gather complete functional and non-functional requirements.‬
‭●‬ ‭Knowledge of IEEE Standard (830-1998)‬‭: Familiarity with the IEEE standard for writing‬
‭software requirement specifications to ensure completeness and adherence to best‬
‭practices.‬
‭●‬ ‭Tool for Documenting the SRS‬‭: Use a text editor or project management tool to draft‬
‭the SRS in a clear, structured manner.‬
‭●‬ ‭System Requirements‬‭: Detailed understanding of both the functional (what the system‬
‭does) and non-functional requirements (how well the system performs).‬

‭SOFTWARE REQUIREMENT SPECIFICATION (SRS)‬

‭1.1 Purpose‬

‭ he purpose of this Software Requirements Specification (SRS) document is to provide a‬


T
‭comprehensive description of the‬‭Video Library Management‬‭System (VLMS)‬‭. This document‬
‭is intended for stakeholders, including project managers, developers, testers, and end-users, to‬
‭ensure a mutual understanding of the system's requirements and expectations.‬

‭1.2 Scope‬

‭ he‬‭Video Library Management System (VLMS)‬‭is designed to automate and manage the‬
T
‭various functions of a video library. The system will facilitate:‬
‭●‬ U ‭ ser Registration and Management‬‭: Allows library members to register, manage their‬
‭profiles, and track their rental history.‬
‭●‬ ‭Video Catalog Management‬‭: Supports the addition, updating, and removal of videos‬
‭from the catalog.‬
‭●‬ ‭Video Renting‬‭: Allows users to search and rent videos for a specified duration.‬
‭●‬ ‭Feedback and Ratings‬‭: Enables users to rate and provide‬‭feedback on rented videos.‬
‭●‬ ‭Report Generation‬‭: Provides reports on rented videos,‬‭overdue rentals, user activity,‬
‭and inventory.‬
‭●‬ ‭Librarian Management‬‭: Allows librarians to manage‬‭video inventory, users, and rental‬
‭transactions.‬
‭●‬ ‭Notifications‬‭: Sends reminders for overdue videos,‬‭rental confirmations, and other‬
‭notifications.‬

‭ he VLMS aims to enhance the efficiency, accuracy, and quality of video rental operations in a‬
T
‭library, ensuring a smooth user experience for both users and staff.‬

‭1.3 Definitions, Acronyms, and Abbreviations‬

‭‬
● ‭ LMS‬‭: Video Library Management System‬
V
‭●‬ ‭UI‬‭: User Interface‬
‭●‬ ‭DBMS‬‭: Database Management System‬
‭●‬ ‭API‬‭: Application Programming Interface‬
‭●‬ ‭SQL‬‭: Structured Query Language‬
‭●‬ ‭Admin‬‭: Administrator (Library staff responsible for‬‭managing the system)‬
‭●‬ ‭Librarian‬‭: Library staff member who manages video‬‭catalog and rentals‬
‭●‬ ‭User‬‭: Library member who rents videos from the catalog‬
‭●‬ ‭Rental‬‭: The transaction where a user borrows a video‬‭for a specified period‬
‭●‬ ‭Overdue‬‭: A rental that has passed its due return date‬‭without being returned‬
‭●‬ ‭Video‬‭: A movie or video content available in the library's‬‭catalog‬
‭●‬ ‭Feedback‬‭: User-provided ratings and comments on videos after rental‬

‭1.4 Overview‬
‭ Video Library Management System (VLMS) is a software application designed to streamline‬
A
‭the organization, cataloging, and tracking of a video collection. It is commonly used in video‬
‭rental stores, educational institutions, and by anyone managing a large library of films,‬
‭documentaries, educational videos, or other visual media. Here’s an overview of its core‬
‭features, benefits, and typical structure:‬

‭Key Features of a Video Library Management System‬

‭1.‬ ‭Cataloging and Metadata Management‬‭:‬


‭○‬ ‭Stores detailed information about each video (title, genre, director, actors,‬
‭release date, language, rating, description, etc.).‬
‭‬ A
○ ‭ llows custom tags, categorization, and keywords to make searching easier.‬
‭○‬ ‭Enables cataloging by physical location (if physical media is used), ensuring‬
‭efficient storage and retrieval.‬
‭2.‬ ‭Search and Retrieval‬‭:‬
‭○‬ ‭Offers advanced search options based on title, genre, director, actor, or custom‬
‭tags.‬
‭○‬ ‭Allows filtering by availability, language, rating, and other attributes.‬
‭○‬ ‭May support keyword-based searches within descriptions and metadata.‬
‭3.‬ ‭User Management and Access Control‬‭:‬
‭○‬ ‭Registers and manages user accounts with roles (e.g., admin, staff, members).‬
‭○‬ ‭Controls access to certain videos or sections based on user roles.‬
‭○‬ ‭Provides personal accounts for users, where they can reserve, borrow, and‬
‭review videos.‬
‭4.‬ ‭Rental and Return Tracking‬‭:‬
‭○‬ ‭Tracks which users have borrowed which videos, along with due dates.‬
‭○‬ ‭Issues reminders and notifications for upcoming due dates or overdue returns.‬
‭○‬ ‭Generates reports on borrowing history and trends.‬
‭5.‬ ‭Inventory Management‬‭:‬
‭○‬ ‭Monitors the number of copies for each video title and updates availability‬
‭accordingly.‬
‭○‬ ‭Tracks damaged, lost, or replaced videos.‬
‭○‬ ‭May also integrate with barcode scanners for faster cataloging and‬
‭check-out/check-in processes.‬
‭6.‬ ‭Reporting and Analytics‬‭:‬
‭○‬ ‭Provides insights into popular titles, frequent borrowers, most rented genres, etc.‬
‭○‬ ‭Generates financial reports (if rental fees are applied).‬
‭○‬ ‭Produces stock reports on available, borrowed, and missing videos.‬
‭7.‬ ‭Online and Mobile Access‬‭:‬
‭○‬ ‭Some systems offer online or mobile access, allowing users to browse, reserve,‬
‭and manage their accounts remotely.‬
‭○‬ ‭Integrates with digital media platforms to support streaming (if applicable) for‬
‭videos directly from the library.‬
‭8.‬ ‭Integration with Payment Systems‬‭:‬
‭○‬ ‭For rental stores, systems may integrate with payment processing for rentals, late‬
‭fees, and other charges.‬
‭○‬ ‭Tracks payment histories and outstanding balances for users.‬

‭Benefits of a Video Library Management System‬

‭●‬ E ‭ fficiency‬‭: Automates the organization and management‬‭of video collections, reducing‬
‭manual effort.‬
‭●‬ ‭Improved Accessibility‬‭: Users can quickly search and‬‭locate desired videos.‬
‭●‬ ‭Enhanced User Experience‬‭: Personalized recommendations, account management,‬
‭and easy access help improve user satisfaction.‬
‭●‬ R ‭ educed Loss and Damage‬‭: Tracks borrowing and return‬‭dates, reducing the risk of‬
‭lost or unaccounted videos.‬
‭●‬ ‭Data-Driven Insights‬‭: Reporting and analytics help‬‭understand user preferences,‬
‭inventory needs, and operational efficiency.‬

‭Technical Structure‬

‭1.‬ D ‭ atabase Layer‬‭: Stores data on videos, users, transactions,‬‭inventory, etc., typically‬
‭using a relational database like MySQL or PostgreSQL.‬
‭2.‬ ‭Application Layer‬‭: Contains business logic for operations‬‭like search,‬
‭check-in/check-out, and user authentication.‬
‭3.‬ ‭User Interface‬‭: Often includes web and mobile interfaces‬‭for ease of use. Admin and‬
‭user portals offer tailored functionality.‬
‭4.‬ ‭Integration APIs‬‭: Interfaces with external payment systems, barcode scanners, digital‬
‭media platforms, and possibly social media for recommendations or reviews.‬

‭Use Cases‬

‭Use Case Diagram‬


‭Security and Compliance Considerations‬

‭ ince such systems often handle personal user data and, in some cases, payment information,‬
S
‭it’s essential to ensure:‬

‭‬ D
● ‭ ata Encryption: For protecting sensitive data.‬
‭●‬ ‭Access Control: Limiting access based on user roles.‬
‭●‬ ‭Compliance: Adhering to relevant data protection laws (like GDPR if in the EU) for‬
‭handling user information.‬

‭Conclusion‬

‭The Software Requirement Specification Document was created.‬

You might also like