This section contains all of the functional and quality requirements of the system. It gives a detailed description of the system and all its features.

A first time user will see the home screen when he/she opens the application, as shown in Figure 1. The home screen will contain Tabs from different news sources. It will also include a list of current and recent news from that particular selected news source in card view.

If the user feels like reading a news article, he/she must click/select a card with a news from the displayed list.

After selecting a news source, the user will be presented with the full news article as shown in Figure 2.

UI Design

Since neither the mobile application nor the backend have any designated hardware, it does not have any direct hardware interfaces.

The mobile application communicates with the backend via API calls. It request news from a specific source and the backend looks for that news source in the noSQL database. Then It fetches most recent 24 news article and serves it back to the mobile application. Then the application converts this data to a format that it is familiar with and displays it as a list of cards.

Functional requirement 1.1

ID: FR1
TITLE: Download mobile application
DESC: A user shall be able to download the mobile application from EntireNews website and the application shall be free to download
RAT: In order for a user to download the mobile application
DEP: None

Functional requirement 1.2

ID: FR2
TITLE: Download and notify users of new releases
DESC: When a new/updated version or release of the software is released, the user shall check for these manually on our webite. The download of the new release shall be done through the mobile phone in the same way as downloading the mobile application
RAT: In order for a user to download a new/updated release
DEP: FR1

Functional requirement 1.3

ID: FR3
TITLE: Mobile Application - homepage view
DESC: Given that the user has downloaded the mobile application, the user shall be able to see the homepage with tabs and article cards in a list view. The article cards shall contains the news headline (title), few lines of the news article (if there is space) and a cover image, from the pre-set default news source with other news sources in a tab on the top of the app. Along with the article view and the sources tabs the user shall see a menu button and a back button on the top of the app screen.
RAT: The way user sees the app when he first opens it after downloading
DEP: FR1

Functional requirement 1.4

ID: FR4
TITLE: Mobile application - Switch source tab
DESC: On the Homepage view selecting the tabs on the top of the app screen or by simply swiping left or right the user shall be able to switch between different sources
RAT: In order to switch the source tab
DEP: FR3

Functional requirement 1.5

ID: FR5
TITLE: Article view
DESC: Given that the user clicks on an article news card, the user shall be able to see the entire article in the article view. This page shall contain the news heading, news article, cover image, publish date, number of saves and views
RAT: The way user can view the entire article
DEP: FR3

Functional requirement 1.6

ID: FR6
TITLE: Incrementing views
DESC: Given that the user is viewing an article, the number of views shall increment by one
RAT: The way user views increment
DEP: FR5

Functional requirement 1.7

ID: FR7
TITLE: Saving an article for offline reading
DESC: Given that the user clicks on the star (save) icon either in list view or in article view, the article shall be saved locally onto the mobile device for later reading without internet connection. The number of saves shall increase by one
RAT: The way user saves an news article
DEP: FR3 or FR5

Functional requirement 1.8

ID: FR8
TITLE: Close article view
DESC: Given that the user is viewing an article, the user shall be able to close the view (or go back) by tapping on the back button on the top of the view.
RAT: The way user close article view
DEP: FR5

Functional requirement 1.9

ID: FR9
TITLE: Pull to close article view
DESC: Given that the user is viewing an article, the user shall be able to close the view (or go back) either by pulling the article from the top or the bottom.
RAT: The way user close article view
DEP: FR5

Functional requirement 1.10

ID: FR10
TITLE: Menu options
DESC: Given that the user taps on the menu button, the user shall be able to see the menu options. The user shall now be able to choose between going to saved news page, settings page, about page.
RAT: In order to view saved menu, settings menu, and about page
DEP: FR3

Functional requirement 1.11

ID: FR11
TITLE: Viewing saved articles
DESC: Given that the user selected saved articles from the menu options, the user shall be able to view saved news article cards in a list view.
RAT: The way user can view all saved articles. DEP: FR10

Functional requirement 1.12

ID: FR12
TITLE: Read a saved article
DESC: Given that the user clicks on an article news card, the user shall be able to see the entire saved article in the article view. This view shall contain the news heading, news article, cover image, publish date, number of saves and views
RAT: The way user can view a saved entire article.
DEP: FR11

Functional requirement 1.13

ID: FR13
TITLE: Change tabs of sources
DESC: Given that the user selected settings from the menu option, the user shall be able to change news sources that shows up in homepage view.
RAT: The way user can change sources
DEP: FR3

Functional requirement 1.14

ID: FR14
TITLE: Get notified at a interval
DESC: Given that the user has the app installed, he/she shall be able to enable notification for a given interval.
RAT: The way user change notification settings
DEP: FR3

Functional requirement 1.15

ID: FR15
TITLE: Generate Recommendations
DESC: The articles being viewed or marked not interested by the user should be recorded and recommendations based on those articles should be generated.
RAT: The way recommendations are generated
DEP: FR5, FR6

Functional requirement 1.16

ID: FR16
TITLE: Get recommendations
DESC: Given that the user has viewed some article, recommendations based on those articles should be displayed to the user under recommendation tab on the home page view.
RAT: The way user sees the recommended articles
DEP: FR3, FR15

Functional requirement 1.17

ID: FR17
TITLE: Not interested article
DESC: Given that the user is not interested in a certain recommended article they should be able to click a not interested button to remove that and any similar article from the recommended article view.
RAT: The way user can dismiss not interested articles
DEP: FR3, FR15, FR16

Funtional requirement 1.18

ID: FR18
TITLE: User Registration
DESC: The user should be able to register and create a profile on the application using username, email and password.
RAT: The way user creates a profile
DEP: FR1

Functional requirement 1.19

ID: FR18
TITLE: User Login
DESC: Given that the user has already registered and has a profile, he should be able to login using username/email and password.
RAT: The way user login
DEP: FR18

Functional requirement 2.1

FR-1
TITLE: Requesting new news URLs
DESC: Using python's request library the system shall be able to smoothly obtain news articles' URLs from Newsapi.org. This URLs shall be stored for later use.
RAT: For the system to receive links to news articles
DEP: NONE

Functional requirement 2.2

FR-2
TITLE: Duplicate articles checking
DESC: The system shall be able to save all the URLs of already scraped articles. It shall also be able to crosscheck these saved URLs with new article URLs before scraping. So the system shall only scrap only new articles and ignore those that have already been scrapped.
RAT: No duplicate articles scraping/saving.
DEP: FR1

Functional requirement 2.3

FR-3
TITLE: Scrap data
DESC: Given that the system has news URLs. Using python library newspaper3k the system shall be able to scrap articles data (text/content) from the source (URL) obtained. The obtained information (title, URL, date, text/description, image and others) shall be saved as a python dictionary.
RAT: Scrap data for a given URL
DEP: FR2

Functional requirement 2.4

FR-4
TITLE: Articles length checking
DESC: After scraping the article check to make sure the articles has sufficient information. If not the system shall ignore the article.
RAT: Making sure that the article has at least 500 character.
DEP: FR3

Functional requirement 2.5

FR-5
TITLE: JSON format
DESC: Given that the system has scraped data in python dictionary format. The system shall be able to convert the scraped data to a JSON format.
RAT: Preparing data for sending post request
DEP: FR4

Functional requirement 2.6

FR-6
Feature: Administrative Login
DESC: In order to save news articles the system shall be able to authenticate itself first

Scenario: Login with Username and Password
The system shall be able to authenticate itself using a Username and Password.
The system shall be provided with a JWT (JSON Web Token)
with an expiration date.
The system shall be able to save that JWT for later use.

Scenario: Saving JWT
Given that the system has a got new a JWT, It shall be able to save
that JWT for later use.

Scenario: Login with JWT (JSON Web Token)
Given that the system has a saved JWT, it shall try to authenticate
itself using that JWT.
The system shall be provided with a new JWT (JSON Web Token) with a new
expiration date.
The system shall be able to save that JWT for later use.

Scenario: Login failed with JWT
Given that the system failed to login with the saved JWT, it shall
try to authenticate itself using username and password.

Scenario: Login failed with Username and Password
Given that the system failed to login with username and password,
it not be allowed to post/save any news article.

Functional requirement 2.7

FR-7
Feature: Saving news articles
TITLE: Saving news articles
DESC: Given that the system has scraped data in JSON format. The system shall be able to post the data to the server (for saving to the database). The system shall be able to authenticate itself each time it sends post request.
RAT: For saving news articles to the database.
DEP: FR4, FR6

The requirements in this section provide a detailed specification of the user interaction with the software and measurements placed on the system performance.

ID: QR1
TITLE: Prominent source feature.
DESC: The source feature shall be prominent and easy to find for the user.
RAT: In order to for a user to find the source feature easily.
DEP: none

ID: QR2
TITLE: Change of the source feature.
DESC: The tabs switching options shall be evident, simple and easy to understand.
RAT: In order to for a user to perform a source change easily.
DEP: none

ID: QR3
TITLE: Usage of the result in the list view.
DESC: The news articles are displayed in the list view shall be user friendly and easy to understand. Selecting an element in the list shall only take one click.
RAT: In order to for a user to use the list view easily.
DEP: none

ID: QR4
TITLE: Usage of the Swipe to access in the tab view.
DESC: The news sources displayed in the tab view, just swipe in order to change the between news sources, shall be user friendly and easy to understand.
Using the swipe shall only take one swipe (left or right)
RAT: In order to for a user to use the map view easily.
DEP: none

ID: QR5
TAG: ResponseTime.
GIST: The fastness of retrieving a list of news.
SCALE: The response time from the server.
METER: Measurements obtained from 100 news loads during testing.
MUST: No more than 3 seconds 100% of the time.
WISH: No more than 1 second 100% of the time.

ID: QR6
TAG: SystemDependability
GIST: The fault tolerance of the system.
SCALE: If the system loses the connection to the Internet news articles will not load, and the user shall be informed.
METER: Measurements obtained from 48 hours of usage during testing.
MUST: 100% of the time.

This section includes the design constraints on the software caused by the hardware.

ID: QR7
TAG: HardDriveSpace
GIST: Hard drive space.
SCALE: The application’s need of hard drive space.
METER: MB.
MUST: No more than 10 MB.
PLAN: No more than 8 MB.
WISH: No more than 4 MB.
MB: DEFINED: Megabyte

ID: QR8
TAG: ApplicationMemoryUsage
GIST: The amount of Operate System memory occupied by the application.
SCALE: MB.
METER: Observations done from the performance log during testing.
MUST: No more than 50 MB.
PLAN: No more than 20 MB.
WISH: No more than 10 MB.
Operate System: DEFINED: The mobile Operate System which the application is running on.
MB: DEFINED: Megabyte.

The requirements in this section specify the required reliability, availability, security and maintainability of the software system.

ID: QR9
TAG: SystemReliability
GIST: The reliability of the system.
SCALE: The reliability that the system gives the right result on a selected source.
METER: Measurements obtained from 16 source change during testing.
MUST: More than 98% of source change. PLAN: More than 99% of source change.
WISH: 100% of source change.

ID: QR10
TAG: SystemAvailability
GIST: The availability of the system when it is used.
SCALE: The average system availability (not considering network failing).
METER: Measurements obtained from 48 hours of usage during testing.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.

ID: QR11
TITLE: Internet Connection
DESC: The application shall be connected to the Internet.
RAT: In order for the application to communicate with the backend.
DEP: none

ID: QR12
TAG: AutomatedSystemLoginAccountSecurity
GIST: Security of accounts.
SCALE: If an Automated system tries to log in to the backend server with a non-existing account then the system shall not be logged in. The system shall be notified about login failure.
METER: 10 attempts to log-in with a non-existing user account during testing.
MUST: 100% of the time.

ID: QR13
TITLE: Application extensibility
DESC: The application shall be easy to extend. The code shall be written in a way that it favors implementation of new functions.
RAT: In order for future functions to be implemented easily to the application.
DEP: none

ID: QR14
TITLE: Application testability
DESC: Test environments shall be built for the application to allow testing of the applications different functions.
RAT: In order to test the application.
DEP: none

ID: QR15
TITLE: Application portability
DESC: The application shall be compatible with Android Operating System.
RAT: The adaptable platform for the application to run on.
DEP: none