Software Requirements

Specification

for

Newspaper Agency Automation

Version 1.0

Prepared by

Anmol Mangaraj 122CS0315

Sneha Burman 122CS0795

Pravanjan Swain 122cs0335

Mohammad Waris 122CS0575

Madireddy Anusha 122CS0555

Instructor: Prasenjit Dey

Course: Software Engineering Lab

Lab Section: S2

Date: 11/02/2025
Software Requirements Specification for Newspaper Agency Automation Page ii

Contents

Contents ........................................................................................................................................................ ii
Revisions ....................................................................................................................................................... ii
1 Introduction ............................................................................................................................................1
1.1 Document Purpose .......................................................................................................................1
1.2 Product Scope...............................................................................................................................1
1.3 Intended Audience and Document Overview ................................................................................1
1.4 Definitions, Acronyms and Abbreviations ......................................................................................2
1.5 Document Conventions .................................................................................................................2
1.6 References and Acknowledgments ...............................................................................................4
2 Overall Description .................................................................................................................................4
2.1 Product Overview ..........................................................................................................................4
2.2 Product Functionality .....................................................................................................................5
2.3 Design and Implementation Constraints ........................................................................................6
2.4 Assumptions and Dependencies ...................................................................................................7
3 Specific Requirements ........................................................................................................................... 9
3.1 External Interface Requirements ...................................................................................................9
3.1.1 User Interfaces ........................................................................................................................................................ 9
3.1.2 Hardware Interfaces ............................................................................................................................................... 9
3.1.3 Software Interfaces .............................................................................................................................................. 10
3.2 Functional Requirements ............................................................................................................ 10
3.3 Use Case Model.......................................................................................................................... 13
3.3.1 Actors ....................................................................................................................................................................13
3.3.2 Usecase-1. ............................................................................................................................................................ 14
3.3.3 Usecase-2. ............................................................................................................................................................ 14
3.3.4 Usecase-3… ......................................................................................................................................................... 15
3.3.5 Usecase Diagram.................................................................................................................................................. 16
4 Other Non-functional Requirements ..................................................................................................... 17
4.1 Performance Requirements ........................................................................................................ 17
4.2 Safety and Security Requirements .............................................................................................. 17
4.3 Software Quality Attributes .......................................................................................................... 17
4.3.1 Reliability .............................................................................................................................................................. 17
4.3.2 Maintainability ......................................................................................................................................................18
4.3.3 Usability ................................................................................................................................................................18
4.3.4 Scalability ............................................................................................................................................................ 18
Appendix A – Data Dictionary ....................................................................................................................... 19
Appendix B - Group Log ............................................................................................................................... 22
Software Requirements Specification for Newspaper Agency Automation Page iii

Revisions
Date
Version Primary Author(s) Description of Version
Completed
Initial draft of the SRS document, including functional
Draft 1.0 All Group Members 08/02/2025
and non-functional requirements.
Anmol Mangaraj , Updated external interface requirements and finalized data
Draft 1.1 09/02/2025
Pravanjan Swain dictionary (Appendix A).
Final Version Finalized SRS document after peer review and
All Group Members 11/02/2025
1.0 incorporated instructor feedback.
Software Requirements Specification for Newspaper Automation Page 1

Introduction
1.1 Document Purpose
This Software Requirements Specification (SRS) document outlines the detailed functional and non-
functional requirements for the Newspaper Agency Automation Software, version 1.0. The purpose
of this document is to serve as a comprehensive guide for developers, project managers, testers, and
other stakeholders involved in the creation and maintenance of the system. It specifies the expected
features, performance parameters, design constraints, and interfaces for the software, ensuring that
all parties have a common understanding of the system’s capabilities and limitations.
The scope of this SRS encompasses the entire functionality needed to support the operations of a
local newspaper and magazine delivery agency. This includes automated management of
subscription records, scheduling and route planning for delivery personnel, billing processes, and
compensation calculations for delivery staff. The document addresses both the managerial functions
required for overseeing operations and the operational functions needed by delivery personnel. It is
intended to guide the development of the system as a whole, while also highlighting interfaces with
other systems where applicable, thus ensuring a streamlined and efficient automation solution for
the agency’s clerical activities.

1.2 Product Scope

The Newspaper Agency Automation Software is designed to automate the day-to-day operations of
a local newspaper and magazine delivery agency. This software will manage a variety of clerical
activities, including subscription management, daily delivery scheduling, billing, and payment receipt
processing. By automating these processes, the system will help the agency minimize manual errors,
streamline operations, and improve overall efficiency. In addition, the system will facilitate optimized
route planning for delivery personnel by generating consecutive address lists to reduce
communication complexities and enhance delivery efficiency.

The implementation of this software is expected to bring significant benefits to the agency. These
benefits include enhanced operational accuracy, reduced administrative workload, and improved
customer service through timely subscription updates and billing management. The system will also
contribute to better financial accountability by automatically calculating monthly bills and computing
delivery personnel compensation based on delivery performance. Overall, the Newspaper Agency
Automation Software aims to provide a robust, user-friendly solution that supports the agency's
objectives of operational efficiency, customer satisfaction, and sustained business growth.

1.3 Intended Audience and Document Overview

This Software Requirements Specification (SRS) document is designed to serve a wide range of
stakeholders involved in the development and deployment of the Newspaper Agency Automation
Software. The primary audience includes software developers, project managers, testers, and quality
assurance engineers who will use the detailed requirements to drive the system's design,
implementation, and validation. In addition, the document is relevant to marketing personnel, end
users (such as the agency manager and delivery staff), system administrators, and technical support
teams. Documentation writers and training coordinators will also benefit from the structured details
provided throughout this document.
Software Requirements Specification for Newspaper Automation Page 2
The remainder of the SRS is organized into four main sections. Section 1: Introduction provides
the foundational context, including the document purpose, product scope, intended audience,
definitions, document conventions, and references. Section 2: Overall Description offers an
overview of the product, outlines its functionality, identifies design and implementation constraints,
and states assumptions and dependencies. Section 3: Specific Requirements details the external
interface and functional requirements, accompanied by the use case model to illustrate user
interactions. Section 4: Other Non-functional Requirements discusses the system’s performance,
safety, security, and overall software quality attributes.
For a systematic review, it is recommended that readers begin with Section 1 to understand the
context and purpose of the document. Project managers and developers should then focus on
Sections 2 and 3 for detailed functional and interface specifications, while testers may concentrate
on both the functional requirements and non-functional aspects outlined in Section 4. This
sequential approach ensures that all stakeholders can access the most pertinent information relevant
to their roles throughout the software development lifecycle.

1.4 Definitions, Acronyms and Abbreviations

The following is a list of the abbreviations and acronyms used in this SRS document, sorted in
alphabetical order:
• API: Application Programming Interface
• CRUD: Create, Read, Update, Delete
• DB: Database
• GUI: Graphical User Interface
• NPAS: Newspaper Agency Automation Software
• QA: Quality Assurance
• SRS: Software Requirements Specification
• UI: User Interface
• URL: Uniform Resource Locator
These definitions ensure that all stakeholders have a common understanding of the terminology
used throughout the document.

1.5 Document Conventions

This SRS document adheres to the IEEE formatting standards to ensure consistency, readability,
and ease of reference across all sections. The following conventions have been applied throughout:

• Formatting Conventions:
o The primary font used is Arial, with a consistent size of 11 or 12 points for all main
text.
o The document is single-spaced with 1-inch margins on all sides, ensuring a clean and
professional layout.
Software Requirements Specification for Newspaper Automation Page 3
o Section and subsection titles follow the hierarchical numbering system as specified in
the template (e.g., 1, 1.1, 1.2, etc.), providing clear structure and navigation.
o Italics are used for comments or supplementary explanations that are not part of the
main text, helping to distinguish additional insights from core content.

• Naming Conventions:
o Acronyms and abbreviations are defined in the “Definitions, Acronyms and
Abbreviations” section and are consistently capitalized throughout the document.
o Technical terms and identifiers (e.g., module names, function names) follow standard
naming conventions, with proper capitalization to enhance clarity and prevent
ambiguity.

• Highlighting and Emphasis:

o Bold formatting is used sparingly to highlight key terms and section headings.
o Italics indicate comments, suggestions, or clarifications that are not part of the
official requirements, ensuring that the primary content remains distinct and
authoritative.
By following these standards and typographical conventions, the document maintains a uniform
style that facilitates understanding and collaboration among all stakeholders.

1.6 References and Acknowledgments

The following documents, standards, and web resources have been referenced in the creation of this
SRS for the Newspaper Agency Automation Software (NPAS):

• IEEE Std 830-1998, "IEEE Recommended Practice for Software Requirements

Specifications" – This standard provides guidelines for the structure and content of the SRS
document.
• Company’s Internal Documentation Standards – Reference to internal style guides and
document templates provided by the organization.
• User Interface Style Guide – A comprehensive guide detailing the standard UI elements
and design practices, which influenced the UI design requirements specified in this
document.
• Project Vision and Scope Document – This document outlines the overarching goals,
business objectives, and high-level functionalities for the NPAS project.
• Contracts and Service Level Agreements (SLAs) – Relevant sections of contractual
agreements with the local newspaper agency, detailing performance expectations and service
requirements.
• Use Case Documents – Detailed use case specifications that have been utilized to inform
the functional requirements and interaction models within this SRS.
The authors acknowledge the contributions of the project stakeholders, domain experts, and
technical staff whose inputs have been invaluable in developing a comprehensive and accurate
requirements specification for the NPAS project.
Software Requirements Specification for Newspaper Automation Page 4

Overall Description
2.1 Product Overview
The Newspaper Agency Automation Software (NPAS) is a self-contained solution developed to
modernize and automate the operational processes of a local newspaper and magazine delivery
agency. Designed as a replacement for existing manual and semi-automated systems, NPAS
consolidates disparate functions such as subscription management, daily delivery scheduling,
billing, payment processing, and delivery personnel compensation into a unified platform. The
system is intended to enhance operational efficiency, minimize errors, and improve customer
service by automating routine clerical tasks and providing timely notifications to both agency
management and end users.
NPAS is a standalone product that also interfaces with external systems to extend its capabilities.
For instance, it integrates with external payment gateways for processing financial transactions,
leverages notification services (e.g., SMS or email) to communicate with customers, and accesses
external customer databases to ensure data consistency and seamless updates. The system is
designed to be modular, enabling future scalability and potential integration with additional external
services if required.
Below is a high-level diagram illustrating the major components of NPAS and its interactions with
the environment:
Software Requirements Specification for Newspaper Automation Page 5

Component Descriptions:
• Billing & Payment Module: Automates the generation of monthly bills, processes cheque
and cash payments, and interfaces with external payment gateways to handle financial
transactions.
• Customer Database & Notification Module: Maintains customer records, manages
subscriptions, and sends automated notifications such as payment receipts and overdue
reminders.
•
• Subscription & Delivery Scheduling Module: Organizes daily delivery schedules,
optimizes delivery routes by generating consecutive address lists, and allows customers to
modify their subscriptions.
• Reporting & Analytics Module: Provides the agency manager with comprehensive reports,
including delivery statistics, billing summaries, and performance metrics.
• User Interface (UI): Offers role-based access for both the agency manager and delivery
personnel, ensuring that each user has a tailored interface suited to their specific operational
needs.
This product overview establishes the context and functionality of NPAS within the operational
environment of the newspaper agency, emphasizing its role as an integrated system designed to
streamline business processes and support decision-making through comprehensive data reporting
and analysis.

2.2 Product Functionality

• Subscription Management:
Enable the management of customer subscriptions by allowing users to easily register new
subscriptions, update or modify existing subscription lists, and cancel subscriptions.
Customers must provide at least one week’s advance notice for any changes to ensure
smooth transition and planning.

• Daily Delivery Scheduling:

Automatically generate daily delivery lists tailored for each delivery person. This
functionality includes route optimization by arranging delivery addresses in consecutive
order, thereby reducing travel time and communication overhead during the delivery
process.

• Billing and Payment Processing:

Compute monthly bills automatically based on the types and quantities of publications
delivered. The system processes both cheque and cash payments, generates detailed
invoices, and issues receipts immediately upon the entry of payment information, ensuring
timely financial records and customer satisfaction.

• Notification and Alerts:

Software Requirements Specification for Newspaper Automation Page 6
Send automated notifications to customers and internal stakeholders. This includes
dispatching payment receipts upon confirmation of payment, issuing overdue payment
reminders for customers with outstanding dues, and alerting customers regarding any
temporary stoppages in delivery services.

• Reporting and Analytics:

Produce comprehensive reports and summaries for the agency manager, covering aspects
such as monthly billing details, delivery statistics, and overall financial performance. These
reports facilitate strategic decision-making and provide insights into operational efficiency
and revenue trends.

• Delivery Personnel Compensation Calculation:

Calculate the amount payable to each delivery person based on a predefined commission rate
(2.5%) of the total value of publications delivered. The system generates detailed payment
statements that ensure transparency and accurate compensation for the delivery staff.

2.3 Design and Implementation Constraints

The development of NPAS is subject to several constraints that will influence design choices
and implementation approaches. These constraints include:

• Hardware and Performance Limitations:

• The system must run efficiently on standard desktop and laptop computers that meet
the agency’s minimum hardware specifications.
• Performance requirements include timely processing of daily delivery scheduling,
billing computations, and report generation to ensure that all operational tasks are
completed within designated time frames.

• Interface and Integration Constraints:

• NPAS must interface with external systems, such as payment gateways for
processing transactions and third-party notification services (e.g., SMS and email)
for sending alerts and receipts.
• The system should be designed to accommodate integration with existing external
customer databases to ensure data consistency and seamless updates.

• Technologies, Tools, and Methodologies:

• The system design must follow the COMET method for software design, ensuring a
structured and systematic approach. (Reference: COMET Method Overview)
• Unified Modeling Language (UML) will be used for system modeling and
documentation, aiding in the clear visualization of system components and
interactions. (Reference: UML Guide)
Software Requirements Specification for Newspaper Automation Page 7
• Development will utilize approved programming languages and frameworks
specified by the agency’s IT department to maintain consistency with existing
systems.

• Security Considerations:
• All communications with external systems must use secure protocols (e.g., HTTPS)
to protect sensitive customer and financial data.
• The design must incorporate robust authentication and authorization mechanisms to
prevent unauthorized access.
• Data encryption and other security measures should be implemented to safeguard
stored information.

• Design Conventions and Programming Standards:

• The codebase must adhere to the agency’s internal coding standards and
documentation requirements, ensuring that the software is maintainable and
extendable.
• The modular design approach should be adopted to facilitate parallel development,
testing, and future scalability.
• Given that the agency’s organization will be responsible for maintaining the
delivered software, comprehensive documentation and adherence to standardized
design conventions are mandatory.

2.4 Assumptions and Dependencies

Assumptions

• The newspaper agency will provide complete and accurate customer subscription data.
• Customers will notify the agency at least one week in advance for any subscription
modifications or cancellations.
• Delivery personnel will have access to mobile devices or printed delivery schedules to
efficiently complete their deliveries.
• A stable and reliable network infrastructure will be available for smooth data
synchronization.
• The agency’s existing IT infrastructure, including hardware and software, will meet the
minimum system requirements for the system.
• Users, including agency managers and delivery personnel, will have the necessary computer
literacy to operate the system effectively.
• Customers will make payments on time, and the payment gateway services will remain
stable and functional.

Dependencies

• Third-Party APIs: The system will integrate with external APIs for payment processing
and notification services (SMS/email). Any disruption or modification in these APIs may
impact system functionality.
• Customer Database Integration: The system depends on external customer databases for
maintaining accurate subscription records and synchronizing data.
•
Software Requirements Specification for Newspaper Automation Page 8

• Software Development Standards: The design and implementation will follow the
COMET method for software engineering and utilize UML (Unified Modeling Language)
for system modeling and documentation.
• IT Support Availability: The system's deployment, maintenance, and troubleshooting
require ongoing support from the agency’s internal IT team.
• Technology Stack Constraints: Development will use approved programming languages,
tools, and frameworks that align with the agency’s IT policies and technical requirements.
Software Requirements Specification for Newspaper Automation Page 9

3 .Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
• The system should provide a graphical user interface (GUI) for the agency manager and
delivery personnel.
• The interface should allow users to manage subscriptions, track deliveries, process
payments, and generate reports.
• The GUI should be intuitive, supporting navigation menus, search functionality, and
form-based inputs.
Mock UI Concept:
(Insert a simple UI wireframe or describe the key interface elements, such as a dashboard with tabs
for subscriptions, billing, and reports.)

3.1.2 Hardware Interfaces

Server-Side Requirements:

Monitor Processor RAM Disk Space

Resolution Intel or AMD 512MB 2GB
1024*768 1GHZ

1. Receipt Printers
a. Must support basic thermal or inkjet printing with connectivity via USB or
network.

2. Barcode Scanners (Optional)

a. If integrated, delivery personnel can use barcode scanners to log deliveries and
confirm subscriptions.

3. Mobile Devices (Optional Future Scope)

a. Delivery personnel may access delivery schedules via mobile devices instead of
printed lists.

4. External Storage (USB Drives/Cloud Storage)

a. Used for data backup and exporting reports.

5. The system does not require specialized sensors, but it must be compatible with standard
input devices (keyboard, mouse, touchscreen) for ease of use.
Software Requirements Specification for Newspaper Automation Page 10

3.1.3 Software Interfaces

• OS (Windows)
• Java, HTML
• MySQL

Database Management System (DBMS)

• Stores customer information, subscription details, delivery schedules, and payment records.
• Supports MySQL/PostgreSQL for structured data storage and retrieval.
Payment Processing API
• Integrates with third-party payment gateways (e.g., Razorpay, PayPal, or local bank APIs)
to handle online transactions.
• Supports cash and cheque payment logging in the system.
Notification System (Email/SMS APIs)
• Sends payment confirmations, overdue reminders, and delivery updates to customers
via Twilio, Firebase, or SMTP email servers.

Report Generation Module

• Exports monthly reports in PDF, CSV, or Excel formats for agency records.
• Generates delivery summaries and financial reports for the manager.

3.2 Functional Requirements

F1: Manager/ Deliverer login

Function 1 Manager/ Deliverer login

Input Username, Password
Processing Check if there a exists a user in the database with the
entered credentials.
Output The user is directed to his main page if the entered
credentials are correct, else the system will ask the user
to enter his correct credentials
Software Requirements Specification for Newspaper Automation Page 11
F2:Add Publication

Function 2 Add Publication

Input Newspaper name, language, description, price
Processing A new record with the above details is inserted into the
database.
Output Notify the user whether the data is successfully inserted
or not.

F3:Edit Publication detail

Function 3 Edit Publication details

Input Newspaper name, language, description, price
Processing Modify the existing record with the above details.
Output Notify user about the update.

F4:Add customer

Function 4 Add customer

Input Customer name, address, phone, subscription
Processing A new record with the above details is inserted into the
database.
Output Notify the user whether the data is successfully inserted
or not.

F5:Edit Customer Details

Function 5 Edit customer details

Input Customer name, address, phone, subscription
Processing Modify the existing record with the above details.
Output Notify user about the update.

F6:Publications to be delivered

Function 6 Publications to be delivered

Input Customer address, Customer subscriptions, Deliverers
Software Requirements Specification for Newspaper Automation Page 12
Processing Each deliverer is assigned an address to which the
subscribed publication must be delivered. The addresses
are assigned such a way that the communication of
deliverer is minimal.
Output Print the publications to be delivered.

F7:Delivery summary

Function 7 Delivery summary

Input Customers, subscribed publications
Processing Check which publications the customers have received
for the whole month.
Output Print summary of the delivered publication details in a
month.

F8:Customer bills

Function 8 Customer bills

Input Customers, subscriptions, publications
Processing Calculate the total amount to be paid by the customer for
a month based on the type of publication and number of
publications received by a customer.
Output Print the bill for each customer which includes
publication type, the number of copies delivered in a
month and cost for these.

F9:With-Hold subscription

Function 9 With-Hold subscription

Input Customer id, Duration
Processing Add above details to database and stop deliveries to the
customer for specified duration.
Output Notify user about the update.
Software Requirements Specification for Newspaper Automation Page 13
F10:Payment receipt

Function 10 Payment receipt

Input Customer id, paid amount, cheque number
Processing Update database about the payment.
Output Print payment receipt of the customer.

F11:Deliverer payment

Function 11 Deliverer payment

Input Deliverers, deliveries made
Processing Calculate the amount a deliverer should receive by
adding 2.5% of the value of the publications delivered by
him.
Output Print the amount payable to each delivery boy.

3.3 Use Case Model

3.3.1 Actors:

1. Manager
• Manage News Agent

• Manage Delivery Agent

• Manage System

2. System User
• Give Advance Notice

• Print Information of the Current Month

• Print Publications for Each Delivery Boy

• Print Bills Every Month

• Automatically Calculate Bills

• Print Receipt for Customers

• Verify Cheque Number

3. News Agent
Software Requirements Specification for Newspaper Automation Page 14
• Publish Newspapers and Magazines

4. Delivery Agent
• Deliver Newspapers and Magazines to Customers

5. Customers
• Pay Monthly Bills (Cheque or Cash)

• Change Subscription Notice

• Modify and Stop Subscription List

• Subscribe to Newspapers/Magazines

6. Bill Management
• Deliver Bills to Customers

• Deliver Receipt to Customers

3.3.2 Use Case #1: Manage Delivery Agent (U1)

Purpose: The manager assigns and manages delivery agents who deliver newspapers/magazines.
Requirements Traceability: FR1, FR3, FR5
Priority: High
Preconditions: Manager must be logged into the system.
Postconditions: Delivery agent details are updated.
Actors: Manager
Extends: None

Flow of Events
1. Basic Flow:

• Manager selects "Manage Delivery Agent" option.

• System displays a list of delivery agents.

• Manager adds, removes, or modifies an agent's details.

• System updates records and confirms changes.

2. Alternative Flow:

• If agent details are invalid, the system displays an error.

3. Exceptions:

• If the database is unavailable, changes cannot be saved.

Includes: None
Notes/Issues: Ensure the system validates delivery agent details.

3.3.3 Use Case #2: Subscribe to Newspaper (U2)

Software Requirements Specification for Newspaper Automation Page 15
Purpose: Customers can subscribe to newspapers/magazines.
Requirements Traceability: FR2, FR4, FR6
Priority: High
Preconditions: Customer must have an account.
Postconditions: Subscription details are saved.
Actors: Customers
Extends: None

Flow of Events
1. Basic Flow:

• Customer selects "Subscribe to Newspaper/Magazine."

• System displays available subscriptions.

• Customer selects preferred subscription.

• System confirms subscription and updates the database.

2. Alternative Flow:

• If subscription is not available, system notifies the customer.

3. Exceptions:

• If payment fails, subscription is not confirmed.

Includes: None
Notes/Issues: Payment verification must be accurate.

3.3.4 Use Case #3: Print Monthly Bills (U3)

Purpose: System generates and prints customer bills every month.
Requirements Traceability: FR7, FR8
Priority: High
Preconditions: System user must be logged in.
Postconditions: Bills are printed and stored in the database.
Actors: System User
Extends: None

Flow of Events
1. Basic Flow:

• System user selects "Print Bills Every Month."

• System retrieves customer details and calculates bills.

• System prints bills for each customer.

2. Alternative Flow:

• If customer details are missing, the system generates an error report.

3. Exceptions:
Software Requirements Specification for Newspaper Automation Page 16
• If the printer is unavailable, system stores bills for later printing.

Includes: None
Notes/Issues: Ensure correct billing calculations.

3.3.5 USE CASE DIAGRAM

Software Requirements Specification for Newspaper Automation Page 17

Other Non-functional Requirements

4.1 Performance Requirements
• P1: The system shall process and generate daily delivery schedules within 5 seconds to ensure minimal delay
in operational workflow.
• P2: The billing module shall compute and generate customer bills for an entire month within 10 seconds for up
to 10,000 active customers.
• P3: The system shall support concurrent access for at least 50 users without noticeable performance
degradation.
• P4: The system shall complete a payment transaction (including verification and database update) within 3
seconds under normal network conditions.
• P5: The response time for user actions (e.g., updating subscription details) shall not exceed 2 seconds under
standard operating conditions.

4.2 Safety and Security Requirements

• S1: The system shall require authentication for all users with role-based access control to ensure data security
and restrict unauthorized actions.
• S2: All communication between the client interface and the server shall be encrypted using Secure Sockets
Layer (SSL) to protect sensitive data.
• S3: The system shall log all significant user activities (e.g., login attempts, modifications to subscription
details, and payment transactions) for audit and tracking purposes.
• S4: Customer financial information (e.g., cheque details) shall be hashed and securely stored in compliance
with industry standards.
• S5: The system shall automatically lock user accounts after three consecutive failed login attempts to prevent
unauthorized access.
• S6: All database backups shall be encrypted and stored securely with access restricted to authorized personnel
only.
• S7: The system shall comply with relevant data protection regulations such as GDPR and PCI-DSS for secure
handling of personal and payment data.

4.3 Software Quality Attributes

4.3.1 Reliability
• R1: The system shall have an uptime of 99.9%, ensuring minimal downtime and continuous operation.
• R2: In the event of a system crash or failure, the system shall be capable of restoring the last known stable state
within 10 minutes using automated recovery procedures.
• R3: The system shall conduct periodic data integrity checks to prevent data corruption and ensure consistent
performance.
Software Requirements Specification for Newspaper Automation Page 18

4.3.2 Maintainability
• M1: The system shall follow a modular architecture to facilitate easier updates and modifications without
affecting overall functionality.
• M2: The source code shall be documented with inline comments and structured following industry best
practices to ease future maintenance efforts.
• M3: The system shall support automated testing for critical modules to ensure seamless updates without
regression errors.

4.3.3 Usability
• U1: The system shall feature an intuitive and user-friendly interface, ensuring that new users can efficiently
operate it with minimal training.
• U2: The software shall include tooltips and contextual help to guide users through complex operations.
• U3: The interface shall be designed with accessibility standards in mind, supporting keyboard navigation and
screen readers where applicable.

4.3.4 Scalability
• SC1: The system shall be capable of scaling horizontally to support increased loads, accommodating up to
100,000 customer records without significant performance degradation.
• SC2: The database structure shall be designed for efficient querying and indexing to maintain performance as
data volume grows.
 Software Requirements Specification for Newspaper Automation Page 19

Appendix A – Data Dictionary

Related
Variable/State Name Type Description Possible States/Values
Operations/Requirements
- Valid credentials: Access
Username and password F1: Manager/Deliverer
User Credentials Input granted<br>- Invalid
entered by users during login. Login
credentials: Access denied
Name of the newspaper or F2: Add
Publication Name Input magazine being added or Alphanumeric string Publication<br>F3: Edit
edited. Publication Details
F2: Add
Publication Language of the publication Dropdown list of supported
Input Publication<br>F3: Edit
Language (e.g., English, Hindi). languages
Publication Details
F2: Add
Publication Brief description of the
Input Free-text field Publication<br>F3: Edit
Description publication content.
Publication Details
F2: Add
Cost of subscribing to the
Publication Price Input Positive decimal value Publication<br>F3: Edit
publication.
Publication Details
Full name of the customer F4: Add Customer<br>F5:
Customer Name Input Alphanumeric string
subscribing to the service. Edit Customer Details
Physical address of the
F4: Add Customer<br>F5:
Customer Address Input customer for delivery Free-text field
Edit Customer Details
purposes.
Contact number of the Numeric string (e.g., 10 F4: Add Customer<br>F5:
Customer Phone Input
customer. digits) Edit Customer Details
Type of subscription (e.g., Dropdown list of F4: Add Customer<br>F5:
Subscription Type Input
daily, weekly, monthly). subscription options Edit Customer Details
F9: With-Hold
State Unique identifier for each Auto-generated numeric
Customer ID Subscription<br>F10:
Variable customer in the system. value
Payment Receipt
Duration for which the Numeric value (e.g., days, F9: With-Hold
With-Hold Duration Input
subscription is paused. weeks, months) Subscription
Amount paid by the customer
Paid Amount Input Positive decimal value F10: Payment Receipt
for their subscription.
Cheque reference number for
Cheque Number Input Alphanumeric string F10: Payment Receipt
payment verification.
F6: Publications to be
State Unique identifier for each Auto-generated numeric
Delivery Agent ID Delivered<br>F11:
Variable delivery agent in the system. value
Deliverer Payment
Address assigned to a delivery
String containing address F6: Publications to be
Assigned Address Output agent for delivering
details Delivered
publications.
Summary of publications Table format with customer
Delivery Summary Output delivered to customers in a names, publication types, F7: Delivery Summary
month. and quantities
Monthly Bill Output Calculated bill for a customer Table format with F8: Customer Bills
 Software Requirements Specification for Newspaper Automation Page 20
Related
Variable/State Name Type Description Possible States/Values
Operations/Requirements
based on subscriptions and publication type, quantity,
deliveries. and total cost
Printed receipt with
Confirmation of payment
Payment Receipt Output customer ID, amount paid, F10: Payment Receipt
made by the customer.
and date
Total payment due to a
Deliverer Payment
Output delivery agent based on Positive decimal value F11: Deliverer Payment
Amount
deliveries made.
All database-related
Database State Indicates whether the system is - Connected<br>-
operations (e.g.,
Connection Status Variable connected to the database. Disconnected
adding/editing records)
State Tracks the operational status R1: System uptime
System Uptime - Up<br>- Down
Variable of the system. requirement
Authentication State Indicates whether a user is - Authenticated<br>- Not S1: Authentication
Status Variable authenticated. Authenticated requirement
Tracks the number of
State S5: Account lockout after 3
Login Attempts consecutive failed login Integer value (0–3)
Variable failed attempts
attempts by a user.
Indicates whether a
State Notification and Alerts
Notification Status notification (email/SMS) was - Sent<br>- Failed
Variable functionality
successfully sent.
Route Optimization State Indicates whether delivery - Optimized<br>- Not Daily Delivery Scheduling
Status Variable routes have been optimized. Optimized functionality
Payment Gateway State Indicates whether the payment - Operational<br>- Non-
Payment Processing API
Status Variable gateway is operational. operational
Backup Encryption State Indicates whether database - Encrypted<br>- Not S6: Backup encryption
Status Variable backups are encrypted. Encrypted requirement
Metrics related to system
Performance P1–P5: Performance
Output performance (e.g., response Numerical values
Metrics requirements
time, uptime).
Logs of significant user
Timestamped entries with S3: Activity logging
Audit Logs Output activities for tracking and
activity details requirement
auditing purposes.
Indicates whether periodic
Data Integrity State R3: Data integrity check
data integrity checks have - Passed<br>- Failed
Check Status Variable requirement
passed.
Maximum number of customer
Scalability records the system can handle SC1: Scalability
Constant 100,000
Threshold without performance requirement
degradation.
Maximum number of users
Concurrent User P3: Concurrent access
Constant who can access the system 50
Limit requirement
simultaneously.
Maximum allowable response
Response Time P5: Response time
Constant time for user actions under 2 seconds
Threshold requirement
standard conditions.
Billing Calculation Constant Maximum time allowed for 10 seconds P2: Billing module
Time generating monthly bills for performance requirement
 Software Requirements Specification for Newspaper Automation Page 21
Related
Variable/State Name Type Description Possible States/Values
Operations/Requirements
10,000 customers.
Maximum time allowed for
Payment P4: Payment transaction
Constant completing a payment 3 seconds
Transaction Time performance requirement
transaction.
Maximum time allowed for P1: Daily schedule
Daily Schedule
Constant generating daily delivery 5 seconds generation performance
Generation Time
schedules. requirement
Software Requirements Specification for Newspaper Automation Page 22

Appendix B - Group Log

Meeting Minutes and Activities

Meeting 1: Project Kickoff and Role Assignment
• Date: 08/02/2025
• Attendees: All group members
• Agenda:
• Introduction to the project and understanding the scope of the Newspaper Agency Automation
Software (NPAS).
• Division of responsibilities among team members:
• Anmol Mangaraj: Functional Requirements and Use Case Modeling.
• Sneha Burman & Madireddy Anusha: Non-Functional Requirements and Performance Metrics.
• Pravanjan Swain & Sneha Burman : Data Dictionary and External Interface Requirements.
• Mohammad Waris & Madireddy Anusha: Overall Description and Document Formatting.
• Established deadlines for initial drafts.

Meeting 2: Midpoint Review and Progress Check

• Date: 09/02/2025
• Attendees: All group members
• Agenda:
• Reviewed progress on individual sections.
• Discussed challenges faced during requirement gathering and resolved ambiguities.
• Finalized the structure of the SRS document and ensured alignment with IEEE standards.
• Assigned tasks for integrating sections into a single document.

Meeting 3: Peer Review and Feedback

• Date: 11/02/2025
• Attendees: All group members
• Agenda:
• Conducted a peer review of the integrated document.
• Identified areas for improvement, such as formatting inconsistencies and missing details in the Data
Dictionary.
• Finalized the Appendix sections (A and B) and prepared the document for submission.

Individual Contributions
1. Anmol Mangaraj

•
Developed the functional requirements section, including detailed descriptions of features like
subscription management, billing, and delivery scheduling.
• Created use case diagrams and flowcharts to illustrate user interactions.
2. Madireddy Anusha & Sneha Burman

• Drafted the non-functional requirements, focusing on performance, safety, security, and scalability.
• Ensured compliance with industry standards such as GDPR and PCI-DSS.
Software Requirements Specification for Newspaper Automation Page 23
3. Sneha Burman & Pravanjan Swain

•
Designed the Data Dictionary, ensuring all variables, inputs, outputs, and state variables were
documented systematically.
• Defined external interfaces, including hardware and software dependencies.
4. Mohammad Waris & Madireddy Anusha
• Compiled the overall description section, providing context for the product's functionality and
operational environment.
• Ensured consistent formatting and adherence to IEEE guidelines throughout the document.

Tools and Resources Used

• Collaboration Tools: Google Docs for real-time collaboration and version control.
• Diagramming Tools: Lucidchart and Microsoft Visio for creating use case diagrams and system architecture
visuals.
• Documentation Standards: Followed IEEE Std 830-1998 for structuring the SRS document.

Key Challenges and Resolutions

• Challenge 1: Ambiguity in defining non-functional requirements.
• Resolution: Conducted additional research and consulted the instructor for clarification.
• Challenge 2: Integrating sections written by different members into a cohesive document.
• Resolution: Held multiple peer review sessions to ensure consistency and alignment.

Conclusion
The group worked collaboratively to produce a comprehensive and professional SRS document for the Newspaper
Agency Automation Software. Each member contributed significantly to their assigned sections, and regular meetings
ensured effective communication and timely completion of tasks. The final document reflects the team's dedication to
delivering a high-quality specification that meets the project's objectives.