ECHOES Online Community

Software Requirements
Specification
Version EICT010
Status: Draft

Prepared by Kajang Moses

Project Manager / Senior Developer

KRE8IVE QULTURE

17th November, 2019.

1
Table of Contents

1. Introduction ............................................................................................... 4
1.1 Purpose ................................................................................................................... 4
1.2 Intended Audience STAKEHOLDERS: ................................................................... 4
1.3 Product Scope.......................................................................................................... 4

2. Overall Description .................................................................................... 5

2.1 User Classes and Characteristics .............................................................................. 7
2.2 Operating Environment ........................................................................................... 7
2.3.1 User Documentation ............................................................................................. 8
2.3.2 Assumptions and Dependencies ............................................................................ 8

3 External Interface Requirements.............................................................. 9

3.1 User Interfaces ........................................................................................................ 9
3.5 Software Interfaces ................................................................................................ 10
3.5.1 Communication among components .................................................................... 11

4 System Features (Use Cases) ................................................................... 11

4.1 Use Case Student Account Creation .......................................................................... 11

5 Other Nonfunctional Requirements ....................................................... 13

5.1 Characteristics ...................................................................................................... 13
5.2 Security Requirements ........................................................................................... 13

2
Revision History
Name Date Reason for Changes
< Author’s Name> <Date of Revision> <Description of Made
Changes>

3
1. Introduction
1.1 Purpose

An online social community system developed for ICT University students who
share similar goals and outlook spanning broadly across academic and social
issues, to interact with each other in real-time. While providing a bedrock for
informative and resourceful information affecting the community and society at
large.

1.2 Intended Audience

STAKEHOLDERS:

ID Stakeholder Description
Primary targeted audience, platform is designed to
S-1 Students
provide multi-level functions for total engagement.
Forming the accurate vision of the project, detailed
S-2 Development team functional and nonfunctional requirements including
project development.
Oversight functions, information gathering, advanced
S-3 Administrators
security responsibilities and resource management
Multi-level resource miners, verified informants,
S-4 Contributors
mobilizers and influencers
S-5 QA team Making test-plans, test-cases and questionnaires.
Estimating the quote of the project, planning
S-6 PM/BA
resources and the timeline of work.
Non-targeted audience, information seekers and
S-7 Visitors
general users with minimal level access.

1.3 Product Scope

A social community Realtime system developed for ICT University students to

provide administration and students with the opportunity to interact with each
other in and out of campus, on issues bothering on vital topics related to social,
academic, communiques and more. This platform shall also provide an enabling
environment for to students to get to know up close other students sharing similar
outlooks.

Greater Reach for Vital Communique between school management and students

4
Improve the Social Community Supporting Structures already placed on ground.

1.4 References

How to Launch a Successful online community: A step-by-step guide

Building an online community: The why, The how, and the What
How to make an online community platform
Bbpress
phpbb

2. Overall Description
The web application requires both Internet and occasionally GPS connection to
fetch and display results. All system information is maintained in a database,
which is located on a web-server. The web application interacts with the GPS-
Navigator software, which is required to be already installed on the user’s
mobile phone, as well as external resources integrated from a wide range of
resource base, using API’s and modules for execution. Information is updated
regularly through the help of external trusted vendors and editors, along with
our skilled contributors.

2.1 Product Perspective

The Echoes platform is a follow-on member of the pre-existing Moodle system

set up by the school, however this system places priority on academic activity
function. Echoes is set-up to address vital issues and functions bordering on
student interaction and networking which may be overlooked by the existing
system. The features of both systems include:

Existing System:
• Course management
• Student – Lecturer communication
• Attendance
• Academic and Grades management
• Overall academic oversight

Proposed system:
• Real-time Information
• Improved social Infrastructure
• Live Chatrooms and forums
• Educative Discussion Board

5

Authenticated User
ICThub
Unauthorized User
Promoters & Sponsors
Product Functions
Contributors
•Content Development
•Forum Input
•Information Gathering
•Community Influencing
Students, Visitors &
Alumni
•Community Development
•Networking
•Solution Development
•Skill Acqusition
Information Flow
6
Multi-level access to
Administrator
information & resources
Multi-level access to
Development Team information & resource
control
Low-level information
Contributors
and resource input
Information, forums,
Students discussion, Networking,
social development
Basic Information
Visitors
Update
Contributions, vital
Alumni Information update,
Oppurtunities
Investment
oppurtunities, promoting
goals, mentorship and
internship
Administration
•Resource Support
•Project Oversight
•Student Feedback
•Infromation
Development Team
•Enviroment Development
•Platform Maintainance
•Database Management
•Content Management
 2.1 User Classes and Characteristics

The user classes and their various characteristics are explained in details in the
table below.
• Administrator
• Development Team
• Students
• Contributors

User Class & Characteristics:

ID User classes Description

A signed-up user who has

completed the account activation.
U-1 Administrator He owns expanded rights inside
the portal. He performs the content
pre moderation.
A signed-up user who has
completed the account activation,
and owns multi-level rights and
U-2 Development Team access to the platform. performing
different roles of content
management and design
modification
A user of the portal who has
completed the sign up on the
U-3 Student portal and the account activation.
Having access to available
features of the system.
A signed-up user who has
completed account activation,
U-4 Contributors
while also possessing low-level
rights inside the portal.
A user of the portal who has
completed neither the sign up on
U-4 Not signed up user the portal, nor the account
activation. He owns limited rights
inside the portal.

2.2 Operating Environment

• HTML • CSS

7
 • JAVASCRIPT • JQUERY
• PHP • GITHUB
• WORDPRESS • FACEBOOK
• PHOTOSHOP • TWITTER

2.3 Design and Implementation Constraints

● Specific technologies, tools, and databases to be used are mostly paid and
not open sourced.
● Hardware limitations (timing requirements, memory requirements).
● Binding agreements or development standards.
● Restrictions imposed by school management rules.
● Interfaces adaptation to multiple screen sizes.
● Standard data exchange protocols.
● design conventions or programming standards (for example, if the
customer’s organization will be responsible for maintaining the delivered
software);
● Language requirements;
● Communications protocols;
● Security considerations.

2.3.1 User Documentation

• Design & user manual

• SRS
• Mock-up Designs
• Account Details & Description
• Development plan & milestones
• Proposed future updates

2.3.2 Assumptions and Dependencies

✓ This system is a compliment to the existing platform hence the need for
the integration is paramount at some point, however factors bordering on
security, third-party components and modules and others must be
carefully considered. This should prevent fatally affecting the system.

✓ The cost of startup, launch and early management might prove to be

important for successful delivery of the proposed system.

8
 ✓ Issues linked to administrative access and permissions could affect
effective system delivery.

✓ Human resource management is key for this community development,

hence the need for influencers and broad social coverage.

3 External Interface Requirements

Requirements for the external interface define the tools, software or database
elements with which the system or the component should interact. The proposed
system would require these components to execute all available features
attributed to this system at different access levels.

3.1 User Interfaces

The user interface of this platform is built to operate on both mobile and
desktop systems, the usability of this software product is placed at high priority
allowing adaptation for various environments and case scenarios
The System deals mainly with hardware devices and installed software
components on devices. The System performs many tasks. It consists of web-
based system used by Super Users (Development team), Administrators and
Students of the university. The system helps to record students’ personal
details, publish articles, preview poll result, select categories and more.
Therefore, the web-based part is expected to run on various operating system
platforms. The client server architecture of the system requires to remotely
connecting with client and server through the internet connection. The system
has two nodes such as the Web server and Clients. The nodes can represent
specific instances (workstations) or a class of computers (web server), which is
a virtual machine. The applications of the system will run on the web server
connected to the database server.

3.2 Hardware Interfaces

Internet is the worldwide interconnection of all smart communication devices
that have a valid IP. There should be installed browser software to access
internet. If the user accesses the system, directly through the internet connection
the user has to install dongle or modem or relevant device and WIFI or etc. To
connect with the system. If the user accesses the system through the intranet
connection, the server should install the relevant software. Most of intranet
accessing modes refer to the website of the organization which can only be

9
accessed by its employees who have a user name and password. So, considering
that type of security purposes, it is better to access this Student account through
the intranet, but it should be accessed through the internet directly also.

3.4 Hardware Requirements (Processor RAM Disk Space)

Pentium II, Pentium III, Pentium IV, Intel, CORE i3 and Higher, 150 Mb or
Higher ROM, 16G or Higher RAM, Lollipop Android OS and higher, IOS.

Physical arrangement of devices in a typical network.

In this diagram, it shows that, the only software a client need is to access this
system is a browser.

3.5 Software Interfaces

Win-7, Win-8, Win-10 Linux, My SQL, jQuery library, Bootstrap library,

Google API, Google Docs, Google Cloud, GitHub, WordPress, Web
Browser.

10
 3.5 Communications Interfaces

Our University Student Management System needs some specific set of servers
and devices. Such as: Server to host web applications and web service
applications. Database server to store and manage data. Personal computer, note
book, smart phone etc. to access the website. Modem/ router/ switch/ hub/ Wi-
Fi network/ cable network etc. and also need an Internet Service Provider to
have the internet connectivity.

3.5.1 Communication among components

Above devices are communicating with each other. Personal computer
communicates with web server and the database server through HTTP
protocol. It communicates with mail server through SMTP protocol.
Cable network or Wi-Fi network is also a communication method using
in connecting different network components.

4 System Features (Use Cases)

4.1 Use Case Student Account Creation

Case 1:
Brief User access landing page
Description: Students creates account
Student modifies personal account details
Student access integrated features
Business Student inputs sign up credentials
Trigger:
Preconditions: Students credentials are validated, recorded and authenticated

Basic Flow: Student sign up credentials authenticated, Student access home page, student
converts created features, Student contributes to community through
Assumptions: All extended student credentials and profile modifications are verified and
successfully recorded.
Line System Actor Action System Response
1 1. The student user access signs 1. If user name is equal to the registered
up portal Username & the password is equal to
2. Get Username and Password the registered Password
3. Then login successful 2. Access student portal
3. End If.
4. Else login failed

11
 2 1. Student login to account 1. Student modifies profile details
2. Select student personal details 2. Modifications are validated and
option recorded.

Post Condition: Based on student preference in profile details various modules are
made available in the home page of the student profile portal. Giving
him access to multiple conversion cases.

Alternate Flow (AF2): Student access registration portal, students’ inputs required details,
Input is verified and authenticated, Student is redirected to login process.

Assumptions: Student inputs have passed all validation rules and have been authenticated.
Upon which a new record would have been successfully created in the database.
Line System Actor Action System Response
1 1. The student user access signs 1. Validate Student inputs with
up portal client-side rules
2. Get Full-name, email, 2. Authenticate inputs with server-
Department, Matric No, contact No. side rules
3. Then login successful 3. Add input to record in database.

4. Else login failed

2 3. Student login to account 3. Student modifies profile details

4. Select student personal details 4. Modifications are validated and
option recorded.

Non-Functional Requirements:
1 Secure access of confidential data (user’s details). SSL can be used.
2 24hour availability.
3 Better component design to get better performance at peak time.
4 Flexible service-based architecture will be highly desirable for future extension

Data Requirements:
1. Name-Name contain first name, middle name, last name.

2. Matriculation No.

3. Date of Birth

4. Faculty

5. Department

6. Language Preference

12
 7. Phone number (Permanent)

8. Phone number (Mobile)

9. Email address

5 Other Nonfunctional Requirements

5.1 Characteristics

i.System should support multi-user environment.

ii.System should be fully automated.
iii.System should be capable to keep track of all the detailed descriptions
of the client and the whole details of services offered by the client
organization.
iv.Various outputs (reports) should be available online any time.
v.System should be able to handle extremely large volumes of data (i.e.
Large database support)

5.2 Security Requirements

i. All data stored on this system are restricted to high-level

administrators, developer has no obligation to provide such
information to anybody, unless on high-level security instances.
ii. Multi-level access is granted to different classes of users in this
system

iii. All data stored on this system must be verifiable upon notification.

iv. System should provide concrete security features like creating users
and assigning privileges to users of the system.

v. Users should under no circumstance provide their sign inn details to

a third-party.

vi. All third-party components integrated in this system are tested and
trusted.

13