Project Name:

INTERACTIVE CHILDREN’S STORYBOOK WITH

ANIMATIONS

Software Requirements Specification

Course Code: INT220

Course Name: SERVER - SIDE SCRIPTING

Student Names:
ABHISHEK KUMAR
VIKHYAT SAINI
JIMI BHAGAT
GANESH KUMAR

Student Registration Numbers:

12308479
12322613
12314293
12317780

Prepared for
Continuous Assessment 3
Spring 2025
 Project Name

Table of Contents

REVISION HISTORY ............................................................................... ERROR! BOOKMARK NOT DEFINED.

1. INTRODUCTION ...................................................................................................................................................1
1.1 PURPOSE ..............................................................................................................................................................1
1.2 SCOPE ..................................................................................................................................................................1
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................................................................2
1.4 REFERENCES ........................................................................................................................................................3
1.5 OVERVIEW ...........................................................................................................................................................4
2. GENERAL DESCRIPTION ...................................................................................................................................7
2.1 PRODUCT PERSPECTIVE .......................................................................................................................................7
2.2 PRODUCT FUNCTIONS ..........................................................................................................................................7
2.3 USER CHARACTERISTICS .....................................................................................................................................8
2.4 GENERAL CONSTRAINTS ......................................................................................................................................9
2.5 ASSUMPTIONS AND DEPENDENCIES ................................................................................................................... 10
3. SPECIFIC REQUIREMENTS ............................................................................................................................. 11
3.1 EXTERNAL INTERFACE REQUIREMENTS ............................................................................................................. 14
3.1.1 User Interfaces ............................................................................................ Error! Bookmark not defined.
3.1.2 Hardware Interfaces ................................................................................... Error! Bookmark not defined.
3.1.3 Software Interfaces...................................................................................... Error! Bookmark not defined.
3.1.4 Communications Interfaces ......................................................................... Error! Bookmark not defined.
3.2 FUNCTIONAL REQUIREMENTS ............................................................................................................................ 14
3.2.1 <Functional Requirement or Feature #1> ............................................................................................... 15
3.2.2 <Functional Requirement or Feature #2> ............................................................................................... 16
3.5 NON-FUNCTIONAL REQUIREMENTS .....................................................................................................................3
3.5.1 Performance ................................................................................................................................................3
3.5.2 Reliability ....................................................................................................................................................3
3.5.3 Availability ..................................................................................................................................................3
3.5.4 Security .......................................................................................................................................................3
3.5.5 Maintainability ............................................................................................................................................3
3.5.6 Portability ...................................................................................................................................................3
3.7 DESIGN CONSTRAINTS .........................................................................................................................................3
3.9 OTHER REQUIREMENTS .......................................................................................................................................3
4. ANALYSIS MODELS ........................................................................................................................................... 19
4.1 DATA FLOW DIAGRAMS (DFD) ...........................................................................................................................4
5. GITHUB LINK…………………………………………………………………………………………………….5
6. DEPLOYED LINK………………………………………………………………………………………………...6
7. CLIENT APPROVAL PROOF……………..…………………………………………………………………….7
8. CLIENT LOCATION PROOF……………………………………………………………………………………8
9. TRANSACTION ID PROOF……………………………………………………………………………………...9
10. EMAIL ACKNOWLEDGEMENT…………………………………………………………………………….10
11. GST No…………………………………………………………………………………………………………...11
A. APPENDICES ...........................................................................................................................................................
A.1 APPENDIX 1...........................................................................................................................................................
A.2 APPENDIX 2...........................................................................................................................................................

Software Requirements Specification Page ii

 Project Name

1. Introduction
This Software Requirements Specification (SRS) document provides a structured and detailed
overview of the StoryLand system — a web-based platform designed to enable users to read,
write, and share stories. This document outlines all technical and functional details required for
software engineers to design, develop, and implement the application efficiently.

The objective of this document is to clearly define the scope, features, constraints, interfaces, and
expectations associated with the StoryLand system. It is intended for use by developers, testers,
project managers, and other stakeholders involved in the development process. The content of
this SRS is structured in accordance with the IEEE Guide to Software Requirements
Specifications (IEEE Std 830-1998).

StoryLand aims to create an engaging, accessible, and intuitive platform for writers and readers.
It includes modules for user authentication, story posting, reading progress tracking, story
interactions such as likes, and newsletter subscriptions. Administrative users will be able to
manage story content and users through a dedicated dashboard.

This SRS contains all the necessary information to support the software engineering team in:

• Understanding the product’s goals and user expectations,

• Identifying functional and non-functional requirements,

• Determining system architecture and interface design,

• Defining constraints and dependencies,

• Supporting testing, deployment, and maintenance planning.

The structure of this document ensures that every aspect of the StoryLand system is well-
documented, traceable, and ready for translation into a working, user-centered application.

1.1 Purpose

The purpose of this SRS is to define the requirements for StoryLand, an online platform for
reading, writing, and sharing stories. It outlines the system's functionality, performance, and
design constraints to guide the development team in building the application accurately.

Intended Audience:

• Developers – to understand what to build

Software Requirements Specification Page 1

 Project Name

• Testers – to verify functionality

• Project Managers – to plan and track progress

• Clients & Stakeholders – to review system goals

• End Users (Readers/Writers) – to know the intended features

• Admins – to manage content and users

This document serves as a common understanding for all involved in the project.

1.2 Scope
The software product to be developed is named StoryLand — a web-based platform that allows
users to read, write, and share stories. It includes key modules such as:

• User Authentication System

• Story Management Module

• Reading Progress Tracker

• Story Interaction (Likes)

• Newsletter Subscription

• Admin Dashboard for Content Moderation

What StoryLand Will Do:

• Allow users to create, edit, publish, and read stories online.

• Track user reading progress and display it on the dashboard.

• Enable users to like stories and subscribe to newsletters.

• Provide administrators tools to manage users and content.

• Offer categorized and searchable story listings.

What StoryLand Will Not Do:

• It will not support collaborative story writing in real-time (e.g., multiple users editing the
same story simultaneously).

• It does not include in-app messaging between users.

Software Requirements Specification Page 2

 Project Name

• It will not provide a mobile app version in the current scope (only responsive web).

Application and Goals:

StoryLand is designed to support individual creators and readers by offering a parameter-driven,
role-based platform for story sharing. The system aims to:

• Simplify content publishing for non-technical users.

• Allow story filtering by genre, reading level, or user interest.

• Ensure user-driven personalization like newsletter subscriptions.

• Provide near-instant updates to reading status and user dashboards.

• Maintain secure and moderated content through admin tools.

This scope aligns with the overall vision of delivering a creative and interactive digital reading
environment that empowers writers and engages readers through intuitive design and smart
functionality.

1.3 Definitions, Acronyms, and Abbreviations

This subsection provides definitions and explanations for the terms, acronyms, and abbreviations
used throughout this Software Requirements Specification (SRS) document to ensure clarity and
proper interpretation.

Term/Acronym Definition

Software Requirements Specification – a document that describes the software

SRS
system to be developed

UI User Interface – the part of the system with which users interact

DB Database – structured data storage for storing stories, users, likes, etc.

Hypertext Preprocessor – server-side scripting language used in backend

PHP
development

Structured Query Language – relational database system used to

MySQL
manage data

Software Requirements Specification Page 3

 Project Name

Term/Acronym Definition

HTML HyperText Markup Language – used to create web page structure

CSS Cascading Style Sheets – used for styling web pages

JS JavaScript – programming language for adding interactivity to web pages

Create, Read, Update, Delete – basic operations supported by StoryLand's story

CRUD
module

StoryLand Name of the software product – a platform to read, write, and share stories

A user who reads stories and interacts with them through likes and progress
Reader
tracking

Writer A user who creates and manages their own stories

Admin A system user with privileges to moderate content and manage users

1.4 References
1. ISO/IEC 12207:2017
Title: Systems and Software Engineering – Software Life Cycle Processes
Report Number: ISO/IEC 12207:2017
Date: 2017-10-01
Publisher: International Organization for Standardization (ISO)
Available at: www.iso.org

2. IEEE 830-1998
Title: IEEE Recommended Practice for Software Requirements Specifications
Report Number: IEEE Std 830-1998
Date: 1998
Publisher: Institute of Electrical and Electronics Engineers (IEEE)
Available at: www.ieee.org

3. User Authentication Design Document

Title: User Authentication for StoryLand Platform
Report Number: StoryLand-UA-Doc
Date: 2025-04-10

Software Requirements Specification Page 4

 Project Name

Publisher: StoryLand Development Team

Available at: StoryLand Internal Wiki

4. MySQL Documentation
Title: MySQL Reference Manual
Report Number: N/A
Date: Ongoing updates
Publisher: Oracle Corporation
Available at: dev.mysql.com

5. PHP Documentation
Title: PHP Manual
Report Number: N/A
Date: Ongoing updates
Publisher: The PHP Group
Available at: php.net

1.5 Overview
Your SRS (Software Requirements Specification) outline for the StoryLand platform looks well-
organized. Here's a breakdown with a little more detail for each section:
1. Introduction: Purpose, Scope, and Assumptions
o Purpose: Define the goals of StoryLand, focusing on what the platform aims to
achieve (e.g., providing a space for users to share stories).
o Scope: Mention the features and services included in the platform (e.g., story
creation, user authentication, admin moderation) and what’s excluded (e.g.,
advanced AI functionalities for now).
o Assumptions: State any assumptions made during the project (e.g., users have
internet access, the platform supports modern browsers).
2. Overall Description: High-level System Overview
o Provide an overview of the system architecture and how the platform works at a
high level. For instance, the front end (HTML/CSS/JavaScript) interacts with the
back end (PHP), which connects to the MySQL database for user data and story
storage.
3. System Features: Functional Requirements
o Break down each feature in detail, for example:
▪ Story Creation: Users can write and submit stories, with options to save
drafts.
▪ User Authentication: Users can sign up, log in, and manage their profiles.
▪ Story Liking/Tracking Progress: Users can like stories and track their
reading progress.
▪ Admin Moderation Tools: Admins can review stories, manage users, and
handle complaints.
4. External Interface Requirements: Interfaces with External Systems
o Detail how the platform interacts with external systems such as APIs (Gemini API
for fashion advice, for instance) or third-party services.

Software Requirements Specification Page 5

 Project Name

o Database Interface: Specify how PHP communicates with the MySQL database
for storing stories and user information.
5. System Attributes: Non-functional Requirements
o Performance: The platform should be responsive with a target page load time
(e.g., <2 seconds).
o Security: User data should be stored securely, and password hashes should be
used. Implement protection against SQL injection, XSS, etc.
o Scalability: The platform should be able to handle an increasing number of users
and stories over time.
6. Other Requirements: Legal or Regulatory Needs
o Mention any legal requirements, such as data privacy (e.g., GDPR compliance),
copyright concerns regarding user-generated content, and accessibility (e.g.,
WCAG compliance).
7. References: List of Referenced Documents
o Include any documents that informed the design of the system, such as project
specifications, external libraries, frameworks, and API documentation.
Let me know if you need more detail on any specific section!

Software Requirements Specification Page 6

 Project Name

2. General Description
This section provides an overview of the general factors that influence the StoryLand platform
and its requirements. It does not include specific requirements but helps to understand the
context in which those requirements are defined.

Key factors affecting the product include:

1. User Demographics: StoryLand targets a broad audience of readers and writers, including
people of various age groups and interests in storytelling, which influences user interface
design and feature prioritization.

2. Platform Environment: The platform is web-based, designed to run efficiently across

modern browsers, ensuring accessibility on desktops and mobile devices.

3. Performance Constraints: The platform must handle large volumes of users and stories,
ensuring fast load times, efficient data processing, and seamless user interaction,
especially during peak usage.

4. Security Requirements: User data protection is a priority, requiring secure authentication,

data encryption, and compliance with privacy regulations.

5. User Interaction: Users interact with the platform by creating stories, liking, commenting,
and tracking reading progress. These actions need to be intuitive, requiring a responsive
and accessible user interface.

6. Integration with External Systems: The platform interacts with external systems for tasks
such as user email subscriptions, moderation tools, and database management.

2.1 Product Perspective

The StoryLand platform is a web-based story-sharing website that allows users to read, write,
and share stories, providing features like story creation, user authentication, progress tracking,
and interaction through likes and comments. It is designed to offer an engaging, user-friendly
experience for both readers and writers.

Relation to Other Products:

• Social Media Platforms: Similar to platforms like Medium or Wattpad, StoryLand

provides a space for users to share stories, but with a unique focus on fostering a
community where users can track reading progress and interact with stories in more
personalized ways.

• Content Management Systems (CMS): Like traditional CMS tools (e.g., WordPress),
StoryLand allows for story creation and management, though it is more specialized for
storytelling rather than general content.

Software Requirements Specification Page 7

 Project Name

• Storytelling Platforms: StoryLand compares to other niche storytelling platforms but

distinguishes itself by incorporating both writer and reader-centric features, such as
tracking reading progress and admin moderation for story quality control.

Product Positioning:
StoryLand positions itself as a community-driven platform where users can not only share their
stories but also engage with a broad audience. Its core features differentiate it from general
blogging platforms by focusing on the storytelling experience, with functionalities like admin
moderation, liking stories, and tracking reading progress.

In comparison with other platforms, StoryLand is tailored to users who enjoy both the creation
and consumption of stories in a dynamic, interactive environment.

2.2 Product Functions

The StoryLand platform will perform the following key functions:

1. User Authentication:

o Users can create an account, log in, and manage their profile.

o Password recovery and email verification processes will be available.

2. Story Creation and Management:

o Users can write, edit, and publish their stories.

o Stories can be categorized, tagged, and saved as drafts.

o Admins can moderate stories to ensure content quality.

3. User Interaction:

o Readers can like and comment on stories.

o Users can track their reading progress on stories they are following.

4. Story Discovery and Search:

o Users can search for stories by category, tags, or keywords.

o A recommendation system may suggest stories based on user preferences.

5. Newsletter Subscription:

o Users can subscribe to newsletters to receive updates about new stories, events, or
platform news.

Software Requirements Specification Page 8

 Project Name

6. Admin Tools:

o Admins can manage user accounts, moderate content, and manage the platform’s
settings.

7. Notifications:

o Users will receive notifications for story updates, new comments, or interactions
on their stories.

2.3 User Characteristics

The StoryLand platform is designed for a diverse group of users, each with specific
characteristics that will influence the product's requirements. These user groups include readers,
writers, and administrators, each with different needs and expectations.

1. Readers

• Age Range: Typically 16-50 years, from a variety of backgrounds.

• Technical Skill Level: Generally moderate to low; most readers will expect an intuitive,
user-friendly interface without requiring technical knowledge.

• Preferences: Readers seek an engaging, easy-to-navigate platform with personalized

recommendations, story progress tracking, and interactive elements (like comments and
likes).

• Devices: Access the platform primarily via web browsers on desktops, laptops, and
mobile devices.

2. Writers

• Age Range: Typically 18-45 years, including both aspiring and established writers.

• Technical Skill Level: Moderate; writers need a simple but feature-rich editor for creating
and managing stories. Some technical knowledge may be required for advanced
formatting and use of story categorization features.

• Preferences: Writers look for tools that allow them to draft, edit, and publish stories
easily. They also value feedback and interaction with their audience (via comments, likes,
and ratings).

• Devices: Primarily use desktops or laptops for writing, but also access the platform
through mobile devices for updates and interactions.

3. Administrators

• Age Range: Typically 25-50 years, responsible for managing content and platform
operations.

Software Requirements Specification Page 9

 Project Name

• Technical Skill Level: High; administrators are expected to manage the system, moderate
content, and ensure platform security.

• Preferences: Admins require powerful moderation tools, including user account

management, content filtering, and data analytics for tracking platform usage and
performance.

• Devices: Access the platform through desktops and laptops for full administrative control
and content management.

4. General Considerations for All Users

• Access Needs: Users expect a responsive, mobile-friendly interface, fast load times, and a
secure experience, especially when logging in or submitting personal information.

• Language Skills: Users primarily communicate in English, with potential for other
languages based on region-specific features or future expansion.

• Accessibility: The platform must cater to users with disabilities, providing features like
screen reader support, keyboard navigation, and adjustable text sizes.

2.4 General Constraints

The StoryLand platform is subject to several general constraints that will influence the design
and development of the system. These constraints include technical, operational, and regulatory
limitations that the developers must consider.

1. Technology Stack

• The backend is implemented using PHP and MySQL, and the frontend utilizes
HTML/CSS/JavaScript. The system must be designed to be compatible with this stack,
limiting the use of certain technologies or frameworks that are not compatible with these
tools.

2. Performance Requirements

• The platform must handle a large number of concurrent users and interactions. This
imposes constraints on database design, caching, and load balancing to ensure fast
response times, especially during peak usage.

3. Security and Privacy

• The platform must comply with data privacy regulations, such as GDPR (General Data
Protection Regulation), especially with regard to user data collection, storage, and
handling. This includes enforcing strong encryption for user credentials, secure data
transmission, and user consent for data collection.

4. Cross-Browser Compatibility

Software Requirements Specification Page 10

 Project Name

• The platform must be compatible with all modern browsers (Chrome, Firefox, Safari,
Edge) and be responsive on both desktop and mobile devices. This ensures that users can
access the platform without restrictions regardless of their chosen browser or device.

5. Third-Party Integrations

• The platform may rely on third-party APIs or services, such as email services for
notifications and newsletters. These integrations may have their own limitations or usage
constraints, which the developers must work within.

6. Scalability

• As the platform grows, it must be scalable to accommodate increasing numbers of users,

stories, and interactions. This may require cloud hosting or distributed systems, which
will impose certain architectural constraints.

7. Time Constraints

• Development of the platform must be completed within the agreed-upon timeline, which
may limit the scope of initial features or the depth of testing and optimization during the
development phase.

8. Budgetary Constraints

• The project must adhere to the allocated budget, limiting the ability to implement certain
high-cost technologies or features that would require significant investment in
infrastructure or third-party services.

2.5 Assumptions and Dependencies

This subsection outlines the factors that affect the requirements of the StoryLand platform, which
are not design constraints but may influence the system’s development and functionality.
Changes to these factors could lead to modifications in the requirements.

Assumptions:

1. Availability of Web Servers and Hosting:

It is assumed that reliable web hosting services and cloud infrastructure will be available
for the platform, ensuring high uptime and scalability as the user base grows.

2. Modern Web Browsers:

The platform assumes that users will primarily access the website via modern web
browsers (Chrome, Firefox, Safari, Edge). If users primarily use outdated browsers, the
platform may need additional support for compatibility.

3. User Internet Connectivity:

The system assumes that users will have access to stable and reliable internet connections

Software Requirements Specification Page 11

 Project Name

for an optimal user experience. If this assumption proves false, certain features (like real-
time updates or story uploads) may be affected.

4. User Device Availability:

It is assumed that users will have access to devices (laptops, desktops, or mobile phones)
capable of running modern web browsers. If significant numbers of users are on devices
that cannot support these browsers, the system may need modifications for backward
compatibility.

5. Email Service Integration:

The platform assumes that third-party email services (for notifications, user registration,
and password recovery) will be available and reliable. If these services are unavailable or
unreliable, the email functionality of the platform may need to be adjusted or replaced.

6. User Data Privacy Compliance:

It is assumed that the platform will comply with data privacy regulations such as GDPR,
and that users will provide consent for data collection. If regulations change, adjustments
to data collection and storage policies may be required.

Dependencies:
1. Third-Party APIs and Services:
The platform depends on external APIs for features like user authentication (e.g., email
verification), email notifications, and possibly content moderation. Changes to these
third-party services could affect functionality.

2. PHP and MySQL Environment:

The platform depends on PHP for backend logic and MySQL for data storage. Any
changes or limitations in these technologies, such as version upgrades or compatibility
issues, could require updates to the system.

3. Internet Hosting and Cloud Infrastructure:

The platform depends on cloud services or web hosting providers for deployment. The
availability, performance, and scalability of these services are crucial for ensuring the
platform’s operational success.

4. Regulatory Changes:
Changes in legal or regulatory requirements related to data privacy, accessibility, or other
aspects could require the system to be adjusted to comply with new laws.

3. Specific Requirements
This section outlines the detailed requirements for StoryLand and provides the foundation for
design, implementation, and testing.
3.1 Functional Requirements
1. User Authentication
o Users can create accounts, log in, recover passwords, and log out.
o Priority: High

Software Requirements Specification Page 12

 Project Name

2. Story Creation and Management

o Users can create, edit, delete, and categorize stories.
o Admins can moderate content.
o Priority: High
3. Story Interaction
o Users can like, comment, and track reading progress.
o Priority: Medium
4. Search and Discovery
o Users can search stories by keywords and categories.
o Recommendations based on user preferences.
o Priority: Medium
5. Admin Tools
o Admins can manage users and delete inappropriate content.
o Priority: High
6. Newsletter Subscription
o Users can subscribe to newsletters for updates.
o Priority: Low
3.2 Non-Functional Requirements
1. Performance
o Support at least 1,000 concurrent users.
o Priority: High
2. Security
o Secure password storage and HTTPS for data transmission.
o Priority: High
3. Usability
o Responsive and user-friendly interface.
o Priority: Medium
4. Scalability
o Platform must scale with increasing users and content.
o Priority: High
5. Compliance
o Comply with GDPR and data protection regulations.
o Priority: High
3.3 External Interface Requirements
1. Email Service
o Integrate with email services for registration and notifications.
o Priority: High
2. Database
o Interface with a MySQL database for storing user data and content.
o Priority: High
3.4 System Attributes
1. Availability
o 99.9% uptime.
o Priority: High
2. Maintainability
o Code must be modular and maintainable.

Software Requirements Specification Page 13

 Project Name

3.1 External Interface Requirements

This section outlines the external interfaces that StoryLand will interact with, including user
interfaces, hardware, software, and communication interfaces.

3.1.1 User Interfaces

• Web Interface: The platform will provide a responsive web interface accessible via
modern web browsers (Chrome, Firefox, Safari, Edge). Users will interact with features
such as registration, login, story creation, and browsing through intuitive UI elements.

• Mobile Interface: The platform will be optimized for mobile devices, offering a user-
friendly experience for reading and interacting with stories on smartphones and tablets.

• Admin Interface: Admins will have access to a separate dashboard to manage users,
moderate content, and perform administrative tasks.

3.1.2 Hardware Interfaces

• Web Server: The platform will be hosted on cloud-based servers that provide adequate
resources to support user traffic and data storage.

• User Devices: The platform is accessible via devices like desktops, laptops, smartphones,
and tablets. Devices must support modern web browsers.

3.1.3 Software Interfaces

• Database: The platform will interact with a MySQL database for storing user
information, stories, and interactions. The database will be used for read/write operations
as required by the platform's functionality.

• Third-Party APIs: The platform will integrate with third-party services, such as email
providers for user registration and notifications (e.g., SMTP, SendGrid), and potentially
external content moderation services.

3.1.4 Communications Interfaces

• HTTP/HTTPS: The platform will use the HTTP/HTTPS protocol to handle
communication between the client (browser) and the server, ensuring secure data
transmission.

• Email Service: The platform will communicate with an external email service to send
user verification emails, password recovery instructions, and newsletter subscriptions.

These external interfaces define the key interaction points between StoryLand and its
environment, ensuring smooth communication, functionality, and scalability across different
platforms and services.

Software Requirements Specification Page 14

 Project Name

3.2 Functional Requirements

This section outlines the core functionalities and features that StoryLand must support. The
requirements describe how the system will interact with users and external systems, ensuring
that all necessary tasks are performed correctly.
3.2.1 User Authentication
• 3.2.1.1 Users must be able to create an account by providing a username, email, and
password.
• 3.2.1.2 Users must be able to log in using their registered email and password.
• 3.2.1.3 Users must be able to recover their password via email.
• 3.2.1.4 Users must be able to log out securely, ending their session.
3.2.2 Story Creation and Management
• 3.2.2.1 Users must be able to create, edit, and delete stories.
• 3.2.2.2 Users must categorize stories with tags and select appropriate categories (e.g.,
fiction, non-fiction).
• 3.2.2.3 Admin users must be able to moderate stories, approving or rejecting them for
public display.
3.2.3 Story Interaction
• 3.2.3.1 Users must be able to like stories and leave comments.
• 3.2.3.2 Users must be able to track their reading progress and resume reading where
they left off.
3.2.4 Search and Discovery
• 3.2.4.1 Users must be able to search for stories using keywords, tags, and categories.
• 3.2.4.2 The platform must recommend stories to users based on their reading history and
preferences.
3.2.5 Admin Tools
• 3.2.5.1 Admins must be able to view and manage user accounts (e.g., suspend, ban, or
delete users).
• 3.2.5.2 Admins must have the ability to delete inappropriate content (stories or
comments).
• 3.2.5.3 Admins must be able to approve or reject stories submitted by users.
3.2.6 Newsletter Subscription
• 3.2.6.1 Users must be able to subscribe to newsletters for updates on new stories and
platform news.
• 3.2.6.2 Users must be able to unsubscribe from newsletters at any time.
3.2.7 User Profile Management

Software Requirements Specification Page 15

 Project Name

• 3.2.7.1 Users must be able to view and edit their profile information (e.g., username,
email, profile picture).
• 3.2.7.2 Users must be able to view a list of their published stories and reading progress.
3.2.1 <Functional Requirement or Feature #1>
3.2.1 User Authentication
3.2.1.1 Introduction
The User Authentication feature allows users to create accounts, log in, recover their password,
and log out securely. This ensures that only authorized users can access personalized content and
interact with the platform's features.
3.2.1.2 Inputs
• Username: A unique identifier for the user, entered during account creation and login.
• Email: An email address used for registration and account recovery.
• Password: A secret password chosen by the user for securing their account.
• Recovery Email: The email address entered by the user to recover a forgotten password.
3.2.1.3 Processing
• Account Creation: When a user submits their username, email, and password, the system
will validate that the email is not already registered, hash the password securely, and
store the data in the database.
• Login: The system will verify the entered username and password by matching the
hashed password in the database. If the credentials match, the user is authenticated.
• Password Recovery: When a user requests a password reset, the system will generate a
password recovery link and send it to the user's registered email address.
• Logout: When the user logs out, the system will end the session by clearing any session
tokens or cookies.
3.2.1.4 Outputs
• Successful Account Creation: Confirmation message to the user that the account was
created successfully.
• Successful Login: Redirect the user to their personalized dashboard or home page.
• Password Recovery Email: A password recovery email containing a secure link to reset
the password.
• Logout Confirmation: A message confirming that the user has successfully logged out.
3.2.1.5 Error Handling
• Invalid Credentials: If the user enters incorrect login credentials, an error message will
inform them that the username or password is incorrect. The user can try again.
• Existing Email or Username: If the email or username is already registered, an error
message will prompt the user to choose another email or username.

Software Requirements Specification Page 16

 Project Name

• Password Recovery Failure: If the email entered for password recovery does not exist in
the system, an error message will notify the user that the email is not associated with an
account.
• Server Errors: In the case of server failures during account creation or login, a generic
error message will be displayed, and the user will be advised to try again later.

3.2.2 <Functional Requirement or Feature #2>

3.2.2.1 Introduction
This feature allows users to create, edit, delete, and categorize stories, while admins can
moderate content to ensure quality.
3.2.2.2 Inputs
• Story Title: The title of the story.
• Story Content: The text of the story.
• Categories/Tags: Descriptive tags or categories for the story.
• Editing Changes: Updates to an existing story.
3.2.2.3 Processing
• Create Story: Validates inputs and stores the story in the database.
• Edit Story: Updates the title or content and saves the changes.
• Delete Story: Removes the story from the database.
• Moderation (Admin Only): Admins approve or reject stories.
3.2.2.4 Outputs
• Story Confirmation: A message confirming creation, editing, or deletion.
• Moderation Status: Notification of approval or rejection.
• Updated Content: Reflects changes to stories after editing or deletion.
3.2.2.5 Error Handling
• Missing Fields: Prompts the user to fill in required fields.
• Unauthorized Deletion: Informs users if they cannot delete a story.
• Moderation Issues: Displays an error message if moderation fails.

Software Requirements Specification Page 17

 Project Name

3.5 Non-Functional Requirements

3.5.1 Performance

• 95% of user actions (e.g., story submission, liking) should be processed in under 1
second.

• The platform should support up to 1,000 concurrent users without performance

degradation.

3.5.2 Reliability

• The system should have a Mean Time Between Failures (MTBF) of at least 30 days.

• System failures should be recoverable within 5 minutes of detection.

3.5.3 Availability

• The platform must maintain 99.9% uptime, with no more than 1 hour of downtime per
month.

• Scheduled maintenance should not exceed 30 minutes per month.

3.5.4 Security

• All sensitive user data must be encrypted using industry-standard encryption methods.

• The system must undergo quarterly security audits and promptly address vulnerabilities.

3.5.5 Maintainability

• The system should be modular to allow easy updates and feature additions.

• Code should be written following best practices, with at least 80% test coverage.

3.5.6 Portability

• The application should be compatible with major browsers (Chrome, Firefox, Safari,
Edge).

• The system should be able to run on various devices, including desktops and mobile
phones, without major modifications.

3.7 Design Constraints

3.7.1 Standards

• The platform must adhere to the General Data Protection Regulation (GDPR) for user
data privacy and protection.

Software Requirements Specification Page 18

 Project Name

• The system should follow WCAG 2.1 accessibility standards to ensure the platform is
usable for people with disabilities.

3.7.2 Company Policies

• The platform’s UI/UX must align with the company’s branding guidelines, including
specific fonts, color schemes, and logos.

• All user data must be stored and processed in compliance with the company’s data
retention policy.

3.7.3 Hardware Limitations

• The system must be optimized to run on standard web hosting services, requiring no
specialized hardware or high-end server infrastructure.

• The platform must be responsive and perform well on devices with limited resources
(e.g., low RAM, older smartphones).

3.7.4 Technology Stack

• The system must be built using PHP for the backend, HTML/CSS/JavaScript for the
frontend, and MySQL for the database.

• The platform must integrate with third-party APIs for user authentication (e.g., Google
Login) and email notifications.

3.7.5 Security Requirements

• The system must implement SSL encryption for all data transmitted between users and
the server.

• Two-factor authentication (2FA) should be available for user accounts to enhance

security.

3.9 Other Requirements

3.9.1 Multilingual Support

• The platform must support at least two languages (English and Hindi) initially, with the
ability to add more languages in the future.

3.9.2 Integration with Social Media

• Users should be able to share their stories on social media platforms (e.g., Facebook,
Twitter, Instagram) directly from the platform.

3.9.3 Notification System

Software Requirements Specification Page 19

 Project Name

• The system should send email notifications for significant events such as new story
approvals, comments on a user's story, or newsletter subscriptions.

3.9.4 User Feedback System

• A user feedback system should be implemented, allowing users to submit suggestions or

report issues with the platform.

3.9.5 Data Backup

• Regular backups of the database must be performed daily to prevent data loss.

4. Analysis Models
4.1 Use Case Model

• Introduction: The Use Case Model describes the interactions between the users (primary
actors) and the system. It focuses on user roles and their goals, outlining the steps needed
to achieve those goals.

• Narrative Description: The primary actors for StoryLand include End Users, Authors, and
Admins. Use cases include actions like creating stories, liking stories, subscribing to
newsletters, and moderating content.

• Traceability to SRS: The use case model is directly linked to the Functional
Requirements section, such as the Story Creation and Management (3.2.2), User
Authentication (3.2.1), and Admin Moderation features (3.2.2).

4.2 Data Flow Diagram (DFD)

• Introduction: The Data Flow Diagram (DFD) illustrates how data moves through the
system, showing inputs, processing steps, and outputs.

• Narrative Description: The DFD highlights key processes, such as user login, story
creation, content moderation, and user interactions (likes, comments). Data flows
between the user interface, database, and backend processes.

• Traceability to SRS: The DFD corresponds to the system's Functional Requirements in

sections like User Authentication (3.2.1), Story Creation (3.2.2), and Admin Moderation
(3.2.2), ensuring that data handling follows the expected workflow.

4.3 Entity-Relationship Diagram (ERD)

• Introduction: The Entity-Relationship Diagram (ERD) defines the database schema,

showing entities like Users, Stories, Comments, and Likes.

Software Requirements Specification Page 20

 Project Name

• Narrative Description: The ERD identifies the relationships between entities, such as a
user having many stories, a story having many comments, and users liking stories. This
structure supports efficient database queries and interactions.

• Traceability to SRS: The ERD aligns with the Data Management section of the SRS,
especially the Database Requirements and User-Story Relationships (3.2.2).

4.4 State Diagram

• Introduction: The State Diagram represents the various states of a Story or User Account
throughout their lifecycle.

• Narrative Description: A story may go through various states such as Draft, Submitted,
Approved, or Rejected. Similarly, user accounts can transition between Active, Inactive,
and Suspended states based on actions like moderation or inactivity.

• Traceability to SRS: This model is linked to the Story Creation and Management (3.2.2)
and User Authentication (3.2.1) sections, specifying the expected states and transitions
within the system.

4.5 Class Diagram

• Introduction: The Class Diagram shows the main objects in the system, their attributes,
and the relationships between them. It is key for object-oriented design.

• Narrative Description: Key classes include User, Story, Comment, and Admin. Each
class has associated methods (e.g., create story, edit story, approve content) and attributes
(e.g., user ID, story content, comment text).

• Traceability to SRS: This diagram maps directly to functional requirements like Story
Creation (3.2.2), Admin Moderation (3.2.2), and User Interaction features (3.2.1).

4.1 Data Flow Diagrams (DFD)

Level 0:

Software Requirements Specification Page 21

 Project Name

Level 1:

Level 2:

Software Requirements Specification Page 22

 Project Name

6. Github Link: https://github.com/ganeshkr0201/storyLand

7. Social Media Video Presentation Link:

Roll No 15:
https://www.instagram.com/reel/DIwgtqzPB2f/?igsh=eTVvbDRmNW0y
ODh2

Roll No 16:
https://www.instagram.com/reel/DIwgtqzPB2f/?igsh=eTVvbDRmNW0y
ODh2

Roll No 17:
https://www.instagram.com/reel/DIwgtqzPB2f/?igsh=eTVvbDRmNW0y
ODh2

Roll No 31:
https://www.instagram.com/reel/DIwgtqzPB2f/?igsh=eTVvbDRmNW0y
ODh2

A. Appendices
Appendices may be used to provide additional (and hopefully helpful) information. If present,
the SRS explicitly states whether the information contained within an appendix is to be
considered part of the overall set of requirements.
A.1 Appendix 1
This appendix includes any initial conceptual documents or preliminary sketches that provide
background or high-level insights into the StoryLand project. It is not considered part of the
formal requirements but offers context for the software design.
A.2 Appendix 2
This appendix contains relevant marketing materials, including proposed branding concepts,
promotional strategies, and user engagement ideas for the StoryLand platform. These materials
serve as a guide for aligning the project with its intended audience but are not considered part of
the technical requirements of the SRS.

Software Requirements Specification Page 23