All in One

Addis Ababa Institute of Technology
Center of Information Technology and Scientific Computing

Department Software Engineering
Ad Platform
Project Proposal, SDS and SRS
Team Members
Enkusellasie Wendwosen
Haftamu Meresa
Hiwot Bishaw
Melkamu Mitiku
Advisor
Abraham Getachew
CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING Page ! 1

ACKNOWLEDGMENT
First of all we are grateful to the God for the good health and wellbeing that were necessary to complete this
proposal.
We wish to express our sincere thanks to our advisor for his continued support and assistance during the writing
of this proposal. It wouldn’t have been done without him.
I take this opportunity to express gratitude to all of the ITSE faculty members for their help and support. I also
thank my parents for the unceasing encouragement, support and attention. I am also grateful to my partner who
supported me throughout this venture.
I also place on record, my sense of gratitude to one and all, who directly or indirectly, have lent their hand in
this venture.
CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 2

Proposal

TABLE OF CONTENTS - Proposal
ABSTRACT
One of the main driving forces of the 21st century is globalization facilitated by the ever so expanding
internet. Internet has become a critical ingredient for any economy that wants to thrive in face of tremendous
competition in the connected world. At the epicenter of the internet lies different social media sites that
people spend most of their times

1.INTRODUCTION
1. Background
One of the main driving forces of the 21st century is globalization facilitated by the ever so expanding internet.
Internet has become a critical ingredient for any economy that wants to thrive in face of tremendous competition
in the connected world. Innovative technologies have disrupted century old businesses. Taking Uber for
example, it has changed the commuting industry forever.
At the epicenter of the internet lies different social media sites that people spend most of their times on. It is
reported that people spend a significant amount of their time on social media. The following graph shows the
amount of time people spend on social media monthly.
Figure 1: Digital Audience Penetration vs Engagement of Leading
We can observe from the above graph that Facebook is the obvious champion with 1000+ minutes per visitor
and almost 98% reach amongst age group 18-34 [3]. This is a very interesting number.
Facebook generates revenue by showing relevant targeted ads. Advertisers that work with Facebook are happy
because they can advertise to a demographic of their choice. This advertisement business has generated billions
to Facebook as shown in the below graph[10].

Figure 2: Facebook Quarterly Profit
Another competing company with similar strategy is google. Google is the most used search engine by a huge
margin(76%). Google’s AdWords advertisement platform gives advertisers a similar tool that enables them to
target users and advertise to a certain demographic. Google reports a revenue of $19.1 billion in 2016 alone[4].
As illustrated above the online advertisement is a multibillion dollar business. This begs the question, what
about Ethiopia? Ethiopia is one of the countries with least internet penetration(4.2%). This number might seem
small but it is 4.2% of 101,853,268 people which is 4,288,023. This number is an increase from 3.8% the
previous year [2].
Online advertisement is almost non-existent. We believe that this is due to many reasons listed as follows.
• No advertisement platform localized for Ethiopia. The tools stated above(Facebook Ads, Google
AdWords) are mostly used by international companies working in Ethiopia like Total and Coca Cola.
Local companies simply ignore using these tools even though they are very effective.
• Advertisers are more focused on more traditional means of media, like radio, television and print
advertisements.
This presents a unique opportunity to create an Advertisement platform unique to the needs of Ethiopians.
Before we get into that we need to see if there are worthy websites that we can advertise on.
With the popularity and immense success of dire-tube, numerous such websites have appeared. Doing a search
for ‘tubes’ on Facebook will present a search result of more than a 1000 Facebook pages, each having a
corresponding website. These websites use their respective Facebook pages to generate traffic to their websites.
They post relevant topics like scholarships, food and others. So why are there so many websites and how do
they generate revenue?We interviewed the owner and operator of esetube.com, Ato Esayas Zenebe, and we
have summarized what we have got.
The number one means of generating revenue is through ads. They use in page Ads like Google AdSense.
There is a confirmation process that takes up to 6months and once they get the confirmation they can only
access their money through international credit card vendors like VISA and MASTERCARD.
The main disadvantages of Google AdSense are the following.

• Google AdSense targets users geographically, hence clicks generated by users in Ethiopia have a very
low per click payment(0.0001$).

• Amharic is not supported by AdSense, meaning that if websites have content in Amharic, the website will
be rejected. (AdSense supports 39 languages).
However as stated above there are around 1000 websites that take advantage of Google AdSense, to generate
revenue, we can conclude from this that if there is an Ad Platform there will be even more websites that will
be very happy to use this platform.
The Project is an Ad Platform. The unique feature of this platform is that it will be content and user aware.
Meaning that it will deliver relevant ads taking into consideration the content the advertisement is being viewed
along and the viewer that is viewing the advertisement.
The platform will be a place where advertisers will be able to advertise their products and services to a
demographic of their choice. There will be a web-panel that they will use control their advertisements and see
statistics. The platform will also have a web-panel for website owners to view statistics and view their ads.
Another very crucial part of this platform is delivery of the ad.
We will deliver a javascript plugin to deliver the ads to websites. The website owners will need to import the
library in their pages. It will have a very small size and will support all browsers. Most website owners use
content management systems like Wordpress and Joomla. Hence we will create plugins for Wordpress and
Joomla too.
The system will roughly have minimal cost, as it doesn't require any hardware components. The only cost will
be for hosting used to host the web app. The system will take roughly 4-5 months be delivered. However there
needs to be a detailed system requirement specification to be exact.
We are planning to work in co-operation with payment services like HelloCash and MBirr to streamline the
payment process. This will make it very easy for Advertisers to pay their dues and websites earn their earnings.
2. The Existing System
As stated in the background section, the target customers are website owners. The most popular Advertisement
system they use to generate revenue is Google AdSense.
Google AdSense is a program run by Google that allows publishers in the Google Network of content sites to
serve automatic text, image, video, or interactive media advertisements, that are targeted to site content and
audience.
Google uses its technology to serve advertisements based on website content, the user's geographical location,
and other factors. Those wanting to advertise with Google's targeted advertisement system may enroll through
Google AdWords. AdSense has become one of the popular programs that specializes in creating and placing
banner advertisements on a website or blog, because the advertisements are less intrusive and the content of
the advertisements is often relevant to the website. Many websites use AdSense to make revenue from their
web content (website, online videos, online audio content, etc.). AdSense is the most popular advertising
network.[5] AdSense has been particularly important for delivering advertising revenue to small websites that
do not have the resources for developing advertising sales programs and salespeople to seek out advertisers.
To display contextually relevant advertisements on a website, webmasters place a brief Javascript code on the
websites' pages. Websites that are content-rich have been very successful with this advertising program, as
noted in a number of publisher case studies on the AdSense website. AdSense publishers may only place up to
three link units on a page, in addition to the three standard ad units, and two search boxes.[6] This restriction is
not applicable for premium publishers who work directly with account managers at Google.

Some webmasters put significant effort into maximizing their own AdSense income. They do this in three
ways:
• They use a wide range of traffic-generating techniques, including but not limited to online advertising.
• They build valuable content on their websites that attracts AdSense advertisements, which pay out the
most when they are clicked.
• They use text content on their websites that encourages visitors to click on advertisements. Note that
Google prohibits webmasters from using phrases like "Click on my AdSense ads" to increase click rates.
The phrases accepted are "Sponsored Links" and "Advertisements".
The source of all AdSense income is the AdWords program, which in turn has a complex pricing model based
on a Vickrey second price auction. AdSense commands an advertiser to submit a sealed bid (i.e., a bid not
observable by competitors). Additionally, for any given click received, advertisers only pay one bid increment
above the secondhighest bid. Google currently shares 68% of revenue generated by AdSense with content
network partners, and 51% of revenue generated by AdSense with AdSense for Search partners.[7]
3. Statement of the Problem
As we tried to illustrate in the background section, the online advertisement industry is very huge with billions
in revenues. We also stated that Google and Facebook are the major players. Ethiopians are not used to seeing
relevant Ads on the internet even when they visit Ethiopian websites. This is simply because Ethiopian
advertisers and businesses find it very hard to advertise online. Hence visitors to these sites have very little
tendency to click on ads. Ads which are not easy to put up( Google AdSense has a rigorous selection process
before they let their ads be visible on a site). To top it all of AdSense has the least amount of value to clicks
generated by Ethiopians(location or IP generated from Ethiopia) as the ads are not relevant to Ethiopians, which
is about $0.001[8], which is not easy accessible as international credit/debit cards(MasterCard, VISA) are
required.
Above we stated what the problems are in general. Lets take a closer look at each problem
• No Relevant Ads
• Rigorous selection process
• Amharic and other Ethiopian Languages not supported
• Money not accessible
• Traditional Ads are not relevant in modern days of smartphones
• Traditional Ads don’t have statistics.
• Advertising to an increasingly online audience.
These problems are so many hence there are many stakeholders involved. Businesses that advertise their
products and services, webmasters that cater to different website visitors, advertisers that create and market
these Ads are some of the stakeholders.
This lack of a working ecosystem has inhibited the industry from flourishing. Lack of an ecosystem maybe
something hard to imagine and one might argue that we are fine as we are now. But in comparison to the global
advertisement industry, this is not something to be easily dismissed. This ecosystem has the opportunity to
create a tremendous amount of jobs. Having this ecosystem will create complex ecosystem of webmasters

catering to the ever so expanding demand of visitors. This means that there will also be a very fierce competition
between creators of ads to capture the attention of the visitors. And all this will be accompanied by the Ad
Platform at the center.
4. Objective of the Project
The overall objective of the proposed project is to develop effective, easy and efficient online
advertising platform for local (Ethiopia Market).
1. Specific Objectives
• to develop a plugin that is lightweight( easy to load even in very slow connections).
• to develop a plugin that is can display ads on pages it is plugged into.
• to develop a plugin that can surpass ad-blockers.
• to develop a platform that ,in congruence with the plugin, can deliver ads based on the content the
website contains. This will make sure that the audience will see relevant ads that relate to the content
the viewer is reading, watching.
• to develop a plugin that is very easy to incorporate into websites, including two of the most popular
Content Management Systems: Wordpress and Joomla.
• to develop a plugin that will collect analytics, that will help webmasters understand their audience.
This will help them better cater to their audience.
• to develop a web-panel that will enable advertisers advertise using images, GIFs, videos or just text.
The web-panel will also enable advertisers specify the target audience that the advertisement will be
advertised to
5. Proposed System
As mentioned above the publishers face a big challenge in generating fair revenue. Even if they sign up
for ad platforms like Google Ad Sense, the filtration process is very rigorous and time consuming. After
they pass the filtration process, the money they got from displaying advertisement is very few. This is
because the ad platforms don't target a market like Ethiopia. The website users see this advertisements as
not relevant data or they just think that they are a distraction. The reason behind this is, this advertisements
don't display products that local viewers can actually buy or use. Their local companies are not online,
most of them advertise their product only using the traditional ones like TV, radio or newspapers.
Our proposed system can create an echo-system of local businesses, website viewers and web masters.
This way viewers can see relevant advertisements.

By designing a simple compatible plug-in webmasters can display advertisements on their websites. The
website owners can get a better revenue from the advertisements that are targeting the local customers.
In order to do this we should attract advertisers by building a reliable, efficient and effective system to
advertise their product. We can do this by ;-
• Identification of Customer - By using different technologies like AI the system should be able to
identify what kind of customer is attracted to specific products. This is called Behavioural
Targeting. It will help the marketer to identify the target customers for their product.
• Identification of article - depending on the websites article the advertiser can target a customer using
the document context. For example if the website is talking about the top ten tourist attraction in
Ethiopia the a tour and travel agencies can target the reader to market what their company can offer.
This is called Contextual Targeting
• Offering them a digital local payment system. This can a reduce the process of the manual or the
paper payment system which is a very time consuming
• Building a system which they can manage their campaign and number of customers.
• Displaying the statics of clicks to their ads and also how the website are doing Feasibility Study

6. Feasibility Study
1. Economic Feasibility
1. Developmental cost
Since the project is web based and can be developed using open source software,
it will be free for use. And all the API’s we need to develop the system are free.
Therefore, the development cost is ZERO.
2. Operational Cost
For this project to be up and running, we will be a pay for the server to host the
web services. Other than this there will not be any additional payment.
2. Technical Feasibility
The main problem will be the website owners that don’t able to put the plugin in the website so
we put the plugin in the registered website to promote on the website so we give the technical
support to the website owners.
3. Schedule Feasibility
This project should be delivered by the time frame allocated. Even if the development process
needs various testing, the time deadline should be the major constraint. Therefore, the deadline for
the delivery of the product should go in accordance with the desirable scheduling to ensure the
proper delivery of the project
7. Scope
This Ad Platform is an advertising service that lets website owners/webmasters and bloggers make money by
showing targeted ads on their sites.
The scope of a system can be defined either using the deliverables from the project or the tasks the system
accomplishes. We prefer to use the task oriented approach to define the scope of the project. The main goal of
the project is to develop an add Platform system that performs the following tasks for the different user groups
we have in the system.
Ad Admins/Our System will able to

• Make modifications to the Ad
• Determine page context and serve a contextually relevant ad
• Targeting: Bring message to exactly the right customers wherever they are online.

o Show ads on sites related to keywords o Show
ads on specific websites that you choose o Show
ads based on user interest o Show ads on pages
about specific subjects o Show ads where your
customers are located
• Create all types of ads - text, image, interactive and video ads.
o Text Ads: Includes a headline, two lines of text
(35 characters each), and a URL. o Image Ads:
include relevant images, customized layouts and

background colors.
o Rich Media Ads o

Video Ads
• Place those ads on websites that are relevant to what you’re selling.
• Block webmasters ad account
• Manage webmasters
• Handle cautions: send warning for fraud clicks

• Collecting information about webmaster's site
Webmasters will be able to
• Sign-up and approvals
• Insert our ad JavaScript code into his/her webpage.

o Copy and paste a piece of code on his/her site where she/he wants to show ads.
• Choose the right ad types and formats for his/her site
• Modification of our ad code : techniques to avoid
• Monitor and manage his/her account o Viewing Key
Metrics o Reading Messages from our ad o Viewing
his/her Payment History o Managing his/her Account
Settings

• Manage Ads o Ad code implementation o Allow and
block ads o Customize ads
• Account management o Account Settings o Address

verification with PIN o Site management o Managing
websites : Give access to our crawler o Privacy and
security
• Payments o Payment process o Form of payment
• Policies End users
• Click on ads shown on the site of their interest

8. Methodology
The methodology we found to be most relevant is ‘SCRUM’ from agile software development methodologies.
We found the techniques in ‘SCRUM’ to be most effective for our context and approach and most of all our
values. Here is a quote from Wikipedia about ‘SCRUM’.
“Scrum is an iterative and incremental agile software development framework for

managing product development. It defines "a flexible, holistic product development
strategy where a development team works as a unit to reach a common goal",
challenges assumptions of the "traditional, sequential approach" to product
development, and enables teams to self-organize by encouraging physical co-
location or close online collaboration of all team members, as well as daily face-
to-face communication among all team members and disciplines involved [10]”
In order to implement Scrum methodology very effectively, the most critical factor is communication between
the working team. The team needs to have Daily Scrums to summarize what has been accomplished the day
before, what challenges were faced and how they were resolved, what the team will be doing that day, and
finally what issues have been found that need the attention of the whole team.
In order to facilitate such a successful meet up and more we will be using two tools. The first one is
MeisterTask and second one is Slack. MeisterTask is a tool to organize the team’s backlog(stuff the team is
working on on each Iteration or sprint). Slack will be the main stream of communication. We will integrate
other development tools with slack like our version control server. This will keep each team-member updated
with the works of other team-members. Scrum master will be Enkusellasie Wendwosen.
Requirement gathering is an integral part of this project’s success or failure. First we have identified who the
major actors are in this system’s ecosystem.
• Website Visitors

• Businesses(Potential Advertisers)
• WebMasters
• Payment service providers
We will need to account vantage points from each of the above actors. We will use questionnaires and face to
face interviews. Questionnaires will be distributed online using Google Forms to a mailing-list database ,we
have developed , of WebMasters. Interviews will be held sparingly with Payment service providers to
understand what their requirements are for integration with their service. These meetings will also be helpful
to distinguish which payment service provider has the better value. There will also be a series of Interviews
with Businesses in order to understand what their values are. This will help us better cater our platform to their
needs.
We will also need to take an in depth look at the current dominant platform, Google AdSense. This will enable
us to understand what is expected from our platform especially from WebMasters that have used Google
AdSense before. We will setup a fake account on google AdSense and also ask WebMasters to show us how
their account looks like.
Design is also another major aspect a successful system. Our system has three major components, that require
attention.
• Plugin
• WebPanel
• ReST API Server
• Information Extraction Server
When considering the design of each component, there are constraints that come to mind. Constraints for each
of the components are as follows.
Plugin
• Size - Has to be less than 10KBs as it needs to be loaded easily even in very slow connections
• Compatibility - Has to be compatible with all browsers.
• Compatibility - Has to be available to popular Content Management Systems.(Wordpress, Joomla)
• Ease of use - Has to be easily configurable and Installable.
• Performance - Has to be able to parse contents of the site it is rendered on very fast, even if the Contents
of the site are very large. Needs to have an efficient HTML parser
WebPanel
• Multilingual - Interface needs to support multiple languages
• Smooth Interactivity - Has to be Single Page App

• Secure - Has to let only authorized personnel access the system.
• Role - Needs to support role based access.
ReST API Server

• Performance - has to have great performance
• Security - has to
• Easily developable - has to require small development effort.
Designing the system will require the system to consider the above constraints.
The implementation of the system will be done in at least 5 or more iterations(Sprints), with each iteration
adding more features to the system. We have planned ahead of time what the first three iterations will need to
incorporate discussed in the following paragraphs. The rest iterations will be decided upon by the success or
failure of the first three iterations.
We will use multiple frameworks. We will use Angular Javascript Framework to implement the WebPanel.
Using angular will enable us to qualify some of the constraints of the Web Panel, as WebPanel being Single
Page Application. We will use Angular Translate to support Multilingual feature. We will use Restangular to
implement connections with ReST API Server. We will use Loopback Node Framework to implement the
ReST API Server. We haven't identified how we are going to implement the Natural Language Processing
and Information Extraction.
Iteration 1
• Getting Familiar with the Multiple Frameworks
• Research on Plugin Implementations.
• Plugin - Send ID and Page content to backend, Receive and Render Ad , Register and Send AdClick.
• Backend - Categorize page content sent from plugin based on certain criteria Iteration 2
• Deliver a working web panel
• Based on Requirements Design UI for Web Panel
• Design Database Schema
• Develop API Server
• Implement a cookie tracking algorithm in plugin and backend to track user activity.
Iteration 3
• Revise and update API Server
• Revise and update tracking algorithm

• Integrate WebPanel with ReST APIs
• Implement Multilingual feature on WebPanel

9. Project Management plan
AD PLATFORM ALL Tuesday, 28 March 2017
18
2. Quality Management Plan
There are some potential risks in our project. The first one and considerably the most risky is our
plug-in size. This matters to us because if our plug-in size becomes larger than we thought it can
cause a major defect. This means the larger the code in the plug-in the bigger time it's going to
take from loading the script, grasp the content of the page, send request to the server, to returning
with a related Ad . By the time we display the Ad the viewer might have lost interest or already
left the page with in 2 or 3 seconds.
The second risk is the content identification process. On our proposed system we suggested
contextual customer targeting using AI, meaning our plug-in can display an Ad related to the
website's article concept. Because we are new to AI technologies our algorithm might not be as
efficient as we thought it would be on content analyzing and identification.
The third one is our plug-in compatibility with different browsers. Our plug-in should be
compatible with all browsers, as possible as we can or at least the popular ones. This way we can
be confident that we are reaching out to maximum number of users
Our project management plan to enable quality is to follow these review and testing stages in each
iterations. This processes are going to help us on finding defects and increasing quality
• requirement and design review
• code review
• unit resting
• integration and regression testing • acceptance testing
19
Figure 3 :Gaunt Chart

3. Communication Management Plan
REFERENCE
Type of Method / Frequency/Schedule Information Participants /
Communication Tool Responsibles
Internal Communication:
Daily SCRUM Slack Daily Project status, problems, Scrum Master,
risks, changed requirements Scrum Team
Weekly Meetings Physical Weekly All project documentation and Scrum Master,
reports Scrum Team,
Advisor
Sprint Review Physcal After completion of each Review Sprint, what Scrum Master,
sprint challenges were faced. Scrum Team
Milestone Meeting Teleconfere After completion of each Project status (progess) Scrum Master,
nce MileStone Scrum Team,
Advisor
Final Project Meeting Teleconfere M6 Wrap-up Scrum Master,
nce Experiences Scrum Team,
Advisor
External Communication and Reporting:
Weekly Report Excel sheet Weekly Project status Scrum Master,
Scrum Team,
Advisor,
External Advisors
Project Report Excel sheet Monthly Project status Scrum Master,
- progress Scrum Team,
- forecast Advisor,
- risks External Advisors
Defence Physical Once Defending the project against Scrum Master,
waive of questions from Scrum Team,
Advisors, and teachers Advisor,
External Advisors
Figure 4: Communication Management Plan
20
Ad Platform - SRS
21
Table of Contents
List of Tables
Table 1: Definitions……………………………………………………………………………………………….….…VI
Table 2: Acronyms……………………………………………………………………………………………….….……VI
Table 3: Abbreviations……………………………………………………………….…………………………….…VI
Table 4: Functional Requirement 01……………………………………………………………….……….15
Table 7: Functional Requirement 04………………………………………………………….…….………16
Table 8: Functional Requirement 05…………………………………………………………..…….…….16
Table 9: Functional Requirement 05………………………………………………………………….…….17
Table 10: Functional Requirement 07………………………………………………………………….….18
Table 11: Functional Requirement 08…………………………………………………………………..…18
Table 12: Functional Requirement 09…………………………………………………………………..…18
Table 13: Functional Requirement 10……………………………………………………………………..18
Table 14: Functional Requirement 11……………………………………………………………………..19
Table 15: Functional Requirement 12………………………………………………………………………20
Table 16: Functional Requirement 13………………………………………………………………………20
List of figures
Figure 1: Login Page ………………………………………………………………………………………………… 12
Figure 2: Dashboard Page…………………………………………………………………………………………. 13
Figure 3: Posts Page …………………………………………………………………………………………………..13
Figure 4: Plugin Page ………………………………………………………………………………………………… 14
Figure 5: Use Cases Page …………………………………………………………………………………………… 22
22
1. Definitions, Acronyms, and Abbreviations.

1.1 Definitions
Table 1 Definitions
No. Word Definition
1 Webmaster Website owner, Website Operator, that generates

income from the website he/she operates
2 HelloCash HelloCash is a company that works as a mobile payment

transactor
3 Plugin The code to be install on the webmaster’s webpage
1.2 Acronyms
Table 2 Acronyms
Term Definition
API Application Programming Interface
ReST Representational State Transfer
NLP Natural Language Processing
SRS Software Requirement Specification
FAQ Frequently Asked Questions
1.3 Abbreviations
Table 3 Abbreviations
No. Abbreviation Description
1 Ad Advertisement
23
DECLARATION
We declare that this written submission represents our ideas in our own words and where
others’ ideas or words have been included. We have adequately cited and referenced the
original sources. We also declare that we have adhered to all principles of academic
honesty and integrity and have not misrepresented or fabricated or falsified any
idea/data/fact/source in our submission. We understand that any violation of the above
will be cause for disciplinary action by the Institute and can also evoke penal action from
the sources which have thus not been properly cited or from whom proper permission has
not been taken when needed.
Group No:
Team:
Date: 11-30-2016
24
1. Introduction
The online advertising industry is expanding at an alarming rate, showing 20% jump in
2015 compared to the year before[3]. One very crucial factor for this surge is the ubiquity
of smartphones, which is reported to be 2.1Billion in 2016 [4]. However there are
multiple stakeholders in this very lucrative business. Getting into this business requires
understanding the dynamics of each stakeholder.
Understanding this complication, our team conducted interviews and online

surveys(Google forms) of each stakeholder before going about to ‘specifying the
requirements’. The stakeholders we identified are webmasters (website publishers),
advertisers (businesses) and end users (website visitors). We have conducted targeted
online survey on each stakeholder. And we have also conducted face-to-face interviews.
The Software Requirement is based on the results from the online survey and interview.
1.1 Purpose
The purpose of this SRS document is to accurately specify the requirements for an online
advertising application that will allow advertisers show their product online and
webmasters to make money by showing those ads on their webpage.
1.2 Scope
The system we are proposing to build is an Ad Platform that will place contextually
relevant Ads on websites. Webmasters who will use our platform will benefit from the
slew of features that will make our platform unique. Advertisers will find our platform
an untaped space to advertise their products. Website visitors will find the contextual
ads relevant and informative.
The system to be designed will include: a browser plugin, a web panel, a ReST API
server and NLP server. The web panel will enable advertisers to upload their
advertisements and will find helpful stats. Webmasters will also use the web panel to
find helpful stats about their website. The browser plugin will present advertisements
in a position on a webpage the webmaster desires. The ReST API server will securely
place the Ads and other stats and data generated by the system. The NLP server will do
classification of each webpage that uses our plugin. This will help our system provide
users with relevant ads.
1.3 Overview
The rest of the SRS examines the specification of the Ad Platform in detail. Section 2
of the SRS presents the general descriptions that affect the Ad Platform and its
requirements, such as user characteristics and constraints. Section 3 outlines the
25
detailed, specific functional, performance, system and other related requirements of

Ad Platform. Use cases are also outlined on the 3rd section. Change management
process is provided in section 4.
2. General Description
The Ad Platform we are building is going to have a plugin that will be inserted in web
pages to display ads. Ads will be provided by businesses and advertisement agencies
that will work with us to promote their products and services. They will have a webpanel
that will show them different stats about their ads. The ads appearing on the web-pages
will be content aware, meaning that they will be related to what the user is reading on
the webpage.
2.1 Product Perspective

This system is comparable to the very popular Google AdSense. What sets our product
apart is that, it is designed for Ethiopia.
• One aspect of Google AdSense that most webmasters complain about is the rigorous
selection process that will reject most Ethiopian applicants[according to most of our
online survey responses]. Our system will be an open application.
• Another problem of Google AdSense is that it does not support Local Payment
systems. Our platform will incorporate HelloCash mobile payment system. This will
streamline transactions.
• Our platform will have support for local languages( currently Amharic only).
2.2 Product Functions

The advertisement platform will need perform multiple functions with a great deal of
accuracy in order to achieve serve it’s purpose. We will see the functions in three
categories.
Web Panel
● The web panel will display selected relevant stats for each role. ● The web panel
will enable editing of advertisements.
Plugin
● The plugin will display advertisements of all sizes.
● The plugin will extract page contents and send to backend server.
● The plugin will collect feedback on irrelevant ads.
Natural Language Processing Server
26
● The NLP server will classify web-pages into predefined categories for ad
placement
● The NLP server will learn new set of keywords for each category
2.3 User Characteristics

The users of the system are as follows. Webmasters, advertisers and visitors of web
pages. All users of the system are mostly Amharic Speaking for the expected reach of
the platform.
Depending on the survey we conducted, webmasters are mostly male and range from
20 - 38 years of age. They are also fairly literate, with a minimum of high school
diploma.
Visitors are very hard to characterize as they vastly vary depending on the site they are
visiting. One point to intuitively regard is, topics that one demographic is interested in
does not interest another demographic. For example teenage girls might be interested
in singers, of which is not found interesting by males in their late twenties.
2.4 General Constraints

The system has multiple constraints from each deliverables perspective(Plugin,
WebPanel, ReST API Server and NLP Server).
Plugin
• Size - Has to be less than 10KBs as it needs to be loaded easily even in very slow
connections
• Compatibility - Has to be compatible with all browsers.
• Compatibility - Has to be available to popular Content Management Systems.
(Wordpress, Joomla)
• Ease of use - Has to be easily configurable and Installable.
• Performance - Has to be able to parse contents of the site it is rendered on very
fast, even if the Contents of the site are very large. Needs to have an efficient HTML
parser
WebPanel
• Multilingual - Interface needs to support multiple languages
• Smooth Interactivity - Has to be Single Page App
• Secure - Has to let only authorized personnel access the system.
• Role - Needs to support role based access.
ReST API Server
• Performance - has to have great performance
27
• Easily developable - has to enable the developers to develop easily in face of

changing requirements.
NLP Server
• Accuracy - has to be very accurate at classifying a given webpage to a predefined
category
• Speed - has to be very fast when performing classification task, as the classification
task is realtime.
• Interoperable - has to be able to communicate with the ReST API Server to access
webpages that will be classified.
2.5 Assumptions and Dependencies

One of our biggest assumption is that the mobile payment services that we plan to work
with have a very simple payment interface. We assume that it would be very easy to
integrate into our system.
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
Our Ad Platform will have a very intuitive, ascetically pleasing user interface. The
system will be used by webmasters, advertisers and admins at Ad Platform as well as
webmaster’s site visitors. Advertisers will interface with a web user interface. They will
be able to view status of their advertisement.
Webmasters will interface with a web user interface that able them to view their
payment history and status, account settings and choose the right ad type and formats
for his/her site.
Administrators will be able to manage registered users. They also manage all the Ads
currently available or registered on the system.
Site visitors, since the interface of the ad to be showed on webmaster’s site is part of
our interface, will interface with a web user interface that able them to see the
relevant Ad on the site they are visiting.
28
As specified in the proposal document, the system will have a web app that will be
tailor made for website publishers and advertisers. The user interface requirements will
be as follows.
1. The web app needs to support multilingual features. The web app will have to
support English and Amharic.
2. Every page on the web app needs to load under 2 seconds, as recommended by
google[]
3. The web app needs support a caching mechanism to enable much faster
subsequent page loads.
4. The web app needs to be Progressive. This means that all features on each page
will need to work for every user, regardless of browser choice.
5. The web app needs to be Responsive. This means that every page needs to work
consistently on High Resolution Desktop, Standard Desktop, High Density Tablet,
Tablet, High Density SmartPhone, SmartPhone
6. The web app needs to be connectivity independent. This means that it needs to
work offline.
7. The web app needs to have an application shell architecture. This means that
the application needs to load basic user interfaces (shell) first.
8. The web app needs to be engaging. This means that the web app needs to send
push notifications to the user.
The system has multiple user interfaces, each corresponding to a specific actor of the
system. Broadly classifying the type of user interfaces, we find two kinds.
● The web app used by publishers and advertisers to check their stats and other
info.
29
● The website plugin that will be placed in publisher’s website to display ads.
Figure2 : Dashboard Page.
3.1.1.1 Web-app
The web app will be, as described earlier, used by advertisers and publishers to do all
sorts of things. Each one will be described in detail in the functional requirements
section. The user interfaces will be as follows.
Figure 1: Login Page
30
Figure 3: Posts page
Above were some of the pages in the web-app. Only some were illustrated for brevity
reasons.
3.1.1.2. Plugin.
The plugin is a very critical component of the system. The plugin will show relevant ads
in pages it is plugged in. The ads can be banner ads of different sizes. Or GIFs that will
come to life once the page has loaded.
31
Figure 4: Plugin Page
Another area of concern regarding ads is their placement. We have had multiple
discussions with publishers found in Ethiopia about where they place ads. The most
popular place is below the navigation bar before the content of the page begins. This
is the most clickable as it is the most visible. The next most popular would be, the side
bar. The side bar is very visible to visitors who are mostly focused on reading the
content. They might miss the top ad as what they would be looking for when the page
first loads is the content. Hence they would scroll past the top ad. However the
strategically placed side ad would be unmissable and would be clicked if found relevant
by visitors.
3.1.2 Hardware Interfaces

Our system is a purely software based project, hence we don’t have a specific set of
hardwares that we need to interface with.
32
3.1.3 Software Interfaces The

system shall
1. Communicate with the web user interface to identify all the available
components to configure Ad interface, like the palette
2. Communicate with payment systems provided by vendors like HelloCash and
MBirr to validate and process payment.
3.1.4 Communications Interfaces

Our system shall use the HTTPS protocol for communication over the internet.
3.2 Functional Requirements

The following are functional requirements of the system
Table 4 Functional Requirement 01
ID FR:01
Name Register ads
Summary Advertiser can add new ads
Description The system will allow the

administrator to register new ads.
Reference UC – 01: Register Ads
ID FR:02
Name View Ads
Summary Administrator, Advertiser can view ads

Administrators to view all ad
Reference UC – 02: View Ads
33
ID FR:03
Name Update ads
Summary Administrator, Advertiser can update

ads
Description The system will allow the Administrator

to update Ads
Reference UC – 03: Update Ads
ID FR:04
Name Activate User
Summary Administrator can activate users

administrator to activate users
Reference UC – 04: Activate User
ID FR:05
Name View Payment History
Summary Webmaster, Advertiser and

Administrator can view their Payment
History
Description The system will allow the webmaster to

view his payment history
34
Reference UC – 05: View Payment History
ID FR:06
Name Manage Users
Summary Adminstrator can manage users
Description The system will allow the webmasters

to customize Ads.
Reference UC – 06: Customize Ads

ID FR:07
Name Choose ad Types and formats
Summary Webmaster can choose ad types and

formats
Description The system will allow the webmaster

to choose Ad types and formats
Reference UC – 07: Choose Ad Types and formats
ID FR:08
Name View ad Status
Summary Advertiser can view Ad status
Description The system will allow the advertiser to

view his Ad status
Reference UC – 08: See Ad Status
35
ID FR:09
Name Click ads
Summary Site Visitor can click on ad and will be

redirected
Description The system will allow the Site Visitor

to click on ad
Reference UC – 09: Click Ads
ID FR:10
Name Create Account
Summary Users, webmasters and advertisers,

can create their account.
Description The system will allow the users to create

an account.
Reference UC – 10: Create Account
ID FR:11
Name Authenticate User
Summary The System can authenticate users

with valid account.
Description The system will allow the users to be

authenticated.
Reference UC – 11: Authenticate User
36
ID FR:12
Name Update Profile
Summary Users (administrator, webmaster and

advertisers) can update their profile
Description The system will allow the users to

update their profile.
Reference UC – 12: Update Profile
ID FR:13
Name Reset Password
Summary Reset forgotten password
Description The system will allow a user to reset

password.
Reference UC – 13: Reset Password

ID FR:14
Name Fraud Detection
Summary The system shall detect fraud

requests.
Description The system shall detect fraud

requests.
ID FR:15
Name Contexually Aware
37
Summary The ad shown shall be contextually

aware.
Description The ad shown shall be contextually

aware.
ID FR:16
Name Contexually Aware
Summary The ad shown shall be contextually

aware.
Description The ad shown shall be contextually

aware.
ID FR:17
Name View ads
Summary Site visitors shall view ads where the

plugin is placed.
Description Site visitors shall view ads where the

plugin is placed.
38
3.3 Use Cases

In order to list all the use cases we first identified the needs to be fulfilled by the
system.The following needs must be addressed by the system
• Webmaster actor needs to use the system to register for ad account

• The webmaster actor needs the system to generate his status
• The advertiser actor needs the system to follow his advertisement status
• The visitor actor need the system to redirect him to the original advertisement
• The admin actor need the system to track user’s information
Based on these needs, the following use cases have been identified
• Register for Ad Service

• Update Ad
• View ads[Administrators]
• Create user account
• Update profile
• Authenticate user
• View Payment History
• Customize ad
• Choose ad types and formats
• View Ad Status[for Advertisers]
• Click ads
• Activate User
• Reset password
Actors
The following are actors identified in the Ad Platform system
• Webmaster – represents webmasters owning a website and who agreed to serve Ads
on their page.
• Advertiser – represents an individual or a group who wants to advertise his product
or work online by the use of our system
• Administrator – represents the web administrator
• Site visitor - represents a site visitor who can reach webmaster’s page and have an
opportunity to click on the advertisers targeted to him/her on that page.
39
Figure 5 : use case diagram for ad platform system
40
3.3.1 Use Case Specification for Register Ads

Name: UC-01:Register Ads
Actors : Administrator
Description : enable the administrator to add new Ads
Precondition :the administrator has successfully logged into the system
Flow of events
S1. The administrator wants to add a new Ad
S2. The administrator clicks on the “Add new Ad” link
S3. The system checks that the entered information is correct
S4. The system verifies that the entered information is valid
S5. The system add the Ad
S6. The use case ends
Alternative A: the entered information is incorrect
S1. The system verifies that the entered information is incorrect S2.
The system informs the user to re-enter the incorrect information S3.
The user enters the information and clicks on the “Add” button.
S4. The use case resumes at step 3 of the basic Flow of events
Post condition: payment history is displayed to webmasters
3.3.2 Use Case Specification for View Ads

Name: UC-02:View Ads
Actors: Administrator
Description: enable the Administrator view all ads available
Precondition: the administrator has successfully logged into the system
Flow of events
S1. The administrator wants to see all ads
S2. The administrator clicks on the “view ads” link
S3. The system displays the ads
Post condition: All Ads are displayed to administrator
3.3.3 Use Case Specification for Update Ads

Name: UC-03:Update Ads
Description: enable the Administrator to update ad information
Flow of events
S1. The administrator wants to update ad
S2. The administrator clicks on the “update ad” link
S3. The system displays the list of ads which are registered.
41
S4. The administrator selects an ad to s/he wants to update and clicks “Edit”
button.
S5. The system displays the detail of the selected ad
S6. The administrator updates the ad information and clicks “Save” button.
S7. The system checks that the entered information is correct.
S8. The system updates the ad information and displays a confirmation message
to the administrator.
Alternative A: administrator clicks on the “Delete” button.
S1. The administrator clicks on the “Delete” button.
S2. The system displays a confirmation request.
S3. The administrator confirms to delete the ad from the system.
S4. The system deletes the ad from the system and displays a confirmation
message to the administrator.
Alternate A.1: the administrator confirms not to delete the ad
S1. The administrator confirms not to delete the ad
· Alternative B:the entered information is incorrect
S1. The system finds that the entered information is incorrect
S2. The system informs the administrator to re-enter the incorrect information
S3. The administrator enters the correct information and clicks the “Save”
button.
S4. The use case resumes at step 7 of the basic Flow of events.
· Post condition: All Ads are displayed to administrator
3.3.4 Use Case Specification for Activate user

Name: UC-04:Activate user
Description: enable the Administrator to activate users (Webmasters and Advertisers).
Flow of events
S1. The administrator wants to activate users
S2. The administrator clicks on the “Activate Users” link S3.
The system displays users waiting for activation.
S4. The administrator selects a user/users and clicks “Activate now” button. S5.
The use case ends
Postcondition: a user is activated and granted for privileged access.
3.3.5 Use Case Specification for View Payment History

Name: UC-05:View Payment History
42
Actors: webmasters
Description: enable the webmasters view their payment history
Precondition: the webmaster has successfully logged into the system
Flow of events
S1. The webmaster wants to see a payment status
S2. The webmaster clicks on the “view payment history” link
S3. The system displays the payment history
Post condition: payment history is displayed to webmasters
3.3.6 Use Case Specification for Customize Ads
Name: UC-06:Customize Ads
Actors: webmasters
Description: enable the webmasters to customize Ad
Precondition: the webmaster has successfully logged into the system Flow
of events
S1. The webmaster wants to customize ads displayed on his site
S2. The webmaster clicks on the “customize ads” link
S3. The system displays the customization settings
S4. The webmaster enters/selects correct information and clicks “Save
Customization” button.
S5. The system registers the customization settings and displays a confirmation
message to the webmaster.
· Post condition: the look of ads is matched to webmaster’s site.
3.3.7 Use Case Specification for Choose Ad Types and formats

Name: UC-07:Choose Ad Types and formats
Actors: webmasters
Description: enable the webmasters to choose Ad types and formats
Precondition: the webmaster has successfully logged into the system
Flow of events
S1. The webmaster wants to choose ad types and formats to be displayed on his
site
S2. The webmaster clicks on the “choose ad types and formats” link
S3. The system displays the available ad types and formats
S4. The webmaster enters/selects correct information and clicks “Save type and
formats” button.
S5. The system registers the type and format settings and displays a confirmation
message to the webmaster.
Post condition: Chosen Ad types and formats are displayed on the webmaster’s site.
43
3.3.8 Use Case Specification for See Ad Status

Name: UC-08:See Ad Status
Actors: Advertiser
Description: enable the Advertiser view their ads status
Precondition: the Advertiser has successfully logged into the system
Flow of events
S1. The Advertiser wants to see an ad status
S2. The Advertiser clicks on the “view ad status” link
S3. The system displays the status of ads
Post condition: status of ads is displayed to Advertiser
3.3.9 Use Case Specification for Click Ads

Name: UC-09:Click Ads
Actors: Site Visitor
Description: enable the Site Visitors click the targeted ads
Precondition: the Site Visitor has to visit one of registered webmaster’s sites.
Flow of events
S1. The Site Visitor wants to see original/full advertisement
S2. The Site Visitor clicks on the ad content/area
S3. The system asks information about the user and sends a confirmation if s/
he is not a robot.
S4. The Site Visitor enters his correct information and confirms s/he is not a
robot then click on the “Continue” button
S5. The system registers user information
S6. The system increments a click count for the owner of the site.
S7. The system redirects the user to the origin of the advertisement. S8.
The use case ends
S1. The system finds that the entered information is incorrect
S2. The system informs the Site Visitor to re-enter the incorrect information.
S3. The Site Visitor enters the correct information and clicks “continue” button.
Post condition: status of ads is displayed to Advertiser
3.3.10 Use Case Specification for Create Account

Name: UC-10:Create Account
Actors : Users( webmaster and advertiser) Description
: enable the users to create an account Precondition:
the user has to visit our web site.
44
Flow of events
S1. The user wants to create an account.
S2. The user clicks on the “Create Account” link
S3. The system displays the “Account Creation Form”.
S4. The user enters the user information and clicks “Create Account” button.
S6. The system checks that the user name is in use by another user.
S7. The system sends an email confirmation request to the user S8.
The user confirms the request and click “Continue” button.
S9. The system creates user account and displays confirmation message to the
user.
S10. The use case ends.
Alternative A: the update information is incorrect
S1. The system finds that the user information is incorrect
S2. The system informs the user to re-enter the incorrect information. S3. The
user enters the correct information and clicks “Create Account” button.
Alternative B: the user name is in use
S1. The system finds that the user name is in use by another user
S2. The system informs the user to try another username
S3. The user enters the user name
S4. The use case resumes at step 6 of the basic Flow of events. Postcondition:
a new user account is created on the system.
3.3.11 Use Case Specification for Authenticate user

Name: UC-11:Authenticate user
Actors: Users( Administrator, webmaster and advertiser)
Description: enable to authenticate a user who wants to access Ad Platform System
Precondition: the user has valid account of Ad Platform System and the user views the
home page of the system.
Flow of events
S1. The user wants to login to the system
S2. The user provides his username and password S3.
The user clicks on the “Login” button.
S5. The system checks that the login information is valid S6.
The system grants access to the user.
S1. The system finds that the user information is incorrect
S2. The system informs the user to re-enter the incorrect information.
S3. The user enters the information and clicks the “Login” button.
45
Alternative B: the login information is invalid
S1. The system finds that the login information is invalid S2.
The system informs that no such user exists.
S3. The system informs the user to try again.
S4. The use case resumes at step 5 of the basic Flow of events. Post
condition: the user is granted access to the system.
3.3.12 Use Case Specification for Update Profile

Name: UC-12: Update Profile
Actors: Users(Administrator, webmaster and advertiser)
Description: enable the users to update his/her profile
Precondition: the user has successfully logged into the system.
Flow of events
S1. The user wants to update his/her profile
S2. The user clicks on the “Update Profile” link
S3. The system displays the detail profile of the user.
S4. The user updates the information s/he wants to change and clicks “Save”
button.
S5. The system checks that the update information is correct
S6. The system updates his/her profile and displays a confirmation message to
the user.
Alternative A: the update information is incorrect
S1. The system finds that the update information is incorrect S2. The
system informs the user to re-enter the incorrect information.
S3. The user enters the correct information and clicks “Save” button.
S4. The use case resumes at step 5 of the basic Flow of events. Post
condition: user profile is updated.
3.3.13 Use Case Specification for Reset Password

Name: UC-13 : Reset Password
Actors: Registered users of the system (Administrator, Webmaster and Advertiser)
Description: enable the users to reset their password
Precondition: user is on the login page and has an account
Flow of events
S1. The user wants to reset his forgotten password
S2. The user clicks on the “forgot password” link
S3. The system displays a form that allows the user to fill the username
S4. The user enters username
S5. The system displays the account
S6. The user selects the account
46
S7. The system displays reset option

S8. The user selects “Reset with email” button
S9. The system sends a password reset link to a previously registered email
S10.The user follows the link and reset new password
S11.The user enters reset information and clicks “Reset” button.
S12.The system checks that the entered information is correct
S13.The system resets his/her password and displays a confirmation message to
the user.
S14.The use case ends
Alternative A: the reset information is incorrect
S1. The system finds that the reset information is incorrect
S2. The system informs the user to re-enter the incorrect information. S3.
The user enters the correct information and clicks “Reset” button.
S4. The use case resumes at S12 of the basic Flow of events.
Post condition: user password is changed.
3.4 Non-Functional Requirements
3.4.1 Performance
• The system must be interactive.
• The system should be able to load Ads to websites with minimum delays possible but
this depends on the speed of the internet .
• The system shall be based on web and run from web server.
• Identifying the websites article type and identifying related Ad needs to be fast.
• Webmasters and Advertisers should be able to see report statistics with minimum
delay possible.
3.4.2 Reliability
The system needs to detect failures by sending an information of verification to our
server. One of the failure we expect will be caused by slow internet connection. Failure
to show an Ad on the websites mean we are losing customers (Advertisers are not
advertising, webmasters are not getting money). In order to avoid this failure, in
addition to verification, our plugin needs to be very small in size, so that it can be
loaded easier even in slow connections. The system should load Ads when loading the
page or after receiving in less than 30 seconds.
The system needs to update statistics reports with minimum delays possible which is in
less than 60 seconds. A failure to update these reports will cause data inconsistency
between webmasters and advertisers. By catching every connection error statuses, we
can make sure the data is updated properly on time.
47
The system needs to show a related Ad to the websites article. There might be a failure
to know the website’s content. In this case, we can show a related Ad with a general
topic.
3.4.3 Availability
The system will be available 24/7. But If the internet service gets disrupted while
sending information to the server, the information can be send again for verification.
3.4.4 Security
The main security concern is for the webmasters and advertisers admin panel. Providing
an account with proper authorization mechanism should be used to avoid hacking. Only
authorized users can access the system. The authorized users are the ones who have
their own user accounts offered by the system. The other major concern is making a
money transaction for webmasters. Hence proper transaction mechanism should be
used to avoid hacking.
3.4.5 Maintainability
To ensure maintainability we designed the system’s architecture in a more flexible
way.For future maintenance the code should be understandable. This means, the code
needs to be readable, naming conventions should be followed and self-descriptive
and/or well commented.
The application needs to be tested in different types of testing mechanisms(like unit

testing, integration testing).The system needs to offer a help section for users, for a
greater understanding of the platform, especially for webmasters and advertisers.
3.4.6 Portability
The system needs to be available any time, any place, where there is available internet.
The plugin needs to be compatible at least with all the popular web browsers. Since it
is web based platform it can be accessed through devices like tablets, mobile phones
and desktop/laptop computers. This means, the platform can be accessed in every
operating systems using web browsers.
3.5 Inverse Requirements

• The system needs only to analyze, the website’s article context to show related
Advertisement, for articles in English language.
• The system doesn’t target customers or article readers based on their experience
or it isn’t structured to have behavioral customer targeting. This means it
doesn’t consider past or current experience of the website's users to recommend
advertisement products. Only needs to see the content of the websites they are
reading.
48
• The system doesn’t include an account for the website readers. It only have
account management for the webmasters and advertisers. As it drive away
customers and the system never going to use user's profile data.
3.6 Design Constraints
The design constraints we have are mostly related to the NLP Server. This server as
stated earlier will classify web pages based on the predefined categories. In order to
do this classification the server needs training data to be defined on each category.
Type of the training data and how the NLP server can process that training data is a
constraint that we will design based upon.
If we have sufficient training data, our system will perform well, if not it won’t. Hence
this is an external design constraint. Also the definition of each category is directly
dependent on the ease of which training data can be found for that category. We don’t
want to define a category that training data can’t be found for.
Another design constraint is the nature of the training data itself. The nature will
directly affect the processing algorithms we will design for the data. It will also affect
the NLP Server’s classification process.
For example lets assume the training data is a set of keywords that are related to each
category. Hence the classification process might be matching the words in the webpage
with the keywords for each category. The category with the most matched words will
be the category of the webpage.
Another design constraint is the nature of websites. Websites that we will process to
classify/categorize. More specifically the nature of the publishers that publish articles
on those websites. For example the lexical diversity of the articles. These factors will
affect the design of the NLP server. We will need to design a comprehensive algorithm
to do the classification task efficiently.
3.7 Logical Database Requirements

Our system will use databases extensively to store all kinds of data. From the very basic
Ads to others like stats on payment, user’s behaviour and on Ads. This means that the
database needs to handle concurrent writes efficiently.
Taking a single request from a website visitor for example. First the plugin installed on
the website will collect stats about the site and send the stats and also contents of the
website to the ReST API Server. The server will persist all the data and send contents
of the page to the NLP Server. Just in this process there have been multiple writes to
the database. Hence the database we would use needs to be able to handle all this
writes without compromising performance.
49
2
ADAD PLATFORM
PLATFORM SRS
SRS
1 | Page
32
AD PLATFORM SRS
3.8 Other Requirements

Training-related Requirements
There is no training to begin the platform for the users but there is some training to the
website masters to insert the plugin into the website.
Packaging Requirements
The system is a web-based application and it will contain file formats, which come with
the web discipline. To specify a few of these, “.HTML”, “.CSS”,”.JS” ,”.PY” and
“.JSON”, “Read me” text file which are going to be contained within a folder.
Legal Requirements
By know there is no copyright laws and license agreements because in Ethiopia the idea
in not patented but at the end of the project there is a copyright laws and license
agreements.
4. Change Management Process

To incorporate ad hoc changes in the requirements and to see if proper changes to the
system meet the requirements, change management process will be done iteratively
with all the activities, the following strategy will be followed.
The Stakeholder (i.e. our advisor, evaluator, team member) will identify a new
requirement or a modification in a requirement and communicate it to the team lead
(i.e. our scrum leader) via email or to the entire team in a meeting. The team will
assess the feasibility of the proposed change considering the time constraints and
structural constraints of the implemented modules and develop an implementation
strategy and submit it to the mentor for approval. A change plan will be created for the
implementation of the change and following sequences of the changes is determined.
The team will then continue implementing the new requirements. Then testing will be
done on the new programmed system. During the testing phase, the product will be
tested for satisfying the requested changes. After the changes have been done, update
will be made to documentation also. The changes will then be verified for the last time,
and a new release will be made.
2 | Page
Ad Platform - Software Design Specification
3 | Page
4 | Page
1.Introduction
1.1 Purpose
The Advertisement industry is a very complicated industry with multiple stakeholders.

Each stakeholder has a unique contribution to the survival of the industry. When we
approached the design of this system, it was done so taking this crucial fact into
consideration. The purpose of this document is to translate the business requirements
we identified in the SRS document and also business processes into technical design
that will be used to develop the application.
This document is intended for anyone interested in understanding the design and
architecture of our system, who has experience reading UML diagrams which include
but not limited to sequence diagrams, class diagrams, component diagrams. This
document includes but is not limited to the following information for the Ad Platform;
system overview, system architecture, object model and detailed system design.
1.2 General Overview
Ad Platform is, as its name suggests, a platform where businesses will be able to
advertise their products and services. A platform that will enable web publishers
monetize their websites by letting us advertise on their platform. The ‘Ad Platform’
name is merely a developmental project name and in no ways reflects the final name
for the product. We might change the name of the project if necessary and we will
identify the change that were made and why.
The system has to be able to do main three tasks efficiently; in order to accomplish its
business requirements. The three tasks are, delivering ads; collecting analytics, analyze
and classify webpages. The system architecture is designed with these tasks in mind.
The system has four main subsystems; Ad Delivery Network, WebPage Classifier, Cross
System Analytics Repository and Website Plugin. Each subsystem is providing
functionality for one of the tasks listed above.
1.3 Goals
Some of our goals when designing the system are listed in this section. The major goal
of the Ad Platform is to cater to the end user with relevant ads that will encourage the
5 | Page
user to interact with the ad without being intrusive. In order to satisfy this we have
devised the WebPage Classifier subsystem of which it’s sole purpose is to classify
webpages from a wide variety of categories. After the webpage is classified, ads in a
similar category will be displayed on that webpage.
The second major goal of the ad platform is to collect as many relevant stats as possible
and provide publishers and advertisers with all the information they need to make
informed decisions. In order to do this we have designed the Cross System Analytics
Repository subsystem; whose sole purpose is to collect stats from the plugin, store them
securely and do some relevant analytics.
The third goal is to make the user interface as intuitive as possible to all actors on the
system. This goal specifically refers to the web panel and plugin. A web panel that
website publishers and advertisers will use to view stats, ads and more. Since the web
panel is the primary way for all actors to interact, it has to very user friendly. To
accomplish this goal we are using rich client side javascript libraries to enhance the
user experience. We also hope to support multilingual functionality.
This design attempted to separate the main functionalities into separate subsystems.
This is done so in part to increase performance of the system. We believe performance
will increase as each subsystem will be independent of the other. For example, The
system can deliver ads and at the same time collect stats about the webpages those
ads are being displayed in. This is also a critical feature when scalability is considered.
1.4 Development Methods & Contingencies
In order to coup with the complexity and changing nature of our system; we have stated
in our proposal document that our approach for design and development of our system
is RAD and specifically SCRUM.
Choosing such an approach enables us to look at the requirements from a different
perspective, which is that they are ever changing. This means that during development,
we are able to entertain requirement changes that are essential to the system. We have
planned, as we stated in our proposal document, to do at least three iterations. With
each successive iteration we will incorporate change to requirements .
2.System Architecture
2.1 Architecture Design Considerations

This section will provide an outline of the various components and subsystems of the Ad
Platform system. As stated in the previous section, the system has four main
6 | Page
subsystems. This section will present each subsystem in a multitude of diagrams. We
have also stated the rationale behind each subsystem. In this section we will go over
some design considerations taken into consideration when designing the system
architecture.
The main design consideration that went into the Website Plugin is minimization of it’s
size. The size needs to be as small as possible, in order to be loaded on browsers even
in low internet connections. When size is a constraint, every feature that is considered
to be added needs careful consideration. If a feature is not absolutely essential it
cannot be added.
The ad delivery network’s main design consideration is speed of delivery. Every request
to this server needs to be analyzed and classified by another subsystem that this
subsystem works closely with. That subsystem is the WebPage classifier. But subsequent
requests made for a certain webpage need to be cached, because it is highly unlikely
that webpages get updated very often. Hence this subsystem has a caching mechanism
that makes the system more efficient and fast.
The WebPage analyzer subsystem works closely with the ad delivery network to classify
webpages. Its sole task is analysis of webpages, isn’t concerned with caching. The
webpage classifier implements Natural Language Processing Algorithms to effectively
extract topic from a webpage. To do so it relies on a set of keywords that are collected
for each topic. Hence the main design consideration for this subsystem is getting
smarter upon each classification. This subsystem will learn new keywords and will be
better at classification.
The main design consideration for the Cross System Analytics Repository is data
independence. What we mean by that is the stats that are collected on each Ad or User
should be represented in a general manner. Hence when designing the persistence for
this subsystem, we devised a type specification mechanism where all the stats are
represented in just two tables. One for the type of the stat and another for the stat
itself.
Figure 1 System architecture
7 | Page
2.1Subsystem decomposition
In this section we will dive deeper into each subsystem and show their internal
components using UML 2.0 Component Diagrams. We have shown diagrams for all
subsystems except the WebPage Classifier subsystem, of which its details haven't been
finalized yet.
Figure 2 Website Plugin Network Component Diagram
8 | Page
Figure 3 Ad Delivery Network Component Diagram Figure 4 Cross System Analytics
Repository Component Diagram
1 | Page
2.2 Hardware/software mapping UML
Deployment diagram.
Figure 5Deployment Diagram
3. Object Model
3.1 Class Diagram
We have provided a Unified Modeling Language (UML) based type of static structure
diagram that describes the structure of our system by showing the system's classes,
their attributes, operations (or methods), and the relationships among the classes. Note
2 | Page
that for each class minimum number of properties are specified. Because unnecessary
properties will make the diagram complicated.
3.1.1 Advertisement Class Diagram
Figure 5 Advertisement class Diagram
3.1.2 Storage class Diagram
Figure 5 Storage class Diagram
3 | Page
3.1.4 User subsystem class Diagram
Figure 7 User class Diagram
4 | Page
3.2 Sequence Diagram
This Section shows how processes operate with one another and in what order. We
depict the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.
3.2.1 Accounts System
3.2.1.1 The system should allow users to login
5 | Page
Figure 8 sequence diagram - login
6 | Page
7 | Page
3.2.1.3 The system should allow users to register an account
Figure 10 Sequence Diagram for register an account
3.2.1.4 The system should allow users to update their account

Figure 11 Sequence Diagram for update an account
8 | Page
9 | Page
3.2.1.5 The system should allow users to reset their password
Figure 12 Sequence Diagram for reset password
3.2.1.7 The system should allow the administrator to delete user account
Figure 14 Sequence Diagram for delete user
10 | Page
3.2.2 Advertisement System
3.2.2.1 The system shall allow the advertiser to add new advertisement
Figure 15 sequence diagram – add new Ad
11 | Page
3.2.2.2 The system shall allow the advertiser to update advertisement
Figure 16 Sequence Diagram for update ad
12 | Page
3.2.3 User data System
3.2.2.1 The system shall allow the advertiser to view his ad status
13 | Page
Figure 18 Sequence Diagram for view ad status
14 | Page
3.2.3.3 The system shall allow the webmaster to choose ad types and formats
Figure 20 Sequence Diagram for choose ad type and formats
3.3 State chart Diagram (optional element) We

have no an object that can be in many states.
4. Detailed Design
15 | Page
The classes represented here are the ones identified on our class diagram. And we have
also add the methods and classes identified in sequence and state chart diagram.
4.1 Detail Design for User Class

Table: 4 User class
User
+name: String
- password: String
+address: String
-email: String
-id: String
-status : ENUM
+createAccount()
+activateUser()
+updateProfile()
+resetPassword()
+logout()
+deleteUser()
16 | Page
Table: 5 Attributes description for User class
Attribute Type Visibilit Invariant
y
name: String Public Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.
password String Private password <> NULL must be at least 6 characters that
combines digits, numbers
address String Public address <> NULL and it must be between 12 to 20
characters
Email String Private Email <> NULL
✓ Must contain @
✓ Must contain. (dot)
✓ Position of @ >1
✓ Position of (dot)>position of @ + 2
✓ Position of (dot)+3<= total length of email
address and the total character of the Email is at
least 5 characters
status ENUM Public Status <> NULL and it must be of on the state of
“Active” or “Passive” with default value of “Passive”
Table: 6 Operation description for User class
Operation Visibility Return Argument Pre-Condition Post Condition

type
17 | Page
createAccount() Public Void . The clients The clients
p e r s o n a l p e r s o n a l
information information
shouldn’t exist should exist
activateUser() Public Void .user: id User that matches User account
w i t h t h e i d should be active
shouldn’t be
activated yet
updateProfile() Public Void User: id User wants to User account
update his should be
account updated
deleteUser() Public Void User : id Administrator User with the

wants to delete a specified id
user and user with shouldn’t exist
the specified id
should exist
4.2 Detail Design for Advertisement Class

Table: 7 Advertisement class
Advertisement
+name: String
+ CategoryId: integer
+CampaignId: integer
-path: String
-id: integer
-status : ENUM
+ regiaterAd()
+ activateAd()
+updateAd()
+customizeAd()
+showPaymentStatus()
+viewAdStatus()
+viewAllAds()
+clickAd()
18 | Page
Table: 8 Attributes description for Advertisement class
Attribute Type Visibilit Invariant

y
name: String Public Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.
category_id Integer Public Categoty_id <> NULL and it is foreign key mapping to
category of advertisements
campaign_id Integer Public Campaign_id <> NULL and it is foreign key mapping
to campaign advertisements created by a specific
advertiser
path String Public Path <> NULL and must be working URL address that
redirects to the origin of the advertisement
status ENUM Public Status <> NULL and it must be of on the state of
“Active” or “Passive” with default value of “Passive”
Table: 9 Operation description for Advertisement class
Operation Visibility Return Argument Pre-Condition Post Condition

type
registerAd() Public Void . Advertiser wants t N e w

oaddnew advertisement
advertisement should exist
19 | Page
activateAd() Public Void .Ad: id Ad that matches Ad should be
w i t h t h e i d s h o active
uldn’tbe
activated yet
updateAd() Public Void Ad: id Advertiser or Ad should be

owner of the Ad updated
with the id n u m b
e r “ i d ” wants to
update the Ad
customizeAd() Public Void User : id Webmaster wants Ads should be

tocustomize displayed on the
Advertisements webmaster ’s site
which displays in based on t h e
his page customization.
4.3 Detail Design for Storage Class

Table: 10 Storage class
Storage
-userId: String
- adId: String
-webmasterId:String
-transactionId:String
-transactionDate:DateTime
+adClicks:integer
+adImpression:integer
+transactedMoney:Double
+adlikedGeography:List<Double>
20 | Page
Table: 11 Attributes description for Storage class
Attribute Type Visibility Invariant
userId String Private userId <> NULL, is a foreign key must be

referentially integrated with the user table ID
adId String Private adId<> NULL, is a foreign key must be
referentially integrated with the user table ID
transactionId String Private transactionId<> NULL, is a foreign key must
be referentially integrated with the user table
ID
transactionDate DateTime Public transactionDate <> NULL
• Must be the exact time of when that
transaction made
• with now() insert property
adClicks: Integer Public adClicks<> NULL
adImpression Integer Public adImpression<> NULL
adLikedGeography List<Double> Public adLikedGeography <> NULL

• should be in longitude, latitude format
transactedMoney: Double Private transactedMoney<> NULL
• depends on adClicks and
adImpression, or calculated using
adClicks and adImpression
21 | Page
Table: 12 Operation description for
Storageclass
Operation Visibili R e t u r n Argument Pre-Condition Post Condition
ty type
getUser() Public U s e r user : Id user must login

object User should
exist
getAd() Public Ad object .Ad: id user must login
The Ad should
exist
updateAdStatus( Public bool • Ad: id The Ad should Ad status
) • Integer:adImp exist should be
ression The updated
• Integer:adClic Advertisement Users(Advertise
ks should be r and publisher)
• List<double> displayed on a could see
: publisher notifications
adLikedGeog website The transaction
raphy money will be
• Webmaster:id calculated
The
Advertisement
should be
Clicked to
update the like
status
getAdStatus() Public AdStatus User : id user must login
object The Ad should
exist
The Ad status
should exist
updateAdTranact public bool • Ad: id The Ad should Ad transaction
ion() exist should be
We b m a s t e r updated
Ad:adClicks should be Users(Advertise
Ad:adImpression registered r and publisher)
DateTime:transact could see
ionDate notifications
Webmaster:id
22 | Page
getAdTransactio public AdTransa Webmaster:id user must login
n() c t i o n Ad: id
Object
updateAdTopic() public bool Ad: id The topic New Ad topic
String:topic should be new will be
available.
The Ads should
categorized
using the
updated topic
lists
getAdTopic() public string Ad:id user must login
The Ad should
exist
REFERENCE
[1] Mark Truss (2015, September 14). Digital adver,sing spending

worldwide from 2012 to 2018 (in billion U.S. dollars).
Retrieved from hgps://www.staDsta.com/staDsDcs/237974/online-adverDsing-
spending-worldwide/
[2] Internet Live Stats (2016,July 14). Ethiopia Internet Users.
Retrieved From hgp://www.internetlivestats.com/ internet-users/ethiopia/
[3] Dave , Chaffey (2016, Mar 10). Global social media research
summary 2016. Retrieved from hgp:// www.smarDnsights.com/social-
media-markeDng/social-media-strategy/new-global-social-media-research/
[4] Jack Nikas, (2016, July 28) Google Profits Surge on Strong Ad
Demand. Retrieved from. Retrieved from
hgp://www.wsj.com/arDcles/google-profits-surge-on-strong-ad-demand-1469736762
[5] W3Techs, ( 2012, August 25) Usage of adver,sing networks
for websites. Retrieved from hgps://
w3techs.com/technologies/overview/adverDsing/all
[6] support.google.com , (2014, October 13) AdSense Ad limit
per page. Retrieved from hgps://
support.google.com/adsense/answer/1346295?hl=en#Ad_limit_per_page
[7] Google Form 10-Q, (2010 ,July 15) . Retrieved from
hgp://investor.google.com/documents/ 20100630_google_10Q.html
[8] Mark Irvine, (2016, Oct 12). Average Cost per Click by
Country: Where in the World Are the Highest CPCs?
.Retrieved from hgp://www.wordstream.com/blog/ws/2015/07/06/average-cost-
per-click
[9] Deepa Seetharaman, (2016, July 27). Facebook Posts Strong Profit and
Revenue Growth. Retrieved from
hgp://www.wsj.com/arDcles/facebook-posts-strong-profit-and-revenue-growth-
1469650289
[10] wikipedia.org (2016, Nov 10). Scrum (soQware development). Retrieved
from hgps://en.wikipedia.org/ wiki/Scrum_(sopware_development)
[11] A survey on “AN ARCHITECTURE OF INTERACTIVE WEB ADVERTISING
SYSTEM” by Hsiangchu Lai and Tzyy-Ching Yang from Department of
Information Management, National Sun Yat-sen University, Taiwan, R.O.C
[12] SDS document of Autistic Conversational Skills Software by Wei Lin

Web resource
[13] http://www.tutorialspoint.com/uml/index.htm at December 31, 2016

All in One

Uploaded by

Copyright:

Available Formats

You might also like

All in One

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

All in One

Uploaded by

Copyright:

Available Formats

Addis Ababa Institute of Technology

Center of Information Technology and Scientific Computing

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING Page ! 1

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 2

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 3

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 4

Figure 1: Digital Audience Penetration vs Engagement of Leading

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 5

The main disadvantages of Google AdSense are the following.

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 6

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 7

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 8

• to develop a plugin that is can display ads on pages it is plugged into.

• to develop a plugin that can surpass ad-blockers.

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 9

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 10

Ad Admins/Our System will able to

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 11

ads on specific websites that you choose o Show

ads based on user interest o Show ads on pages

about specific subjects o Show ads where your

customers are located

o Text Ads: Includes a headline, two lines of text

(35 characters each), and a URL. o Image Ads:

include relevant images, customized layouts and

o Rich Media Ads o

• Block webmasters ad account

• Handle cautions: send warning for fraud clicks

• Insert our ad JavaScript code into his/her webpage.

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 12

• Account management o Account Settings o Address

• Payments o Payment process o Form of payment

• Policies End users

• Click on ads shown on the site of their interest

“Scrum is an iterative and incremental agile software development framework for

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 13

• Payment service providers

• ReST API Server

• Information Extraction Server

• Compatibility - Has to be compatible with all browsers.

• Compatibility - Has to be available to popular Content Management Systems.(Wordpress, Joomla)

• Ease of use - Has to be easily configurable and Installable.

• Smooth Interactivity - Has to be Single Page App

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 14

• Role - Needs to support role based access.

ReST API Server

• Easily developable - has to require small development effort.

• Research on Plugin Implementations.

• Deliver a working web panel

• Based on Requirements Design UI for Web Panel

• Design Database Schema

• Develop API Server

• Revise and update tracking algorithm

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 15

• Implement Multilingual feature on WebPanel

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING ! 16

2. Quality Management Plan

Figure 3 :Gaunt Chart