Software Requirement

Specification for Kzonne

Table of Contents

1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms And Abbreviations 6
2. Overall Description 6
2.1 Product Perspective 6
2.2 Product Functions 7
2.3 User Characteristics 7
 2.4 Constraints 7
3. Specific Requirements 8
3.1 External Interface Requirements 8
3.1.1 User’s Interfaces 8
3.1.1.1 Standard User Interface 8
3.1.1.2 Facebook Administration Interface 13
3.1.2 Communication Interfaces 15
3.2 System Features 15
3.2.1 Creating An Event 16
3.2.1.1 Background Information 16
3.2.1.2 Stimulus/Response Sequence 16
3.2.1.2.1 Diagram 16
3.2.1.2.2 Description 17
3.2.1.2.3 Normal Flow Of Events 17
3.2.1.2.4 Alternative Flow Of Events 17
3.2.1.3 Functional Requirements 17
3.2.2 Attending An Event 18
3.2.2.1 Background Information 18
3.2.2.2 Stimulus/Response Sequences 18
3.2.2.2.1 Diagram 18
3.2.2.2.2 Description 18
3.2.2.2.3 Normal Flow Of Events 19
3.2.2.2.4 Alternative Flow Of Events 19
3.2.3 Searching Friends 19
3.2.3.1 Background Information 19
3.2.3.2 Stimulus/Response Sequences 20
3.2.3.2.1 Diagram 20
3.2.3.2.2 Description 20
3.2.3.2.3 Normal Flow Of Events 20
3.2.3.2.4 Alternative Flow Of Events 21

1
 3.2.3.3 Functional Requirements 21
3.2.4 Adding Friends 22
3.2.4.1 Background Information 22
3.2.4.2 Stimulus/Response Sequences 22
3.2.4.2.1 Diagram 22
3.2.4.2.2 Description 23
3.2.4.2.3 Normal Flow Of Events 23
3.2.4.3 Functional Requirements 23
3.2.5 Creating Groups 23
3.2.5.1 Background Information 23
3.2.5.2 Stimulus/Response Sequences 24
3.2.5.2.1 Diagram 24
3.2.5.2.2 Description 24
3.2.5.2.3 Normal Flow Of Events 24
3.2.5.2.4 Alternative Flow Of Events 25
3.2.6 Uploading Photos 25
3.2.6.1 Background Information 25
3.2.6.2 Stimulus/ Response Sequence 26
3.2.6.2.1 Diagram 26
3.2.6.2.2 Description 26
3.2.6.2.3 Normal Flow Of Events 26
3.2.6.2.4 Alternative Flow Of Events 27
3.2.7 Creating Albums 27
3.2.7.1 Background Information 27
3.2.7.2 Stimulus/ Response Sequence 27
3.2.7.2.1 Diagram 27
3.2.7.2.2 Description 28
3.2.7.2.3 Normal Flow Of Events 28
3.2.7.2.4 Alternative Flow Of Events 28
3.2.8 Sharing User Status 28

2
 3.2.8.1 Background Information 28
3.2.8.2 Stimulus/ Response Sequence 29
3.2.8.2.1 Diagram 29
3.2.8.2.2 Description 29
3.2.8.2.3 Normal Flow Of Events 29
3.2.8.2.4 Alternative Flow Of Events 30
3.2.8.3 Functional Requirements 30
3.2.9 Sending Messages 30
3.2.9.1 Background Information 30
3.2.9.2 Stimulus / Response Sequences 31
3.2.9.2.1 Diagram 31
3.2.9.2.2 Description 31
3.2.9.2.3 Normal Flow Of Events 31
3.2.9.2.4 Alternative Event Flows 32
3.2.9.3 Functional Requirements 33
3.2.10 Receiving Messages 34
3.2.10.1 Background Information 34
3.2.10.2 Stimulus / Response Sequences 34
3.2.10.2.1 Diagram 34
3.2.10.2.2 Description 34
3.2.10.2.3 Normal Flow Of Events 35
3.2.10.2.4 Alternative Event Flows 35
3.2.10.3 Functional Requirements 35
3.2.11 Commenting 36
3.2.11.1 Background Information 36
3.2.11.2 Stimulus / Response Sequences 36
3.2.11.2.1 Diagram 36
3.2.11.2.1 Description 36
3.2.11.2.3 Normal Flow Of Events 37
3.2.11.3 Functional Requirements 37

3
3.2.12 Uploading Videos 37
3.2.12.1 Background Information 37
3.2.12.2 Stimulus/ Response Sequence 38
3.2.12.2.1 Diagram 38
3.2.12.2.2 Description 38
3.2.12.2.3 Normal Flow Of Events 38
3.2.12.2.4 Alternative Flow Of Events 39
3.2.12.3 Functional Requirements 39
3.2.13 Creating Complaint Reports 39
3.2.13.1 Background Information 39
3.2.13.2 Stimulus / Response Sequences 40
3.2.13.2.1 Diagram 40
3.2.13.2.2 Description 40
3.2.13.2.3 Normal Flow Of Events 40
3.2.13.2.4 Alternative Flow Of Events 41
3.2.13.3 Functional Requirements 41
3.2.14 Reading Complaints 41
3.2.14.1 Background Information 41
3.2.14.2 Stimulus / Response Sequences 42
3.2.14.2.1 Diagram 42
3.2.14.2.2 Description 42
3.2.14.2.3 Normal Flow Of Events 43
3.2.14.2.4 Alternative Event Flows 43
3.2.15 Responding Complaints 44
3.2.15.1 Background Information 44
3.2.15.2 Stimulus / Response Sequences 44
3.2.15.2.1 Diagram 44
3.2.15.2.2 Description 45
3.2.15.2.3 Normal Flow Of Events 45
3.2.15.2.4 Alternative Event Flows 45

4
 3.2.15.3 Functional Requirements 46
4. Non-Functional Requirements 46
4.1 Performance Requirements 46
4.2 Design Requirements 46

5
6
 1. INTRODUCTION
This document is prepared in order to determine a software requirement specification
for Kzonne. Kzonne is a social network on which people can add their friends, share videos
and photos, send and receive messages, comment on the links etc. In order to gain an
overview about the report, firstly, the purpose and scope of this document will be given, then
an overall description of Kzonne system is followed. In addition to these, system features
such as uploading photo, sharing video, adding friend etc. are described deeply. After
mentioning about the introduction of the software system, the specific requirements will be
addressed for it. In the final part, functional and non-functional requirements will be
addressed.

1.1 PURPOSE
The SRS is needed to evolve as the development of the software product processes.
The purpose of this document is to give a complete description about how Kzonne social
network system can be developed. This document is to provide information about what the
software product is to do to customers and establish an agreement between customers and
suppliers and also become helpful for development. In addition to these, it provide a basis for
validation and verification. The issues which are basically addressed are functionality such as
adding friends, uploading photos, external interfaces, performance, attributes and the design
constraints of the system.

1.2 SCOPE
The name of the software product is Kzonne. Kzonne is a social network that connects
people. The aim of Kzonne is to unite all african together. The users of kzonne can add
friends, share videos which they want their friends watch; upload photos, comment on their
friends’ sharings, chatting with their friends and become informed about their friends.
Moreover, people can create social groups for such as university clubs, football clubs or for
social awareness. People can be informed about the events by the help of these groups or their
friends, people can their business pages , sell on the platform through the marketplace
system , people will be able to enroll courses and other features .

7
8
 1.3 DEFINITIONS, ACRONYMS and ABBREVIATIONS
When the user will logins into Kzonne, they can see their home page, which is named
as “News Feed” that provide users to see what their friends share, what their friends write
their status and to see ads running their pages. Moreover, at the left of this page, the user can
see the event invitations and the birthdays of their friends. Therefore News Feed is the main
page which combines daily friend interactions.

2. OVERALL DESCRIPTION

In this section, background information about what type of requirements the system
should have will be provided briefly.

2.1 PRODUCT PERSPECTIVE

Kzonne is an independent and will be world-wide social network website. Every
person can use it online without a fee. Kzonne is not a part of a larger system, it is an
independent system. People from different regions of the world can connect to it and exchange
information with other people. In order to control the contents of the sharings and comments
done by the other people, Kzonne has also a control mechanism. People can deliver their
complaints about any part of the Kzonne o the “ Kzonne Administrators”. Then, “ Kzonne
Administrators” might take appropriate actions according to the complained situation which is
against the rules.

Kzonne

Kzonne
users Kzonne administrator

Figure 2.1.1: Kzonne social network website system

9
 2.2 PRODUCT FUNCTIONS

After creating an account and starting to use the Kzonne, first thing he or she will
make is searching for friends. The user will search people by their names and can send an
invitation to them to add as a friend and to be able to see their shared items on Kzonne. If the
person accepts the invitation, these two persons become friends on Kzonne and can interact
more closely such as sending messages to each other.

Any user can share his/her status like whatever he is thinking, wherever he is or his
current mode. Friends of this person can make a comment on that. Furthermore, if a user
shared a photo, video, link or anything, any friend of that user can share that shared item also.

Users can upload photo and video to their profiles and create an album. Anyone can
create a group and invite people to join in the group. Similarly, people can attend the activities
where they are invited.

2.3 USER CHARACTERISTICS

Kzonne does not require any specific computer knowledge to use it except the
developers and administrators of it. Standard users are thought to be from any age, any gender
and from any nationality who can use just computer’s browser. On the other hand,
administrators and potential developers need a high level of expertise to understand web
technologies.

2.4 CONSTRAINTS

Being a social network website, the software should ensure the safety of information
given by the user and provide some privacy settings options to the user.

Firstly, Kzonne provides people the right to choose the category of people who will be
able to view their shared items. Some users may not desire the access of some people to their
shared items and information. If this is the case, users can set their privacy settings to prevent
some people’s access to their information.

Secondly, Kzonne cannot sell the private information of users to someone else.
However, if the user permits, an application can access to some information of the user.

3. SPECIFIC REQUIREMENTS

10
 In this section, all software requirements will be explained in detail. All requirements
are divided into two groups as functional and non-functional.

3.1 EXTERNAL INTERFACE REQUIREMENTS

In this section, external interface requirements for user and communication channels
will be described in order to clarify the relationship of this software with other entities and
systems.

In the first part, user’s interfaces will be explained with the layout information, textual
items and error handling types for two types of users of the system, as standard users and
Kzonne administrators. In the second part, communication interfaces of our system will be
described in order to explain the relationship with other systems which are sharing
information with Kzonne

3.1.1 USER’S INTERFACES

3.1.1.1 STANDARD USER INTERFACE

Standard users shall be using the web browser to use the product. Thus, it shall have a
login page and users must login with their e-mail addresses and passwords. After a successful
login, they shall be taken to their “News Feed” which is their homepage thereafter. Since they
are logged into the system, there must be logout button and their Kzonne profile names at the
top of the page until they logged out of the system. In addition, there shall be Help menu in
order to explain the processes of Kzonne to the users.

11
 Figure 3.1.1.1: Diagram for Standard User Interface of Kzonne

Being a social network, a direct link to the list of “Friends” shall be listed in the
“Account” menu, located at the right top, which shall also include “Logout” and “Account and
Privacy Settings”. At the top, there shall be “Home” and “Profile” buttons which are used for
linking News Feed and users’ own profile respectively. “Search” field which lets users search
for their friends, events, etc. shall be located at the center of the top in the whole processes.
All other features of the system shall be reachable by menu as a left sidebar such as Events,
Photos, Videos, Groups etc. In the menu, order of these features shall be updated according to
their usage levels for the users Finally, sub-functions, such as “Creating Event” which is
related to “Events” feature, shall be reachable from the related features menu.

Since standard users can use different types of features, there shall be different
interfaces for each of them and they will be described separately:

a) Creating an Event:

This function’s interface will be a form which contains text fields/areas and check boxes.
This form will have a “text fields” for “Date and Time”, “Name” and “Place” of the event.
Optional text fields for ending time will be shown when user clicks on “Adding End Time”

12
 and optional “Street” and “City/Town” will be shown when user clicks on “Adding Street
Address” button. There will be a “text area” which is for “Additional Information”.

There will be a button for selecting guests and when user clicks on this, friends list will be
shown to select. Finally there will be two check boxes for making event “Public Event” and
“Showing guest list to others”. In order to send this form, there will be a “Create Event”
button. If the user does not fill the form correctly, s/he will be notified and when the user
submits correctly s/he will be directed to Event page which is just created.

Creating businnes pages :

Here user will be able to create their businness pages where they can manage and
run their ads to attact more user their pages and their business

Attending an Event:

This function will be shown in the related event’s page at the top of the page. This will
be formed of three buttons for attendance situation of the user to the event. These shall be
“No”, “Yes” and “Maybe Attending”. When user clicks on “Yes” or “Maybe Attending”, s/he
will be listed in the guest list and when “No” is clicked no action will be taken.

b) Uploading Photo:

When this function is to be performed, there will be a button for choosing image files.
When user clicks on it, a file browser will be opened to select images. When user successfully
uploads the photo, s/he will get a notified, if an error occurs during the upload, the user bill be
informed about it.

c) Creating Album:

This function will have an interface as a form type. This form will include two text
fields for “Name of the Album” and “Location” and there will be a drop down menu for
selecting the album’s privacy settings. In order to complete form, there will be Cancel and
Create Album buttons. When user creates album s/he will be taken to uploading photo
function.

13
 d) Uploading Video:

With resembling to Uploading Photo interface this function will have a button for choosing
files to be uploaded and there will be a text field for the name of the video. In addition, limit
and copyright notifications will be shown (under 1024 MB and 20 minutes and user’s own
production). If user selects inappropriate files, s/he will be informed, on the other hand
successful uploading will take the user to the video page which is just uploaded.

e) Sending Message:

This function will use an interface constituted of one text field for message receiver
and one text area for message itself. There will be two buttons for attaching a file or picture
and one additional check box if the user wants this message to be sent as a text message also.
To complete form, there will be send and cancel buttons. Upon successful sending user will be
informed as “your message sent” and if no user selected or no message is written send button
will not take any action and no notification will be shown.

f) Receiving Message:

This function will be available through the “message received notification” in the
home page. Reaching the receiving message interface, the sent message will be shown with
the sender’s “Profile Name” and “Profile Picture”. Time at the message sent will be shown at
the right top of the message and subject of the message will be shown below time. In order to
continue conservation, at the bottom there will be Sending Message interface.

g) Sharing User Status:

For this function, there will be a text field for the status to be shared and there will be a drop
down menu for selecting the privacy level of the shared status for Friends, Networks or
Public. Finally, there will be a share button to complete the form. When the user exceeds the
limit of status, which is 420 characters, s/he will be informed for “Exceeding limit”; therefore

14
 the remaining character limit will be shown at the right top of the text area. Upon sharing in
the limits, the shared status will be shown in the News Feed thereafter.

h) Commenting:

This function will be reachable for the every shared item such as pictures, videos, user
status etc. This interface will have a text area for comments and when the user presses “Enter”
key after writing the comment in the text field, the comment will be listed thereafter in the
bottom of the related item.

i) Searching Friend:

This interface will be reachable from every page and will include one text field for text to be
searched and one button at the left to start searching. This interface will take the user to the
results page which shows the list of the search results.

j) Adding Friend:

This function will be reachable from every profile page which is not already added as a friend.
Clicking the “Add as a Friend” button from the top of the profile page, interface of this
function will be reached. This interface will have an optional button for adding “Personal
Message” to the other user which will open a text field for this personal message. At the right
bottom of the interface, there will be two buttons for cancelling the request and sending the
request. Sending the request successfully, an informative text will be shown at the profile
page of the user which the request sent as “a friendship request sent” instead of “Add as a
Friend” button thereafter.

k) Creating Group:

This interface will be in a form style. There will be a text field for the group name and
a text area for writing the names of the group members. At the bottom of the interface, a

15
 dropdown menu will help user to select the privacy level of the group and these will be
followed by create and cancel buttons. If the user either does not type a group name or any
friend’s name to be member of the group, the user will be informed. When the user
successfully fills fields, the interface will take the user to the group page which is just created.

l) Creating Complaint:

This interface will be reachable from any of the profile pages, shared items or events by clicking
a direct link. This interface will be in a form style which lets users to select any of the reasons
why they are complaining about the content. Therefore the reasons will be listed with radio
boxes. In order to send the complain report, there shall be “Continue” and “Cancel” buttons.
Upon successful sending the user will be informed about the completion.

E-learning pages :

Here user will be able to enroll course on the platform

3.1.1.2 Kzonne ADMINISTRATION INTERFACE

Administrators of the Kzonne will be using the administration features by logging into
their specific interface using a browser. Therefore, there shall be a login page which is
different than standard users’ login page and administrators shall use that page to login
system. After successful login they will be taken to the reading complaints interface directly.
In addition, administrator’s name, authority level and logout button shall be located at the top
of the page thereafter. Basic outline for the Facebook administrators’ interface can be seen the
figure below 3.1.1.2:

16
 Figure 3.1.1.2: Diagram for Interface of Kzonne Administrators

Administrators’ main responsibility will be reading and responding complaints,

however they will be able to search through Kzonne users and send message to them in order
to control activities of users that have complaints recorded against. Therefore, after a
successful login, administrators will be able to reach sending messages, searching, reading and
responding complaints interfaces by the direct links given at the top of the page.

Since searching and sending message interfaces are same as the standard users’
interfaces, they will not be described again in this part. On the other hand, Reading
Complaints and Responding Complaints interfaces will have different characteristics that will
be described as following:

a) Reading Complaints:

This interface will enable administrators to read the complaints that are sent.
Therefore, this interface will be in a list type which includes subject of the complaint, name of
the sender, content of the complaint and time when the complaint is sent. Administrator will
be able to sort the complaints according to their priority levels or to time at which the
complaint is occurred; therefore, at the top of the list related buttons shall be located. In
addition, administrator will be able to filter the complaints according to the time interval that
are sent, countries which they are sent from and priority levels. Therefore, drop down menus
for filtering functions must be located next to the list.

b) Responding Complaints:

This interface will enable administrators to take actions to the complaints that are sent.
Therefore this interface shall be shown at the bottom of the complaint which is related to.
These actions will include deleting the user account, sending an attention to the user and
deleting the shared item which does not obey copyright or privacy rules. Therefore, a drop
down menu in order to let the administrator to select an action shall be located. After taking a

17
successful action, or in this concept responding the complaint, a feedback will be given to the
administrator.

3.1.2 COMMUNICATION INTERFACES

As a whole social networking website, Kzonne will be completely stand-alone system

which lets other platforms connect, fetch and transform data in certain levels. Therefore, other
platforms such as mobile phone applications, namely Kzonne for Android, iPhone, Windows
Mobile etc., or other websites which want to use Kzonne integration will be connecting to the
Kzonne main system by using Kzonne Platform. Kzonne Platform will provide APIs and tools
to 3rd party developers to let them create high-level integrated plugins and programs.
Therefore main communication interface with the other platforms will be Kzonne Platform for
Kzonne. However, this integration and its level will be set by the user, who wants to integrate
their accounts and information with other websites. Basic outline of the communication
interfaces could be seen from the figure 3.1.2 below:

Kzonne

Kzonne platform

Figure 3.1.2: Communication Interfaces

18
 3.2 SYSTEM FEATURES
In this section, all normal and alternative flow of events are organized with the
assumption that users or administrators are successfully reached their homepage by loginning
to the system. This assumption is made in order to describe specifications of the sub-features
with better focusing.

3.2.1 CREATING AN EVENT

3.2.1.1 Background Information

Kzonne is a social network site so people want also to use Kzonne in order to inform
their friends and other people who are friends of their friends about activities and events. For
this reason, Kzonne provides users such a system feature. On the right hand side of the screen,
there is a link that opens the events page and at the left hand side of this events page, there is a
box which link to create an event.

3.2.1.2 Stimulus/Response Sequence

3.2.1.2.1 Diagram

19
 Kzonne

3.2.1.2.2 Description

Primary Actor Standard User

Goal in context The purpose of this feature is to enable users to create an event for
informing their friends about their activities.
Preconditions In order to create an event, people must have a Kzonne account.

Trigger User wants to create an event, which they want to make in real life, in
online manner.

3.2.1.2.3 Normal Flow of Events

1. User reaches the events interface from the homepage of Kzonne.

2. The necessary information is typed the required areas.

3. User clicks create an event to finish creating.

4. User is notified of the successful operation she has performed.

3.2.1.2.4 Alternative Flow of Events

20
 Alternative Event Flow 1:

3. User presses create event button without completing the name of the event.

4. User is notified that s/he must provide an event name.

Alternative Event Flow 2:

3. User presses create event button without filling the time of the event.

4. User is notified that s/he must provide an event time.

3.2.1.3 Functional Requirements

REQ. 1: System shall check whether the name of the event is entered.

REQ. 2: System shall check whether the time of the event is entered.

3.2.2 ATTENDING AN EVENT

3.2.2.1 Background Information

The created events can be sent to the people in user’s friend list in order to inform
them about the event and ask whether they attend or not. The users, who are sent event
request, can learn the details of the event and attend this event. After attending an event in
online manner, they can learn any change in the event schedule, place or content.

3.2.2.2 Stimulus/Response Sequences

3.2.2.2.1 Diagram

21
 Kzonne

3.2.2.2.2 Description

Primary Actor Standard User

Goal in context The purpose of this function is to enable the user to attend events in
the online manner and inform people about the changes.

Preconditions There must be a created event in order to attend.

Trigger User wants to attend and be informed about the events.

3.2.2.2.3 Normal Flow of Events

1. User reaches the event invitation interface from the homepage of Facebook.

2. User presses I’m attending button.

3. The page is renewed and the user added to attending list.

3.2.2.2.4 Alternative Flow of Events

2. User does not respond the event invitation.

3. The event invitation is removed automatically when the event time is finished.

22
3.2.3 SEARCHING FRIENDS

3.2.3.1 Background Information

Since Kzonne is introduced to people as a social network, searching friends is one of

the main features of Kzonne . This function of the system enable the users find their friends by
searching with their friends’ name. If the searched friend is Kzonne user and s/he do not close
their profile to searches from privacy settings, the search engine of Kzonne will come out the
people who has the searched name.

3.2.3.2 Stimulus/Response Sequences

3.2.3.2.1 Diagram

Kzonne

3.2.3.2.2 Description

Primary Actor Standard User

Goal in context The purpose of the feature is to help people find their friends.

23
Preconditions The typed names must be similar with the account names of the their
friends.

Trigger User wants to find their friends in order to communicate.

3.2.3.2.3 Normal Flow of Events

1. User reaches searching friend interface from every page.
2. User types the name of his/her friend in the search box.
3. The results are shown on the screen.

3.2.3.2.4 Alternative Flow of Events

Alternative Event Flow 1:

2. User typed a name that is not a name of the user of Kzonne.

3. User is notified of the no results.

3.2.3.3 Functional Requirements

REQ. 3: System shall not view the users who do not want to show themselves at
search results.

24
3.2.4 ADDING FRIENDS

3.2.4.1 Background Information

The users can add their friends from search results or from the name of their friends
that is listed as “people who you may know” part of the homepage. After reaching the
interface, the user can send request to his/her friend by clicking the “Add as Friend” button. If
the friend accepts the friend request by clicking accept option, the friend is added to friend
list.

3.2.4.2 Stimulus/Response Sequences

3.2.4.2.1 Diagram

Kzonne

3.2.4.2.2 Description

25
Primary Actor Standard User
Goal in context The purpose of the feature is to enable the users to add their friends
into their friends list.

Preconditions The friend must allow other people to add herself/himself as a friend.

Trigger User wants to add his friend to friend list to follow and communicate
his friend.

3.2.4.2.3 Normal Flow of Events

1. User reaches the profile page of her friend whom s/he want to add.
2. User presses add as friend button.
3. User is notified of the friend request is sent.

3.2.4.3 Functional Requirements

REQ. 4: If the other user has set privacy level to prevent others adding as a friend, system
shall not let other users add as friend.

3.2.5 CREATING GROUPS

3.2.5.1 Background Information

The users can create groups for common shared view, activity or information. At the left
hand side of the screen, there is create group link. The users can create groups by clicking this
link. They must name the group; add their friends who they want to member of the group and
must be select privacy feature when they create a group. After the creation, the admin can send
to request to others to join the group.

26
 3.2.5.2 Stimulus/Response Sequences

3.2.5.2.1 Diagram

Kzonne

3.2.5.2.2 Description

Primary Actor Standard User

Goal in context The purpose of this feature is to enable to users create groups in
online manner and share posts with group members.

Trigger User wants to create a group to share information and collaborate.

3.2.5.2.3 Normal Flow of Events

1. User reaches the create group interface from the homepage of Kzonne.

2. The necessary information is typed the required areas.

3. User presses the “Create an event” button.

4. User is notified of the successful operation s/he has performed.

27
 3.2.5.2.4 Alternative Flow of Events

3 User presses create button without completing the group name.

4. User is notified that s/he must write a group name.

3.2.6 UPLOADING PHOTOS

3.2.6.1 Background Information

In order to upload a photo in a already created album or upload photo without having
an existing album, the user should click on the profile tab on the right top of the Kzonne page.
Then, if the user wants to add a photo to an album, the user should choose the album first and
then the photo from the file browser. If the user does not want to upload a photo to existing
albums, then an album has to be created first.

3.2.6.2 Stimulus/ Response Sequence

3.2.6.2.1 Diagram

28
 3.2.6.2.2 Description

Primary Actor Standard user

Goal in context The aim of the user is to upload a photo on his/her profile and
make his/her friends see it.

Preconditions User has to have an created album.

Trigger User wants to upload a photo to an album.

3.2.6.2.3 Normal Flow of Events

1. User clicks the profile tab and sees the already created albums.

2. User clicks the album where he wants to add a photo.

3. User chooses the photo from the file browser and marks one of the quality options
in the radio box.

4. If the user desired, s/he can tag his friends in the photo.

5. User is notified that s/he successfully uploaded the photo.

3.2.6.2.4 Alternative Flow of Events

1. When the user wants to upload photo without choosing an album, album creation
form is opened.

3.2.7 CREATING ALBUMS

3.2.7.1 Background Information

When the user wants to create an album on his profile, a form type interface will
appear with fields or “Name of the Album” and “Location”. In addition to these, there will be

29
a quality of the photos option and a drop down list to choose the group with whom the album
will be shared. After this step, the user will be directed to photo uploading feature. Finally, the
user can click on create the album or cancel option.

3.2.7.2 Stimulus/ Response Sequence

3.2.7.2.1 Diagram

3.2.7.2.2 Description

Primary Actor Standard user

Goal in context The aim of the user is to create an album on his profile and make
his friends see it.

Preconditions The user should be logged in.

Trigger User wants to create an album.

3.2.7.2.3 Normal Flow of Events

1. User reaches the album creation form.

2. User fills the required fields.

3. Photo uploading stage takes place.

4. User chooses create album and completes creation.

30
 3.2.7.2.4 Alternative Flow of Events

4. If the user clicks on the cancel at the end of the process, a warning box will
appear asking for user’s approval.

3.2.8 SHARING USER STATUS

3.2.8.1 Background Information

At the top of the news feed part of the Kzonne page, there will be a part for user status. This
part will be consisting of four different type of sharing. The user can only text whatever he
wants or share a photo, url or a video. The user can select the privacy level of the shared status
for Friends, Networks or Public as well. There is a limit for status text which is 420
characters. If the user exceeds it, a notification message will be appeared. After, creating the
status, the status will be shown on the news feed after clicking on the share button. Other user
can click on the “like” the sharing as well.

3.2.8.2 Stimulus/ Response Sequence

3.2.8.2.1 Diagram

31
3.2.8.2.2 Description

Primary Actor Standard user

Goal in context The aim of the user is to share her/his current status.
Preconditions The user should be logged in.
Trigger User wants to share an item on the news feed.

3.2.8.2.3 Normal Flow of Events

1. User shares text less than 420 characters, url, photo or a video.
2. User sets the privacy settings and clicks on the share button.

3. Status is shown on the news feed.

3.2.8.2.4 Alternative Flow of Events

1. User exceeds the limit and gets an error message.

32
 3.2.8.3 Functional Requirements

REQ. 5: A user can like the sharing if he/she is included in the group specified in the
privacy settings by the user who shared the status.
REQ. 6: System shall check whether the size of the status is less than 420 characters.

3.2.9 SENDING MESSAGES

3.2.9.1 Background Information

Being a social network, Kzonne will enable users to send messages to each other.
Sending message interface will be available from messages menu in the homepage and this
will let users to send messages to their friends. In addition, there will be direct links at the
profile pages, which lets users send messages to the profile owner they are visiting, therefore
users will be able to send messages to the people that are not their friends.

Sending message will include filling a text area and optionally attaching images or any
other kind of files to the messages. In addition, sender will be able to choose to send the same
message as an SMS message to the receiver, if the receiver is a friend of sender in the Kzonne.

3.2.9.2 Stimulus / Response Sequences

3.2.9.2.1 Diagram

33
 3.2.9.2.2 Description
Primary Actor Standard User
Goal in context The purpose of this feature is to send messages, optionally with
attachments, to the other users, which are already their friends or not.

Preconditions Receiver should have set her/his privacy level to receive messages from
other users.

Trigger User wants to send a message to the other user.

3.2.9.2.3 Normal Flow of Events

1. User reaches the sending message interface from the homepage of

Facebook.
2. User chooses a friend’s name by writing it.
3. User types the message s/he wants to send.
4. User clicks send button.
5. Sending message interface closes after the notification that the
message is sent.

3.2.9.2.4 Alternative Event Flows

34
 Alternative Event Flow 1 (Related to Normal Flow of Events and Alternative Event
Flow 6):

4. User clicks attachments button.

5. File browser opens to let user select files.
6. User selects files.
7. Selected files are uploaded.
8. User clicks send button.
9. Sending message interface closes after the notification that the message is
sent.

Alternative Event Flow 2 (Related to Alternative Event Flow 1):

6. User selects inappropriate types of files, such as system files and executable
files.
7. User is informed that these kinds of files cannot be sent as attachments.

Alternative Event Flow 3 (Related to Alternative Event Flow 1)

6. User exceeds the attachments size limit, which is 25 megabytes.

7. User is informed that the total size of attachments is exceeded.

Alternative Event Flow 4 (Related to Normal Flow of Events)

5. User exceeds the message length limit, which is 10000 characters

including spaces.
6. User is informed that the message is too long.

Alternative Event Flow 5 (Related to Normal Flow of Events)

35
 4.User checks send as an SMS option.
5. User clicks send button.
6. Sending message interface closes after the notification that the
message is sent.

Alternative Event Flow 6 (Related to Normal Flow of Events)

1. User reaches the sending message interface from the receiver’s profile page.
2. User types the message s/he wants to send.
3. User clicks send button.
4. Sending message interface closes after the notification that the message is
sent.

3.2.9.3 Functional Requirements

REQ. 7: System shall check whether the receiver allows receiving messages.
REQ. 8: System shall check whether sender and receiver are friends to allow sending by
SMS.
REQ. 9: System shall check the file types of attachments to prevent misuse of messages.
REQ 10: System shall check the size of the attachments, whether total size of attachments is
less than 25 MB.
REQ 11: System shall check the length of the message, whether it is longer than 10000
characters.

3.2.10 RECEIVING MESSAGES

3.2.10.1 Background Information

This feature will enable standard users to receive the messages that are sent to them. Using
this feature, users will be able to see the list of the messages that are sent to them with the subject of
the message, sender’s name and picture. In addition, time the message sent will be shown and

36
messages will be listed from the newest to the oldest message. Since this list will contain both read and
unread messages, unread messages will be notified in the list view.

3.2.10.2 Stimulus / Response Sequences

3.2.10.2.1 Diagram

3.2.10.2.1 Description

Primary Actor Standard User

Goal in context The purpose of this feature is to convey the messages that are sent to
user by correctly listing the archive of sent messages.

Preconditions The primary actor should be able to receive messages according to

his/her privacy settings.

Trigger Being notified about unread messages or not, the user wants to read
the messages that are sent.

3.2.10.2.3 Normal Flow of Events

1. User reaches the messages interface from the homepage of Facebook.

2. User clicks an unread message that is listed.

3. Message content is fully shown to the user and unread sign is removed from the
message.

4. User leaves receiving message interface.

37
 3.2.10.2.4 Alternative Event Flows

Alternative Event Flow 1:

2. User clicks an already read message that is listed.

3. Message content is fully shown to the user.

4. User leaves receiving message interface.

Alternative Event Flow 2:

4. User writes a reply through Sending Message interface shown in the bottom of the
message that is received.

5. Sending Message feature event flow is followed.

6. User leaves receiving message interface.

3.2.10.3 Functional Requirements

REQ. 12: System shall view the messages only that are sent to the user.

3.2.11 COMMENTING

3.2.11.1 Background Information

This feature will enable standard users to comment on the shared items on the Kzonne.
Commenting will be done by an interface of a text field located at the bottom of every shared item
throughout the Kzonne. This feature and the interface will be available only on the friends’ shared
items; however comments will be shown to the every user who could see the shared item.

38
 3.2.11.2 Stimulus / Response Sequences

3.2.11.2.1 Diagram

3.2.11.2.1 Description

Primary Actor Standard User

Goal in context The purpose of this feature is to enable users to share their ideas on the
shared items all over the Kzonne.

Preconditions Primary actor must be the friend of the other user in order to comment
on the other user’s shared item.

Trigger The user wants to comment on the other friends’ shared item.
3.2.11.2.3 Normal Flow of Events

1. User reaches commenting interface from any shared item.

2. User types the comment into the text field.

3. User presses enter.

4. Written comment is shown thereafter and new comment interface is

located under that comment.

5. User leaves commenting interface.

39
 3.2.11.3 Functional Requirements

REQ.13: System shall view commenting interface only for the friend’s shared items.

3.2.12 UPLOADING VIDEOS

3.2.12.1 Background Information

Uploading video includes similar steps with uploading a photo. The user should click on
his profile and then upload video button. Then, the file browser will be opened and the user can
select the video from there. However, the video must be less then 20 minutes or 1024 MB and it
has to be user’s own production, not a copyrighted video. In case of inappropriate files, the user
will be notified. If it is successfully uploaded, the user will be directed to the page where the
video is uploaded.

3.2.7.2 Stimulus/ Response Sequence

3.2.8.2.1 Diagram

40
3.2.12.2.2 Description

Primary Actor Standard user

Goal in context The aim of the user is to upload a video.
Preconditions The user should be logged in.
Trigger User wants to upload a video on his profile.

3.2.12.2.3 Normal Flow of Events

1. User chooses a video less than 20 minutes or 1024 MB and not a copyrighted video
from the file browser.

2. User clicks on the upload button.

3. The video is uploaded to profile page.

3.2.12.2.4 Alternative Flow of Events

Alternative Flow 1:

1. User exceeds the limit and notified about unsuccessful operation.

Alternative Flow 2:

1. User chooses a copyrighted video and notified about unsuccessful operation.

Alternative Flow 2:

1. User chooses an unsupported video format. An error box with a list of supported
video format will be appeared.
2.

3.2.12.3 Functional Requirements

41
 REQ. 14: System shall check whether the size of the video is less than 20 minutes or 1024
MB .

REQ. 15: System shall check whether the video is copyrighted or not.

REQ. 16: System should support all the video formats of the other platforms that are connected to
Facebook.

3.2.13 CREATING COMPLAINT REPORTS

3.2.13.1 Background Information

This feature will enable standard users to report their complaints to the Kzonne
administrators, which is the only controlling mechanism of this social network. Standard users will be
able to report copyright issues, harassment, inappropriate profile pictures and posts (shared items)
therefore this feature will be reachable from any part of Kzonne. After selecting appropriate reasons
from the creating complaints interface, report will be sent to the database and user will be informed
that complaint is successfully sent.

3.2.13.2 Stimulus / Response Sequences

3.2.13.2.1 Diagram

42
 3.2.13.2.2 Description

Primary Actor Standard User

Goal in context The purpose of this feature is to enable users to report inappropriate
use of Kzonne

Preconditions The profile or the item about which the complaint will be reported,
should not have any unresolved complaints.

Trigger The user wants to report a complaint about any item or the profile in
the Kzonne

3.2.13.2.3 Normal Flow of Events

1. User reaches creating complaint interface from any shared item or profile page.

2. User selects any one of the reasons.

3. User clicks continue button.

4. User is notified about successful report sending.

5. User leaves commenting interface.

3.2.13.2.4 Alternative Flow of Events

Alternative Event Flow 1:

2. User does not select any of the reasons.

3. User is informed that s/he must select one of the options in order to continue.

Alternative Event Flow 2:

1. User reaches creating complaint interface of a profile page or item that the user has already
reported.

43
 2. User is notified that a report is already submitted.

3.2.13.3 Functional Requirements

REQ. 17: System shall check whether the user has selected a reason to submit a report.

REQ. 18: System shall check whether the user has already submitted a report about the
content which is going to be reported.

3.2.14 READING COMPLAINTS

3.2.14.1 Background Information

This feature will enable administrators to read complaints that are sent by standard
users. Using this feature, administrators will be able to sort, filter and read complaints before
taking any action. Therefore this feature will list complaint reports by showing priority,
subject and item type which is reported. Alike reading messages feature, in the list, reports
that no action taken will be shown differently than the reports that actions taken against them.

3.2.14.2 Stimulus / Response Sequences

3.2.14.2.1 Diagram

44
 3.2.14.2.2 Description

Primary Kzonne Administrator

Actor
Goal in The purpose of this feature is to enable the administrators to read complaints
context that are sent by standard users.

Trigger In order to control user activities, Kzonne Administrators regularly read

complaint reports.

3.2.14.2.3 Normal Flow of Events

1. Administrator reaches reading complaints interface from the

administrator homepage.

2. Administrator clicks any of the unread complaints.

3. Complaint content is fully shown to the administrator.

3. The complaint is marked as read.

4. Administrator leaves reading complaints interface.

45
 3.2.14.2.4 Alternative Event Flows

Alternative Event Flow 1:

2. Administrator clicks any of the listed complaints which are already

marked as read.

3. Complaint content is fully shown to the administrator.

4. Administrator leaves reading complaints interface.

Alternative Event Flow 2:

4. Administrator wants to take an action to the complaint which is read.

5. Responding Complaints feature event flow is followed.

6. Administrator leaves reading complaints interface.

3.2.15 RESPONDING COMPLAINTS

3.2.15.1 Background Information

This feature will enable administrators to take actions to the complaints that are sent by
standard users. Using this feature, administrators will be able to delete user profiles, remove
shared posts, pictures, videos etc. and send notification messages. Therefore this feature will
let administrators select an appropriate action to the read complaint report. After taking
actions, the administrators will be informed about the completion of the process and the
priority of the report will be decreased and it will be shown as completed thereafter.

46
 3.2.15.2 Stimulus / Response Sequences

3.2.15.2.1 Diagram

3.2.15.2.2 Description

Primary Kzonne Administrator

Actor
Goal in The purpose of this feature is to enable the administrators to take actions to the
context complaints that are sent by standard users.

Preconditions No action must be taken against to the complaint report before.

Trigger In order to control user activities, Kzonne Administrators must respond to the
complaint reports.

3.2.15.2.3 Normal Flow of Events

1. Administrator reaches responding complaints interface from the reading

complaints interface.

47
 2. Administrator chooses any of the actions to take against the complaint.

3. Related actions are taken.

3. Administrator is informed about the completion of action.

4. Administrator leaves reading complaints interface.

3.2.15.2.4 Alternative Event Flows

Alternative Event Flow 1:

2. Administrator does not select any of the actions.

3. Administrator is informed that at least one action must be taken.

3.2.15.3 Functional Requirements

REQ. 18: System shall check whether the administrator chooses at least one action.

REQ. 19: System shall not let administrators to take actions to the complaints that are
completed.

4. NON-FUNCTIONAL REQUIREMENTS

4.1 PERFORMANCE REQUIREMENTS

System shall be available from all over the world at all times. Being a social network,
any interruption in the sharing chain will cause people to give up on Kzonne, therefore it is
essential that the system shall be available at all times.

48
 System shall not be affected from the number of active users in the system until half of
the registered users become active. Being a worldwide network, assuming that half of the
registered users are reaching to the website is a legitimate and necessary requirement.

4.2 DESIGN REQUIREMENTS

Design of the system shall arrange the content size as compatible for different
platforms, such as mobile phones, tablets and desktop computers. Since Kzonne is based on
sharing with friends, design of the system shall let high level of mobile access.

Design of the system shall let different languages to be shown without affecting the
general layout and operations. Being a worldwide network, different language sets shall be
able to shown as the main language of the website without creating any obstacles on the
operations.

49