Software Requirements Specification - Sajid231/Bengali-Newspaper GitHub Wiki
Software Requirements Specification
For Bengali Newspaper
Prepared By-
1. Fazla Rabbi Sajid-1513155642
2. Rayhan Bppy-1520824042
3. Md Rakibul Kabir Khan-1631789042
4. Zubaer Ahmed-1711218042
North South University
Software Engineering (Cse-327.4)
Submission Date:
07 July, 2021
Table of Contents
1 Introduction
2 Overall Description
- 2.1 User Classes and Characteristics
- 2.2 User Needs
- 2.3 Operating Environments
- 2.4 Constraints
- 2.5 Assumptions
3 External Interface Requirements
4 Appendix
SRS:
A software requirements specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements. The SRS is developed based the agreement between customer and contractors. It may include the use cases of how user is going to interact with software system.
Chapter 1
Introduction
1.1 Purpose
Purpose of Software Requirements Specification (SRS) is to describe the specification and description of our project “Bengali Newspaper”. This Software Requirements Specification illustrates, in clear terms, the system's primary uses and required functionality so that the clients and other developers can easily understand what we did and how to change anything if it is required.
1.2 Intended Audience
The intended audience of this document would be Clients, Developers and Project Manager who will evaluate the project. As such, this document was written in plain English with little to no technical terminology so that anyone interested in the “Bengali Newspaper” project can easily read this SRS. This document contains who this application is for, how and where it will run and what it can do. It is recommended that the SRS be read sequentially according to the index given previously.
1.3 Intended Use
The SRS contains this software’s description, requirements ans other functional and non-functional requirements. Readers are requested to read SRS documents in the given sequence.
1.4 Product Scope
The purpose of this software is to make the smartphones and internet more accessible to the old people who are interested to read the newspaper but face problems browsing the internet, often have visionary problems. The objective of the application is to bring news from the trusted sources very easily to the user so that the users don't have to take the trouble to search up these news. No such application is yet on the market for competition.
1.5 Risk Definitions
We are creating a software that will try to help people by bringing news from trusted sources. There is no risk in our software as it will work as a third party between the news source and the user.
Chapter 2
2. Overall Description
2.1 User Classes and Characteristics
The software will be mainly focused onto the user, user will be able to use the software with or without signing in. The admins job is preliminary straight forward, they can update the scripts when ever the newspapers upgrade their style format and due to the security issues the admins won’t be able to access the data of the users. Users will be able to use the voice search command to search for their desired news and listen or read it as they want.
2.2 User Needs
- Provides news from different trusted newspaper sources.
- Users can listen to any news.
- Users can search news using their voices.
- Users can check the source of the news.
- Users can visit the official link of the news if they want.
- Users can stop and switch to any other news.
2.3 Operating Environments
The operating environment of Bengali Newspaper is listed as follows:
- Distributed Database
- Client/Server System
- Operating System: Any system that supports a modern web browser
- Database Configuration: SQLite3
- Platform: Any Platform
2.4 Constraints
- There might be an issue with the newspaper website as they block scraping crawler mistakenly.
- The system shall be available for 99.99% of the time.
- The Software is fully web crawling dependent.
2.5 Assumptions
- User must reliable internet connection.
- User knows how to operate web application
- User will use the software from a noise free environment.
Chapter 3
3. External Interface Requirements
3.1 Functional Requirements
3.1.1 Register
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Register
- Actor: User
- Type: Primary
- Overview: Register / Create new account in the website.
Exception:
- The user fill unformatted information
- Server is down so form did not reach to database server
3.1.2 Login
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Login
- Actor: User
- Type: Secondary
- Overview: Allows user to log in to the website to access the synced bookmarks
Exception:
- The user will unformatted information
- Server is down so form did not reach to database server
3.1.3 Voice Search
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Voice Search
- Actor: User
- Type: Primary
- Overview: Allows user to search their desired news via voice
Exception:
- User is not connected to the internet so system won’t be able to connect to the API
- User is not speaking native Bangla / English which our targeted API won’t recognize
- User is not speaking anything related to news so no match will come
3.1.4 Listen to Audio
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Listen to Audio
- Actor: User
- Type: Primary
- Overview: Allows user to listen to news article
Exception:
- User is not connected to the internet so system cannot contact the API
3.1.5 Check News Source
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Check Source
- Actor: User
- Type: Primary
- Overview: Allows user to check the source of news article
Exception:
- System cannot connect to the database
- User has no internet connection to receive the response
3.1.6 Logout
Stimulus/ Response Sequences The following expanded use case shows the response sequences between the actor actions and the system responses.
- Use Case Name: Logout
- Actor: User
- Type: Secondary
- Overview: Allows user to logout
Exception :
- Server is down so system cannot remove bookmarks
- If there is no internet connection user cannot log out successfully
3.2 Non Functional Requirements
Performance Requirements Any Interface between a user and software shall have reasonable response time based on Intranet connection
3.2.1 Prominent search feature
TITLE: Prominent search feature OVERVIEW: The search feature should be prominent and easy to find for the user. PURPOSE: In order to find the search feature easily for a user. DEP: none
3.2.2 Usage of the Google API
TITLE: Usage of the API OVERVIEW: Using Google Text to speech and Speech to text API's PURPOSE: To convert the user voice into text and use the text for search, and also using Speech to text for listening the news article DEP: none
3.2.3 Response time
TAG: Response Time GIST: The fastness of the search SCALE: The response time of a search METER: Measurements obtained from 1000 searches during testing. MUST: No more than 2 seconds 100% of the time. WISH: No more than 1 second 100% of the time.
3.2.4 System dependability
TAG: System Dependability GIST: The fault tolerance of the system. SCALE: If the system loses the connection to the Internet or missing any sensor, the user should be informed. METER: Measurements obtained from 1000 hours of usage during testing. MUST: 100% of the time.
Safety Requirements: To ensure no data is lost in case the user decides to change devices or if the user's device is extensively damaged all data will be stored in Google cloud storages. This will allow safe storage and easy accessibility from anywhere.
Security Requirements: The System shall not disclose any personal information about the users. The Application shall not grant access to an unauthorized user and the Application shall not communicate with any other devices or servers while in use by the user. In addition to that users must refrain from uploading any sensitive information such as credit card info, id or any personal information that is not required.
3.2.5 Communication Security
TAG: Communication Security GIST: Security of the communication between the system and server. SCALE: The messages should be encrypted for log-in communications, so others cannot get user-name and password from those messages. METER: Attempts to get user-name and password through obtained messages on 1000 log-in session during testing. MUST: 100% of the Communication Messages in the communication of a log-in session should be encrypted. Communication Messages: Defined: Every exchanged of information between client and server.
3.2.6 User Account Security
TAG: User Create Account Security GIST: The security of creating account for users of the system. SCALE: If a user wants to create an account and the desired user name is occupied, the user should be asked to choose a different user name. METER: Measurements obtained on 1000 hours of usage during testing. MUST: 100% of the time.
Chapter 4
4. Appendix
Glossary
Definitions, acronyms, and abbreviations are listed below:
| Serial | Term | Definition |
|---|---|---|
| 1 | User | Someone who interacts with the mobile phone application |
| 2 | Admin/Administrator | System administrator who is given specific permission for managing and controlling the system |
| 3 | User | Someone who can see news |
| 4 | Admin | fsdafsadfsdf |
| 5 | DEP | Dependency |
| 6 | PFR | Primary Functional Requirements |
| 7 | SFR | Secondary Functional Requirements |
| 8 | GIST | A short description to help understanding [2] |
| 9 | SCALE | The scale of measurement used to quantify the statement [2] |
| 10 | METER | The process or device used to measure using the SCALE [2] |
| 11 | MUST | The minimum level required to avoid failure [2] |
| 12 | PLAN | The level at which success can be claimed [2] |
| 13 | WISH | A desirable level of achievement [2] |
- API: Application Protocol Interface. This is the part of a program that lets other programs or services interact with the data in the former and vice versa.
- Framework: It is like the base of a program that provides generic functionality but can be custom built for specific purposes
- Backend: The part of an app service that works behind the scenes away from the user's device, usually in the cloud (server computer owned by the company)
- Proprietary: Owned by that particular company/person etc.