University: Ar-Rasheed University

Major: Cyber Security

Year: 3rd Year, First Semester
Subject: System Analysis and Development

Olympic Unity

Members:
1- Humam Al-Dhubhani
2- Eyad Aqlan
3- Hashem Noman
4- Yousef Al-Moghalis
5- Mohammed Al-Zomor

1
Table of Content
Table of Content ........................................................................................................................................... 2
Table of Figures ............................................................................................................................................ 4
Table of Tables ............................................................................................................................................. 4
1. Chapter 1 .............................................................................................................................................. 5
1.1 Introduction:.................................................................................................................................. 6
1.2 System Idea: .................................................................................................................................. 6
1.3 Problems That the System will seek to address: ........................................................................... 6
1.4 The Opportunities Offered by the System: ................................................................................... 6
1.5 Goals That the system aims to achieve: ........................................................................................ 7
1.6 Project Importance: ....................................................................................................................... 7
1.7 System Development Methodology: ............................................................................................. 8
1.8 Detailed project plan ..................................................................................................................... 9
1.8.1 Time Table: ........................................................................................................................... 9
1.8.2 Tasks In Detail: ..................................................................................................................... 9
1.8.3 GANTT Diagram: ............................................................................................................... 10
1.8.4 PERT Diagram: ................................................................................................................... 11
1.9 Feasibility study .......................................................................................................................... 12
1.9.1 Technical Feasibility: .......................................................................................................... 12
1.9.2 Economic Feasibility........................................................................................................... 13
1.9.3 Operational Feasibility ........................................................................................................ 14
2. Chapter 2 ............................................................................................................................................ 15
2.1 Introduction:................................................................................................................................ 16
2.2 Data Gathering: ........................................................................................................................... 16
2.2.1 Reading and Analyzing documents:.................................................................................... 16
2.2.2 Interviews ............................................................................................................................ 18
2.2.3 Similar Systems................................................................................................................... 21
2.3 Story Telling: .............................................................................................................................. 24
2.4 Requirement and specifications: ................................................................................................. 25
2.4.1 Functional Requirement .......................................................................................................... 25
2.4.2 Non-Functional Requirements: ............................................................................................... 26
2.5 Data Flow Diagrams: .................................................................................................................. 27
2.5.1 Context Diagram ................................................................................................................. 27

2
 2.5.2 Diagram 0............................................................................................................................ 28
2.5.3 ER Diagram: ....................................................................................................................... 29
2.6 Process Specification Form:........................................................................................................ 30
2.7 Data Flow Description ................................................................................................................ 31
2.7.1 News Data – Data Flow Description................................................................................... 31
2.7.2 Ad Info - Data Flow Description ........................................................................................ 32
2.8 Data Structure Description for Data Flow .................................................................................. 33
2.9 Element Description Form for Data Flow................................................................................... 34
2.9.1 Event Schedule.................................................................................................................... 34
2.9.2 Live Score Updates ............................................................................................................. 35
2.10 Data Store forms ......................................................................................................................... 36
2.10.1 Data Store Description Form .............................................................................................. 36
2.10.2 Data Structure Description Form ........................................................................................ 37
2.10.3 Element Description Form .................................................................................................. 38
3. Chapter 3 ............................................................................................................................................ 39
3.1 Introduction:................................................................................................................................ 40
3.2 Database Design.......................................................................................................................... 40
3.2.1 User Table ........................................................................................................................... 40
3.2.2 Article Table ....................................................................................................................... 41
3.3 System Interfaces Desing ............................................................................................................ 42
3.3.1 Home Page .......................................................................................................................... 42
3.3.2 Specific sport page .............................................................................................................. 43
3.3.3 Club and event Details page................................................................................................ 44

3
Table of Figures
Figure 1 GANTT Diagram ............................................................................................................................. 10
Figure 2 Pert Diagram ................................................................................................................................. 11
Figure 3 FIDE Hand Book .......................................................................................................................... 17
Figure 4 Sporticos Website ......................................................................................................................... 21
Figure 5 Live Soccer Tv Website ............................................................................................................... 22
Figure 6 Sport Skeeda Website ................................................................................................................... 23
Figure 7 All Sport DB ................................................................................................................................. 23
Figure 8 Context Diagram .......................................................................................................................... 27
Figure 9 Diagram 0 ..................................................................................................................................... 28
Figure 10 ER Diagram ................................................................................................................................ 29
Figure 11User Table ................................................................................................................................... 40
Figure 12 User Table constraints ................................................................................................................ 40
Figure 13 Article Table ............................................................................................................................... 41
Figure 14 Article Table constraints ............................................................................................................. 41
Figure 15 System Home Page Interface ...................................................................................................... 42
Figure 16 Specific Sport website page ........................................................................................................ 43
Figure 17 Club and event Details page ....................................................................................................... 44

Table of Tables
Table 1 Time Table ........................................................................................................................................ 9
Table 2Table 2 Pert Diagram Independencies Table .................................................................................. 11
Table 3 Process Specification Form............................................................................................................ 30
Table 4 Data Flow Description -1 ............................................................................................................... 31
Table 5 Data Flow Description-2 ................................................................................................................ 32
Table 6 Data Structure Description for Data Flow ..................................................................................... 33
Table 7Element Description form for Data Flow -1 ................................................................................... 34
Table 8Element Description form for Data Flow-2 .................................................................................... 35
Table 9Data Store Description Form .......................................................................................................... 36
Table 10Data Structure Description for Data Store .................................................................................... 37
Table 11Data Structure Description for Data Store .................................................................................... 38

4
1. Chapter 1

5
1.1 Introduction:
The Olympic Unity System is a centralized platform designed to bring together all Olympic sports,
providing real-time updates, event reports, and statistical insights. In this chapter, we will explore
the system’s goals and objectives, discuss the feasibility studies that evaluated its technical,
operational, and financial viability, and outline the project timeline. Additionally, we will examine
the opportunities the system presents for fans, staff, and advertisers, and explain the methodology
used during development.

1.2 System Idea:

The Olympic Unity System is a comprehensive platform designed to manage, analyze, and
disseminate information related to all Olympic sports. It encompasses event scheduling, results
management, news coverage, and in-depth sport-specific data. By integrating various subsystems,
each focused on a specific sport, the system aims to provide a centralized hub for athletes, officials,
media, and fans. Key features include real-time updates, advanced analytics, and interactive
platforms to enhance the overall Olympic experience.

1.3 Problems That the System will seek to address:

1. Information overload: The system will aggregate and organize vast amounts of data, making
it easily accessible and digestible.
2. Inefficient communication: By providing a centralized platform, the system will improve
communication among athletes, officials, and media.
3. Data inconsistency: The system will standardize data collection and storage, ensuring
accuracy and reliability.
4. Lack of transparency: The system will enhance transparency in event scheduling, results,
and decision-making processes.
5. Event scheduling conflicts: The system will optimize event schedules to avoid conflicts and
maximize efficiency.
6. Delayed results: Real-time results processing will eliminate delays and provide instant
gratification for athletes and fans.
7. Limited access to sports information: The system will provide comprehensive coverage of
all Olympic sports, catering to a diverse audience.

1.4 The Opportunities Offered by the System:

1. Core Functionality Opportunities:
a) Real-time updates: Ensure immediate dissemination of event schedules, results, and
news.
b) Multiple language support: Cater to a global audience by providing information in
various languages.
c) Accessibility features: Make the system usable by people with disabilities.

6
 d) Data visualization: Present complex data in easy-to-understand formats (e.g., graphs,
charts).
e) Push notifications: Allow users to subscribe to specific sports or athletes for timely
updates.
2. Subsystem-Specific Opportunities
a) In-depth sport-specific data: Provide detailed statistics and analysis for each sport.
b) Expert commentary: Integrate expert analysis and predictions into the news section.

1.5 Goals That the system aims to achieve:

1. General Goals:
a) Centralize and manage Olympic sports data effectively and efficiently.
b) Provide real-time access to accurate and up-to-date sports information.
c) Optimize operational processes related to event scheduling, results management, and
resource allocation.
d) Enhance the overall Olympic experience for athletes, officials, media, and fans through
innovative features and functionalities.
2. Goals The system aims to achieve for sports fans:
a) Engaging experience: Create an immersive and interactive platform for following the
Olympic Games.
b) Access to information: Provide comprehensive and up-to-date information about
athletes, events, and results.
c) Personalized experience: Offer tailored content and experiences based on fan
preferences.

1.6 Project Importance:

The Olympic Unity System is a comprehensive platform that brings together all Olympic sports
in one centralized website, providing real-time event updates and seamless management of event
data. By integrating with third-party providers, the system delivers live scores and updates,
ensuring fans have access to accurate and timely information across all sports. It enhances the
fan experience with personalized notifications and detailed event schedules. The platform also
supports advertisers, allowing them to manage and target ads effectively during key events,
creating both a revenue stream and broad exposure. For staff, the system streamlines the
management of event data, ad approvals, and report generation, improving operational
efficiency. With its ability to generate reports based on historical and current event data, it offers
valuable insights, while its scalability ensures the system can grow to accommodate increasing
demands. Additionally, the platform’s global accessibility unites fans from around the world,
making it a key tool for experiencing the Olympics seamlessly and comprehensively.

7
1.7 System Development Methodology:
1. Methodology:
The Methodology that will be used for developing the system is SDCL
Reasoning:
Given the dynamic nature of the Olympic Games and the potential for changes in sports,
athletes, and regulations, this methodology is essential for flexibility and adaptability. The
iterative development approach allows for continuous improvement and the incorporation of
new features based on feedback from stakeholders, such as athletes, officials, and fans.
Moreover, this methodology promotes collaboration among development teams, which is
crucial for a complex system involving multiple sports and subsystems.

2. Programming Language:
The chosen programming language to develop the system in Python
Reasoning:
Python's readability and versatility make it an ideal choice for developing a complex system
like an Olympic sports system. Its extensive libraries, such as Pandas and NumPy, provide
powerful tools for data analysis and manipulation, which are critical for processing and
analyzing sports data. Additionally, Python's ability to integrate with various other
technologies and frameworks makes it suitable for building different components of the
system, including data management, web applications, and machine learning models.

3. Database:
The chosen Database for Olympic Unity System is Hybrid Database
Reasoning:
A hybrid database approach could work well. SQL databases can handle structured event
scheduling and results, while NoSQL databases can be used for unstructured data, like news
coverage and multimedia.

4. Tools:
a) Version control: Git for effective code management and collaboration among development
teams.
b) Integrated development environment (IDE): PyCharm for Python development, providing
a comprehensive environment for coding, debugging, and testing.
c) Project management: Jira or Trello for task management and tracking, facilitating efficient
project planning and execution.
d) Data visualization: Libraries like Matplotlib and Seaborn for creating informative
visualizations of sports data to support analysis and decision-making.
e) Testing framework: Unittest or pytest for writing and running tests to ensure code quality
and reliability.
f) Deployment tools: Docker for containerizing the application and its dependencies,
simplifying deployment and scalability.
g) Cloud platform: AWS, GCP, or Azure for hosting the system and leveraging cloud
services for scalability, reliability, and cost-efficiency.

8
1.8 Detailed project plan
In this Section we will show the detailed plan for building the “Olympic Unity” System. In
addition, we will provide Diagrams Such as Pert diagram and Gantt Chart to visualize the plan.
The following is the Time table for the phases of building the system. After this table we will
provide every phase with its tasks in details and duration in days.
1.8.1 Time Table:

Phase Duration

Information Gathering 2 Weeks

Project Planning 1 Week

System Design 3 Weeks

Development 5 Weeks

Testing 2 Weeks

Deployment 1 Week

Maintenance On- Going

Table 1 Time Table

1.8.2 Tasks In Detail:

a) Information Gathering: August 1 - August 14
• Gather Requirements: August 1 - August 5
• Analyze Existing Systems: August 6 - August 9
• Conduct User Interviews: August 10 - August 14
b) Project Planning: August 15 - August 22
• Define Project Scope: August 15 - August 16
• Create Detailed Project Plan: August 15 – August 17
• Allocate Resources: August 17 – August 22
c) System Design: August 23 - September 5
• Design Database Schema: August 23 - August 28
• Develop System Architecture: August 29 - September 1

9
 • UI/UX Design: September 2 - September 5
d) Development: September 6 - October 16
• Backend Development: September 6 - October 1
• Frontend Development: September 15 - October 10
• Integrate Sub-Systems: October 11 - October 16
e) Testing: October 17 - November 1
• Unit Testing: October 17 - October 21
• Integration Testing: October 22 - October 26
• User Acceptance Testing: October 27 - November 1
f) Deployment: November 2 - November 8
• Deploy to Production
• Perform Post-Deployment Testing
g) Maintenance: November 5 – Ongoing
• Monitor System Performance
• Update and Fix

Now we will drop these detailed tasks on GANTT Diagram to which is a toll for project
management that help in visualizing the process of building the project.

1.8.3 GANTT Diagram:

Figure 1 GANTT Diagram

10
1.8.4 PERT Diagram:
Pert diagram is a very important tool in project management as is important for identifying the
critical path and the priority for every task and its dependencies
Symbol Phase Name Independencies
A Gathering Information None
B Analyze existing Systems A
C Conduct User Interviews B
D Define Project Scope A
E Create Detailed Project Plan D
F Allocate Resources E
G Design Database Schema F
H Design System Architecture G
I UI/UX Design H
J Back-End Development H
K Front-End Development I
L Integrate Sub-Systems J
M Unit Testing K, L
N Integrate Testing K, L
O User Acceptance Testing M, N
P Deploy to Production O
Q Perform Post-Deployment Testing P
R Monitor System Performance Q
S Update and Fix Q
Table 2Table 2 Pert Diagram Independencies Table

Diagram:

Figure 2 Pert Diagram

The critical path

A+B+C+E+F+G+H+J+L+M+O+P+Q
➔5 + 4 + 5 + 3 + 6 + 6 + 3 + 26+ 6 + 5 + 5 + 4 + 4= 82 Days

11
1.9 Feasibility study
The Feasibility Study section provides an evaluation of the proposed system's viability by examining
various factors that influence its success. This analysis is conducted to ensure that the project is
practical and achievable within the given constraints. The study covers multiple aspects, including
technical, economic, operational, and legal feasibility, each contributing to a comprehensive
understanding of whether the system can be implemented effectively. By assessing these key areas,
the feasibility study helps stakeholders make informed decisions before proceeding to the design and
development phases.
1.9.1 Technical Feasibility:
1. Structure:
a) Microservices Structure:
Implementing a microservices architecture is optimal for scalability, especially when
each sport has specific data and functionality requirements. Each microservice can be
independently developed and deployed, reducing the system’s complexity and enhancing
modularity.
b) API Integration:
To handle real-time data for scores and news, integration with third-party APIs is
essential. This setup supports dynamic updates and enables seamless interaction with
external Olympic data sources.
2. System Components:
a) Frontend:
Utilizing JavaScript frameworks such as React, Angular, or Vue.js will ensure a
responsive, user-friendly interface across devices.
b) Backend:
A combination of Django, Node.js, or Spring Boot can support efficient server-side
processing, depending on the final structure and desired language compatibility.
c) Database:
Using a combination of SQL (e.g., PostgreSQL) for structured data and NoSQL (e.g.,
MongoDB) for unstructured data (e.g., media and sports-specific information) can
optimize data storage and retrieval.
d) Cloud services:
Deploying on cloud platforms like AWS or Azure will enhance scalability and ensure
uptime through load balancers, automatic scaling, and redundancy.
3. Security Measures:
a) Authentication and Authorization: Implement OAuth 2.0 or JWT for secure user
sessions.
b) Data Protection: Use of SSL/TLS encryption to protect data in transit, and regular
backups to secure data at rest.
4. Scalability and Maintenance:
a) Load Balancing: Load balancers will efficiently distribute traffic, especially critical
during peak events.
b) System Monitoring: Continuous monitoring tools (e.g., AWS CloudWatch, Prometheus)
will aid in identifying performance bottlenecks and maintaining optimal performance.

12
Result of Technical Feasibility:
The technical feasibility study demonstrates that the Olympic Unity system can be built with
available technology and infrastructure. The chosen components and architecture will support
scalability, real-time data processing, and secure handling of user data, making the creation of
this system worth pursuing.

1.9.2 Economic Feasibility

1. Cost Analyze:
a) Development Costs:
Salaries for developers, designers, and project managers over the estimated development
phase (approximately $200,000 to $300,000).
b) Technology Costs:
Software licenses, API subscriptions, and database hosting services ($10,000 to
$20,000/year).
c) Infrastructure Costs:
Initial costs for cloud servers, load balancers, and storage can range from $5,000 to
$15,000 depending on usage and storage capacity.
d) Maintenance Costs:
Ongoing maintenance, updates, and support can be estimated at 15% of initial
development costs annually.
2. Revenue Generation:
a) Sponsorships and Advertisements:
Partnering with relevant brands and organizations to generate revenue through ads.
b) Subscription Models:
Offer premium features to users for a fee (e.g., ad-free experience, exclusive content).
3. Economic Viability analysis:
a) Projected Timeline to Break Even:
Given the estimated initial development and operational costs ($247,000–$385,000
including infrastructure and maintenance), break-even might be expected within 2–4
years, depending on user acquisition and revenue streams. Major events, such as the
Olympics, can serve as key revenue drivers due to increased traffic and engagement.
b) Revenue Streams:
• Advertisements and Sponsorships:
Collaborating with global sports brands and advertisers targeting the Olympic
audience could bring in substantial ad revenue, especially during event seasons.
Strategic ad placements could yield an estimated $50,000–$100,000 annually.
• Subscription Model:
Offering a subscription with exclusive features like ad-free browsing, in-depth
analytics, and personalized athlete content can attract dedicated sports fans. At an
estimated 10,000 users in the first year, with each paying a $5 monthly subscription,
this could generate around $600,000 annually. Growth in subscribers would drive a
quicker recovery.

13
Result of Economic Feasibility:
The economic feasibility indicates that the Olympic Unity system is financially viable. The
estimated revenue from subscriptions, sponsorships, and ads should cover initial costs and
maintenance, making the system's development worthwhile.

1.9.3 Operational Feasibility

Operational feasibility assesses the capability of an organization to implement and maintain the
proposed system effectively. This section outlines the aspects related to user interaction,
workflow, team structure, and ongoing support that ensure the success of the Olympic Unity
system, which will serve as a platform for various sports with live scores and updates.

1. User Interface Design and Usability

a) User Interface and Usability:
The design must cater to diverse users, such as fans, athletes, and officials. Features like
intuitive navigation, responsive design, and accessibility (e.g., WCAG compliance) will
improve usability.
b) Multi-Device Compatibility: Development of a responsive web design that adjusts
seamlessly across various devices (desktop, tablets, and mobile devices) to enhance user
experience and engagement.
2. User Training and Support
a) Documentation: Providing comprehensive guides and manuals will facilitate user
onboarding.
b) Support Channels: A centralized help center with FAQs, live chat, and email support
will enhance user experience and resolve issues efficiently.
3. Team Structure and maintenance:
a) Development and Maintenance Team:
Establishing dedicated roles, from frontend to backend developers, will streamline both
the system’s implementation and ongoing maintenance.
b) Continuous Improvement:
Regular feedback channels and version control (e.g., Git) will enable the team to roll out
updates and changes based on user needs.

Result of Operational Feasibility:

The operational feasibility confirms that implementing and maintaining the Olympic Unity
system is achievable with proper resource allocation and support structures. The system’s
usability, support, and team organization make its creation a worthwhile endeavor.

14
2.Chapter 2

15
2.1 Introduction:
This chapter focuses on the methodologies and approaches used to gather data for the development
of the Olympic Unity System and outlines the system's design structure. Several techniques were
employed during the data collection process, including interviews, questionnaires, and document
analysis each contributing to a comprehensive understanding of stakeholder needs and system
requirements.
Following data collection, the system’s design is elaborated through visual models such as the
Context Diagram and the Level 0 Data Flow Diagram (DFD), which depict the interaction between
users, processes, and data stores. These diagrams provide a clear and structured view of how data
flows within the system and how different components interact to achieve the system’s objectives.

2.2 Data Gathering:

In this section of Olympic Unity System documentation, several documents are critical to
review before building the system. These documents provide background knowledge, define
system requirements, and ensure compliance with regulations. Here's a breakdown of the key
documents and how they benefit the system development process. This Process was done by
several techniques which are:

2.2.1 Reading and Analyzing documents:

Many Information was gathered by reading and analyzing documents such as:
1. Olympic Games Guidelines and Policies
• Purpose: These documents outline the official rules, regulations, and guidelines set by
the International Olympic Committee (IOC) regarding the organization and management
of the Olympic Games.
• Benefits:
o Ensures that the system adheres to the official standards of the Olympic Games.
o Provides detailed descriptions of the different sports, events, and categories,
which can be used to design the structure of the event and athlete databases.
o Helps ensure compliance with athlete participation regulations, scheduling
standards, and data management protocols.
o Defines security protocols and privacy policies that the system must implement,
especially when handling sensitive athlete and event data.

16
2. Legal and Data Privacy Regulations
• Purpose: Documents outlining data protection laws such as GDPR (General Data
Protection Regulation) and other privacy standards applicable to international sporting
events.
• Benefits:
o Ensures that the system handles athlete and user data responsibly, maintaining
compliance with legal requirements.
o Minimizes the risk of legal issues arising from the misuse or mishandling of
personal and performance data.

3. International Sports Federations Documents (e.g., FIDE Handbook)

• Purpose: Documents from international sports federations, such as the FIDE Handbook
(for chess), provide sport-specific regulations and operational guidelines.
• Benefits:
o Offers a detailed breakdown of the rules and procedures specific to individual
sports, ensuring that the system accurately reflects the requirements of diverse
sporting disciplines.
o Provides insights into event structuring, participant qualification criteria, and
result reporting for particular sports, ensuring that the system can handle the
unique needs of different federations.
o Ensures that the system complies with specific federation requirements regarding
athlete data, event results, and rankings, which is crucial for ensuring the system’s
credibility and accuracy.

The following figure shows the website of FIDE Hand Book

Figure 3 FIDE Hand Book

17
2.2.2 Interviews
The interviews phase aims to gather qualitative insights directly from stakeholders involved
with or affected by the OlympicUnity system. This will help in understanding their needs,
pain points, and expectations, enabling us to refine the system's design and functionality.

1. Target Interviewees:
a) Management (CEO/Executive Team):
• Demographics:
Leadership and executive team members of the organization behind OlympicUnity.
• Purpose:
To understand the strategic vision for the platform and the business objectives it
needs to fulfill.
b) Sports Fans:
• Demographics:
Various age groups, backgrounds, and interests in Olympic sports. They may include
casual viewers, avid supporters, and social media followers.
• Purpose:
To understand their preferences for accessing information about Olympic sports and
events, their usability expectations, and desired features for engagement.
c) Event Organizers and Officials:
• Demographics:
Individuals involved in organizing and managing Olympic events, such as local
organizing committees and sports federation officials.
• Purpose:
To gather insights regarding event management needs, scheduling, results reporting,
and information dissemination.
d) Athletes and Coaches:
• Demographics:
Professional athletes competing in Olympic sports and their coaches or trainers.
• Purpose:
To identify their needs in terms of performance tracking, training resources, event
participation, and interaction with fans.
e) Media Personnel:
• Demographics:
Journalists, bloggers, and broadcasters who cover Olympic events and sports.
• Purpose:
To understand their requirements for accessing updates, managing content, and
disseminating information efficiently.

18
2. Sample Interview Questions:
a) For Management (e.g., CEO/Executive Team):
• What are the primary business objectives for the OlympicUnity system?
• How do you envision the platform impacting user engagement with Olympic sports?
• What metrics will you use to measure the success of the OlympicUnity system?
• What is your vision for integrating sponsorships, advertising, or partnerships within
the platform?
• How do you envision the system evolving over the next 5 to 10 years?

b) For Sports Fans:

• How do you currently access information about Olympic sports and events?
• What features would you like to see in an Olympic sports management platform?
• How important are real-time updates to you during Olympic events?
• Would you be interested in features that allow communication between fans and
athletes? If yes, how would you envision this working?
• What kind of analytics or data would enhance your viewing experience?

c) For Event Organizers and Officials:

• What challenges do you currently face in managing and disseminating information
during Olympic events?
• What tools or systems do you currently use, and what are their limitations?
• How critical is real-time reporting of results during events?
• What kind of analytics do you need to assess the success of various events?

d) For Athletes and Coaches:

• What functions would you find most helpful in an Olympic sports management
platform?
• Are there certain types of information you’d like the platform to provide to fans about
your journey or achievements?
• Would you be interested in features that facilitate interaction with fans or media?

e) For Media Personnel:

• How do you gather information during Olympic events? What is your biggest
challenge?
• What features would help you provide better coverage of the events?
• Would you find analytics on audience engagement and event popularity valuable?
• What is your preferred method of receiving updates—through a dedicated platform,
email alerts, or app notifications?
• How can the system support your story development or content creation process?

19
3. Summary of Interviews Conducted
The interviews yielded valuable qualitative insights from a diverse group of stakeholders
involved with or impacted by the OlympicUnity system. Key themes identified during the
interviews include:

1. User Preferences:
Stakeholders expressed a strong desire for an intuitive user interface that prioritizes real-time
updates and easy navigation. Sports fans emphasized the need for personalized content and
community engagement features.
2. Information Accessibility:
Event organizers highlighted the importance of efficient tools for event scheduling and
results management. They requested features that streamline communication with both fans
and athletes.
3. Performance Tracking:
Athletes and coaches emphasized the need for performance analytics and tools for tracking
progress. They expressed interest in features that promote athlete-fan interaction while
addressing privacy concerns.
4. Media Needs:
Media personnel stressed the importance of timely access to accurate information and
analytics to enhance their coverage of events. They requested features that support content
generation and audience engagement metrics.

20
2.2.3 Similar Systems
The Olympic Unity system draws on the strengths of both single-sport and general multi-
sport platforms. A review of existing platforms reveals two main categories: those that focus
on one sport in depth and those that cover a broad range of sports with less detailed reporting.
Here’s a comparison of similar systems:
1. Single-Sport Focused Systems:
• Sporticos (Football)
o Advantages:
▪ Offers live football match streams, results, and news coverage specific to
football.
▪ Specializes in providing fans with legal streams and detailed match schedules
from leagues across the world.
▪ Fans get a comprehensive football-only experience with easy access to results,
news, and live coverage.
o Disadvantages:
▪ Limited to football, which means users interested in other sports need to use
different platforms for other events.
▪ Lacks features for other Olympic sports, which could be a limitation for multi-
sport fans.
The following figure shows Sporticos homepage website:

Figure 4 Sporticos Website

21
 • Live Soccer TV (Football)
o Advantages:
▪ Focuses exclusively on football coverage, offering detailed live streaming
schedules, TV listings, and match updates.
▪ Provides global coverage of leagues and tournaments with live scores and
news, making it an ideal platform for football enthusiasts.
o Disadvantages:
▪ Similar to Sporticos, it’s limited to just one sport, leaving no room for multi-
sport coverage.
▪ Lacks personalization for users interested in other Olympic sports or
international competitions.

The following figure shows Live Soccer TV homepage website:

Figure 5 Live Soccer Tv Website

2. General multi-sport systems:

• Sportskeeda (Multi-sport platform)
o Advantages:
▪ Offers a broad range of sports coverage, including cricket, basketball, WWE,
and more, with live results and detailed news.
▪ Ideal for users who want a general overview of many sports without needing
to switch between platforms.
o Disadvantages:
▪ Does not provide in-depth analysis or comprehensive data on individual
sports; it mainly focuses on major news without much detailed reporting.
▪ For fans seeking specialized statistics or features, it lacks the depth found in
single-sport platforms.

22
The following figure shows Sportskeeda homepage website:

Figure 6 Sport Skeeda Website

• AllSportDB (multi-sport event tracking)

o Advantages:
▪ Provides a comprehensive sports event calendar, covering a wide range of
global sports events like tennis, cycling, figure skating, and many others.
▪ Excellent for keeping track of event dates, locations, and schedules for
multiple sports at once.
o Disadvantages:
▪ The platform does not provide in-depth coverage of any one sport, nor does it
offer advanced features like live commentary or detailed performance
statistics.
The following figure shows AllSportDB homepage website:

Figure 7 All Sport DB

23
2.3 Story Telling:
In the world of sports, every moment counts. For athletes, fans, and officials, a single update can
mean the difference between being in sync with the action and missing out on a thrilling
moment. Recognizing this, a group of passionate developers embarked on an ambitious journey
to create a system that would bridge the gap between sports events and real-time information for
millions of Olympic fans around the world.

Imagine a fan named Sara. Sara has been an Olympic enthusiast her entire life, eagerly awaiting
each game to support her favorite athletes. But like many, she often struggles to keep track of
event schedules and match results. She dreams of a platform that not only provides updates but
also offers a personal connection with the athletes she admires.

Meanwhile, across the globe, there’s Alex, an athlete who dreams of more than just winning
medals. He wants to engage with his fans, sharing insights about his journey, training, and the
highs and lows of being a competitor on the world’s biggest stage. However, there’s currently no
system that enables such a connection effectively.

And then there’s Maria, a journalist covering Olympic events. Maria’s challenge lies in staying
ahead of the updates, capturing the essence of every match in real-time to report to her audience.
She needs immediate access to reliable data and insights but often struggles with delays or
incomplete information.

Witnessing the challenges faced by fans like Sara, athletes like Alex, and media professionals
like Maria, the creators of Olympic Unity decided to build something unique—a comprehensive
platform that would go beyond conventional sports apps.

They began by gathering input from stakeholders like Sara, Alex, and Maria. Through
interviews, surveys, and research, they learned what truly mattered to each of them: for fans, it
was real-time notifications and an engaging interface; for athletes, a secure way to connect with
supporters; and for media professionals, a fast, reliable feed with in-depth analytics.

With these insights, the team chose the latest technologies and security protocols, ensuring that
the platform would not only perform seamlessly but also protect the data and interactions of
everyone involved. They envisioned a hybrid database that could handle structured event
schedules and unstructured news content, guaranteeing that no matter what kind of information
was needed, it was always accessible, accurate, and immediate.

As Olympic Unity began to take shape, it became clear that it was more than a project—it was a
mission to bring people closer to the sports they love. Fans would receive updates instantly,
athletes could share moments from their journeys, and journalists would have the tools to deliver
powerful stories with unprecedented accuracy.

24
2.4 Requirement and specifications:
2.4.1 Functional Requirement
a) Fans:
• Fans should be able to view event schedules, scores, and live updates provided by the
Third-Party Data Provider.
• Fans should have the option to choose to receive notifications about live events,
scores, or important updates and articles (news).
• The fans should be able to filter events by sport, date, or athlete to easily find relevant
information.
• Fans should be able to have the access to historical data and not only live event
information.

b) Admin:
• Admin should have the ability to approve or reject advertisements that appear on the
platform.
• Admin should be able to remove or add staff from the system.

c) Staff:
• Staff should be able to manage and update event schedules, venues, and other event-
related information.
• Staff should be able to post articales and specify the sport the article related to.
• The system should allow staff to generate and view reports regarding fan
engagement, platform usage, and advertisement performance.

d) Third-Party Data Provider:

• The Third-Party Data Provider should supply real-time event data, such as live scores
and updates, which the system displays to fans.
• The system should handle potential issues like delays or downtimes from the Third-
Party Data Provider by displaying appropriate fallback messages.
• The Third-Party should provide the historical data for every sport.

e) Advertisers:
• Advertisers should be able to submit advertisement requests to the system for
approval by the Admin.
• Advertisers should have access to reports on the performance of their ads, including
views, clicks, and engagement.
• Advertisers should receive notifications on the approval status of their
advertisements.

25
2.4.2 Non-Functional Requirements:
a) Performance:
• The system should provide real-time updates to fans without delays when retrieving
data from the Third-Party Data Provider.
• The platform should handle high traffic during peak events without affecting the
performance or user experience.
b) Scalability:
• The system should scale to accommodate increasing numbers of fans, advertisers, and
live updates as the platform grows.
• The system should be flexible enough to integrate additional data providers if
necessary.
c) Security:
• All communications with the Third-Party Data Provider should be secure to prevent
data manipulation.
• Advertisers’ data and reports should be protected from unauthorized access, with
role-based permissions in place for staff.
• The system should protect fans' interactions, especially when displaying ads, to avoid
malicious content or phishing attempts.
d) Usability:
• The platform’s design should allow fans to easily navigate event schedules, live
updates, and advertisement interactions.
• Advertisers should have an intuitive process to submit and track their ad performance.
e) Reliability:
• The system should ensure high availability, especially during live events, with
minimal downtime.
• If the Third-Party Data Provider experiences issues, the system should display
fallback information to maintain user engagement.
f) Maintainability:
• The system should be modular, allowing for easy updates or adjustments, such as
modifying the way ads are displayed or updating integrations with the data provider.
• Logs should be maintained to monitor both ad placements and data retrieval from the
provider for troubleshooting.
g) Compliance:
• The system should follow data privacy regulations, ensuring that fans' information is
secure and not misused.
• Advertisements should comply with local advertising standards, with staff responsible
for enforcing compliance when approving ads.

26
2.5 Data Flow Diagrams:
When we want to understand the system requirements that we need in the system, we must
understand how the data flows by describing the requirements graphically. Therefore, the DFD
method has levels, which are:

2.5.1 Context Diagram

A context diagram outlines how external entities interact with an internal software system.
We will use it to help us wrap our heads around the scope of a system. As a result, they can
figure out how best to design a new system and its requirements or how to improve an
existing system.
The following diagram is the context diagram of Olympic Unity System:

Figure 8 Context Diagram

27
2.5.2 Diagram 0
It shows the major processes, data flows, and data stores in the system, without providing any
details about the internal workings of these processes
The following diagram is the Diagram 0 of Olympic Unity System:

Figure 9 Diagram 0

28
2.5.3 ER Diagram:
The Entity Relationship Diagram explains the relationship among the entities present in the
database. ER models are used to model real-world objects like a person, a car, or a company and
the relation between these real-world objects. In short, the ER Diagram is the structural format of
the database. The following Figure is ER diagram of the Olympic Unity System.

Figure 10 ER Diagram

29
2.6 Process Specification Form:
Process specifications provide a standardized framework for performing specific tasks or
processes within an organization. They outline the step-by-step procedures, guidelines, and
requirements necessary to achieve consistent and reliable results. In this section we will take
one of the processes that are in the Diagram 0 which is Generate Event Report and Statistics.
The following figure is the process specification form of the is Generate Event Report and
Statistics process.

Process Specification
ID: 5
Name: Generate Event Report and Statistics
Description:
This process gathers event data, results, and historical data to generate event reports and
statistics. These outputs are stored for use in reports and articles about the events.

Input Data Flow:

• Event data from D3 - Events Data Store.
• Historical data from D2 - Historical Data Store
Output Data Flow:
• Event reports and statistics sent to D4 - Statistics Data Store.

Processing Logic:
• Fetch event-specific data from the Events Data Store (D3).
• Access historical data from past events from the Historical Data Store (D2).
• Compare current event results with historical data to calculate statistical trends.
• Generate a comprehensive event report based on this information.
• Store the generated reports in the Statistics Reports Data Store (D4).
Type of Process:
Batch( ) Online( ✓ ) Manual( )

Table 3 Process Specification Form

30
2.7 Data Flow Description
In this section, each element of the Data Flow Diagram (DFD), starting with the flow arrows, is
described in detail. This includes identifying the source of each arrow, its destination, and its
type, followed by a list of the data it transfers. Additionally, a thorough explanation is provided
for each term within the data being transferred. The data dictionary, which will follow the same
sequence as presented in the diagram, serves as a crucial reference tool for developers, offering
indispensable guidance throughout the system development process. In our system, we will take
two data flows as an example of the Data Flow Description which are (Ad Info, News Data) data
flows.

2.7.1 News Data – Data Flow Description

Data Flow Description

ID:
Name: News Data
Description: This data flow includes news content provided by staff members. The data
is used to generate article templates for the platform, allowing for timely and relevant
information to be prepared for publication.

Source: Destination:
Staff Generate Article Template (Process 4)

Type of Data Flow:

File Report ✓ Form Screen Internal


Data Structure Traveling with the Flow: Volume/Time:
Article Content, Author Info, Event 10-15 updates/day, typically during or
Details, Publication Date after key events

Comments: News content is reviewed and structured by staff members, then sent to the
Generate Article Template process. This information is formatted into articles for
publication, ensuring up-to-date coverage of events.

Table 4 Data Flow Description -1

31
2.7.2 Ad Info - Data Flow Description

Data Flow Description

ID:
Name: Ad Info
Description: This data flow contains advertisement information submitted by
advertisers to the system. The data is sent to the Ads Requests Data Store for storage
and further processing, where it will be reviewed and potentially authorized by the
system admin.
Source: Destination:
Advertiser D7 (Ads Requests Data Store)

Type of Data Flow:

✓ File Report Form Screen Internal


Data Structure Traveling with the Flow: Volume/Time:
• Advertisement Content (Images, Text, Media) Approximately 10-20 ad requests per
• Advertiser Info (Company Name, Contact day
Details)
• Target Audience Details (If specified)
• Advertisement ID
Comments: Advertisers submit ads to the system, and these ads are stored in the Ads
Requests Data Store. The ads are then reviewed by system Admin to ensure they meet
platform guidelines before being authorized and displayed.

Table 5 Data Flow Description-2

32
2.8 Data Structure Description for Data Flow
Data structures are typically represented using algebraic notation. This approach enables the
analyst to present the individual components that form the data structure, along with detailed
information about those components. For our Olympic Unity System we will take the data flow
named (Event Data) to make a data structure description for it. The following diagram is the data
structure description form for that data flow:

Data Structure Description for Data Flow

Name: Event Data
Alias: Olympic Event Information
Description: Provides comprehensive details about Olympic events, including schedule,
location, participants, and results.
Related Data Flows/Structures: Volume/Time:
50 events/day

Event Data = Event ID +

Event Name +
Event Type +
Event Schedule +
Location +
Event Status +
Event Format +
(Results)
Event Type = [Group: Individually]

Event Schedule = Start Date +

Start Time +
End Date +
End Time +
(Time zone)
Location = Venue +
City +
Country +
[Indoor: Outdoor]
Event Status = [Scheduled: Ongoing: Completed: Canceled]

Event Format= [Round Robin: Double Round Robin: Knockout]

Table 6 Data Structure Description for Data Flow

33
2.9 Element Description Form for Data Flow
An Element Description Form for data flow is a detailed form that describes each element in a
Data Flow Diagram (DFD). It is used to define the attributes and details of every flow, process,
data store, or external entity involved in the system. This form helps analysts and developers
understand the nature of each component of the data flow, how it interacts with other
components, and what kind of data is transferred. In our system we will make two element
description forms which are (Event Schedule, Live Score Updates)

2.9.1 Event Schedule

Element Description form for Data Flow

ID:
Name: Event Schedule
Alias: Event Timetable
Description: Represents the detailed schedule of Olympic events, including event names,
times, venues, and participants.
Element Characteristics
Length: 100 Alphabetic
Input format: Alphanumeric (event name, date, time) ✓ Alphanumeric
Output format: Alphanumeric (event details) ✓ Date
Default Value: None
Numeric
Continuous ✓ Discrete
✓ Base Derived

Validation Criteria
Discrete Discrete
Value: Date (DD-MM-YYYY) Value: Event Name (Text)
Value: Time (HH:MM) Value: Venue (Text)
Comments:
The event schedule element must include all details for each event, ensuring no time conflicts.
It is a core part of the system for keeping fans, staff, and athletes updated with real-time
schedules.
Table 7Element Description form for Data Flow -1

34
2.9.2 Live Score Updates

Element Description form for Data Flow

ID:
Name: Live Score Updates
Alias: Real-Time Results
Description: Represents the real-time score updates during Olympic events. Provides fans and
stakeholders with immediate access to event results.
Element Characteristics
Length: 50 Alphabetic
Input format: Numeric (score), Alphanumeric ✓ Alphanumeric
(event/participant names)
Date
Output format: Alphanumeric (event name,
participant name, score) ✓ Numeric
Default Value: None ✓ Base Derived
✓ Continuous Discrete
Validation Criteria
Continuous Discrete
Upper Limit: 999 (Maximum score value) Value: Score (Numeric)
Lower Limit: 0 (Minimum score value)
Comments:
The live score updates must be displayed without delays, ensuring that fans and media receive
accurate, real-time information during Olympic events. The score can range from 0 to 999,
depending on the sport.
Table 8Element Description form for Data Flow-2

35
2.10 Data Store forms
Now since we have already discus what are Description forms, we have to make them again for
data stores in this section.

2.10.1 Data Store Description Form

Data Store Description Form

ID: D2
Name: Historical Data Store
Alias: Archive Data Repository
Description: Stores all historical event data, including records of past results, athlete
performances, and event outcomes from previous Olympic Games. This information is preserved
for research, analysis, and reporting purposes.
File Type: ✓ Computer Manual
File Format: ✓ Database Indexed Sequential Direct
Record Size (Characters): 300
Number Of Record: Maximum of 5000
Percent Growth Per Year:5%
Data Set Name: Historical Results Archive
Copy Member: Historical_Backup
Data Structure: Historical Event Record
• Primary Key: Event ID
• Secondary Key: Event Date, Athlete ID, Event Location

Comments:
Data from past Olympic Games is maintained in this store to provide access for analytical reports,
historical comparisons, and event trend analysis. The data is periodically reviewed and archived to
ensure efficient storage and retrieval.
Table 9Data Store Description Form

36
2.10.2 Data Structure Description Form

Data Structure Description for Data Store

Name: Historical Data
Alias: Olympic Event Historical Information
Description: Captures historical records of Olympic events, including results, participants,
locations, and key event details over time.
Related Data Flows/Structures: Volume/Time: Up to 200 events/year (historical records
for all past events)
Historical Data = {Event ID} +
Event Name +
Event Type +
Event Date +
Location +
Results +
Event Report
Event Type = [Sports, Cultural, Others] +
[Group: Individually]

Event Date = Start Date +

Start Time +
End Date
Location = Venue +
City +
Country
Results = Final Scores+
Winner+
Losers
Event Report = Textual Summary+
Detailed Statistics+
Performance Analysis
Table 10Data Structure Description for Data Store

37
2.10.3 Element Description Form

Element Description form for Data Store

ID:
Name: Historical Records
Alias: Past Event Data
Description: Stores detailed records of previous Olympic events, including event names,
dates, venues, results, and participant information. This data is used for statistical analysis,
historical reference, and reporting purposes.
Element Characteristics
Length: 500+ entries (scalable) Alphabetic
Input format: Alphanumeric (event name, date, ✓ Alphanumeric
participant details)
Output format: Alphanumeric (historical event ✓ Date
details) Numeric
Default Value: None ✓ Base Derived
Continuous ✓ Discrete
Validation Criteria
Discrete Discrete
Value: Date (DD-MM-YYYY) Value: Event Name (Text)
Value: Time (HH) Value: Venue (Text)
Value: Results (Alphanumeric)
Comments:
The historical records data store is crucial for providing accurate information on past Olympic
events. It supports statistical analysis and trend identification, aiding both researchers and
system users in understanding historical event outcomes.
Table 11Data Structure Description for Data Store

38
3.Chapter 3

39
3.1 Introduction:
In this chapter, we outline the design of the Olympic Unity system, focusing on database
structure and website interfaces. The database design section will cover the organization of data
and relationships essential to support seamless data retrieval, and storage ensuring optimal
performance and data integrity. Following this, we present the interface design for the website,
showcasing user-friendly layouts and functionalities tailored to meet the needs of athletes,
officials, and fans. Through this chapter, we aim to demonstrate how each design element
contributes to an efficient, intuitive, and robust platform.

3.2 Database Design

In chapter 2 we have already viewed the ER diagram of the system data base. In this sections we
will view the tables of the Database in details showing its columns, constraints, and data types.
As an example, we will show two tables from the Data base which are “User” table and “Article”
table”.
3.2.1 User Table
The user table contain four columns which are: USER_ID, USER_NAME, PREFERENCES,
and FOLLOWS_ARTICLES. The USER_ID is Primary key of this table. The USER_NAME
must not be NULL. The following figures show the table in details.

a) Table

Figure 11User Table

b) Table constraints

Figure 12 User Table constraints

40
3.2.2 Article Table
a) Table

Figure 13 Article Table

b) Table constraints

Figure 14 Article Table constraints

41
3.3 System Interfaces Desing
In the System Interface Design section, we will present the visual layouts and interaction points
that define how users will engage with the system. This includes designing user-friendly
interfaces, such as input forms, dashboards, and navigation menus, that align with the system’s
functionality. The goal is to create intuitive, accessible, and efficient interfaces that enhance the
user experience and ensure seamless interaction with the system’s features. The designs will
serve as blueprints for the development phase, guiding the implementation of the system’s front-
end.
3.3.1 Home Page
In this page the website will display a list contain favorite sports for the user and a list of the
big news of the sport he is in. additionally, the website will display a list of the matches that
currently are playing or recently done. It will also have a list of the sports event to allow the
user to follow each event as he wants and the same apply for sport clubs and sport athletes.

Figure 15 System Home Page Interface

42
3.3.2 Specific sport page
In this page the list of sports will be replaced with the list of top leagues of that specific sport
also the articles will not be of all sports It will contain only sport-related articles.

Figure 16 Specific Sport website page

43
3.3.3 Club and event Details page
In the club and event details page. The club last few matches will be viewed and the upcoming
match for that club also. In addition, a list of top-rated players of the club according to the last
few matches performance.
Note:
This page is made for group sports only. In the individual sports such as: tennis and chess this
page will be replaced with athlete performance and athlete last few matches.

Figure 17Club and event Details page

44