SPKRDRM Project - Srs - v5

Zfort Group Friendly Web Technologies
www.zfort.com
contact@zfort.net
Software Requirements
Specification
For
SPKDRM Project
Version 5 draft

www.zfort.com
contact@zfort.net
Revision History
[Every change to this document must be recorded in the revision history chart below.
Modifications to this document will be documented in the following chart.
There are no exceptions. Note that the Project Owner and the Project Manager must sign off
on any changes to this document.]
Date
Revision
Description
Author
01/16/15
V1
First draft
Alex Tuchkov
01/20/15
V2
Second draft
Alex Tuchkov
01/23
V3
Third draft
Alex Tuchkov
01/27
V4
Fourth draft
Alex Tuchkov
01/29
V5
Fifth draft
Alex Tuchkov
Contacts
Name
Role
Contact details
Alex Tuchkov
PM/BA
tuchkov@zfort.com

www.zfort.com
contact@zfort.net
Table of Contents
1.
Purpose................................................................................................................ 6
1.1. Intended Audience and Reading Suggestions................................................6
1.2. References..................................................................................................... 7
1.3. Definitions of main entities............................................................................ 7
1.4. Executive Summary....................................................................................... 8
2.
Overall Description............................................................................................. 10
2.1. System Architecture..................................................................................... 10
2.2. General User Characteristics........................................................................11
2.3. General Flow................................................................................................ 12
2.4. Screen flow................................................................................................... 13
2.5. Admin Panel Sitemap................................................................................... 14
3.
Functional Requirements....................................................................................16
3.1. Application General Layout..........................................................................16
3.2. Splash.......................................................................................................... 17
3.3. Application Authentication Flow Sign Up.................................................18
3.4. Application Authentication Flow Sign In..................................................23
3.5. About / Tutorial............................................................................................. 24
3.6. Spectrum...................................................................................................... 25
3.7.
DASM........................................................................................................ 27
3.7.1.
Problem................................................................................................ 27
3.7.2.
Solution Concept..................................................................................28
3.7.3.
Lens...................................................................................................... 29
3.7.4.
Flow...................................................................................................... 30
3.7.5.
Lens...................................................................................................... 31
3.7.6.
Confirm................................................................................................ 31
3.8. Topic Interaction........................................................................................... 32

3.9. User Account................................................................................................ 34
3.9.1.
4.
Upgrade to premium............................................................................ 35
3.10.
Blog.......................................................................................................... 35
3.11.
History...................................................................................................... 37
Serverside application........................................................................................ 39
4.1. Role-based access control............................................................................ 39
4.2. Entities......................................................................................................... 40

www.zfort.com
contact@zfort.net
5.
4.2.1.
User Entity........................................................................................... 40
4.2.2.
Topic Entity........................................................................................... 40
4.2.3.
Fingerprint............................................................................................ 41
4.2.4.
Client.................................................................................................... 41
4.2.5.
Blog/FAQ............................................................................................... 42
4.2.6.
Admin/Editor........................................................................................ 42
API...................................................................................................................... 43
5.1. User.............................................................................................................. 43
5.2. Topics........................................................................................................... 43
5.3. Blog.............................................................................................................. 44
6.
Serverside application........................................................................................ 45
6.1. Role-based access control............................................................................ 45
6.2. Responsive views......................................................................................... 46
6.3. Admins Dashboard...................................................................................... 48
6.4.
Functional widgets................................................................................... 49
6.5.
Activity Stream......................................................................................... 50
6.6.
Statistics widget....................................................................................... 51
6.7.
User Management.................................................................................... 52
6.8.
Editor........................................................................................................ 53
6.9.
Statistics.................................................................................................. 55
6.10. Billing....................................................................................................... 55
6.11. Account.................................................................................................... 57
6.12. Editor........................................................................................................ 58
6.13. Editor Topic Editor and Topic Scheduler....................................................59
6.14. Manage FAQ section................................................................................. 64
6.15. Manage Notifications................................................................................65
6.16. Blog/Pulse................................................................................................. 67
6.17. Account.................................................................................................... 69
6.18. Dashboard Client...................................................................................... 71
6.19. Pulse......................................................................................................... 72
6.20. Topics....................................................................................................... 73
6.21. FAQ........................................................................................................... 79
6.22. Client Notifications................................................................................... 80
6.23. Client Account.......................................................................................... 81
6.24. Client Data Mining TBD............................................................................82
7.
Non Functional requirements............................................................................. 83

7.1. Performance Requirements..........................................................................83

www.zfort.com
contact@zfort.net
7.2. Design and browser compatibility................................................................83

7.3. Devices and OS version compatibility..........................................................83
7.4. Operating Environment................................................................................83
7.5. Security........................................................................................................ 83
7.6. Backup......................................................................................................... 84
8.
Development Approaches.................................................................................. 85
8.1. Methodology................................................................................................. 85
8.2. Risk Management......................................................................................... 85
8.3. Change Management................................................................................... 85

www.zfort.com
contact@zfort.net
1. Purpose
The present document purports to describe the details level sufficient for the
Contractor to create project plan and work assessment in the scope of the
SPKDRM project. The target audience of the document consists of
representatives of the Customer, the Contractor team of Zfort Group: Design,
Development and QA teams.
1.1.
Intended Audience and Reading Suggestions
This section contains the brief information about all chapters in the
document. Please note that all that is not covered by this document and not
shown on the wireframes will be construe as a change request and will be
assessed separately and may amend and increase the plan
Part 1 Introduction. This part provides general information about the
document its purpose, audience, references, accepted abbreviations, etc.
Part 2 Overall Description. This chapter describes the project and other
important aspects to take care of while working on the project requirements.
Part 3 A description of the functional requirements to the native mobile
application is provided.
Part 4 A description of the functional requirements to serverside
application is provided.
Part 5 - A description of the Entities and their interactions is provided.
Part 6 - Non-functional requirements. A description of the systems nonfunctional requirements is provided. It contains an overview of the design
requirements, scalability, safety etc.
Part 7 Development Approaches. General info about the work flow of the
project development.

www.zfort.com
contact@zfort.net
1.2.
#
References
Description
Link
1 Prototype
http://lkgv1m.axshare.com/
2 Yii php framework
http://www.yiiframework.com/
3 iOS design concepts
https://developer.apple.com/library/ios/do
cumentation/UserExperience/Conceptual/
MobileHIG/
4 Android design concepts
http://developer.android.com/design/
1.3.
Definitions of main entities
#
1 Fingerprint
Term
Definition
Fingerprint is a unique data object
encapsulating the security identity of a
user.
Fingerprint has the following features:
The fingerprint consists of each

saved data point of (a user's)
answered questions combined their
completed
registration
profile
targeting information (age,
sex,
etc.)
Number of available
questions is not limited.
Fingerprint is a parent entity and

answered question is a child entity.
Fingerprint is a unique for each

user.
Fingerprint should be stored with

highest level of security we can
provide
(and
anonymously
associated with one registered
account and pay choice like PayPal,
ApplePay etc)
answered

www.zfort.com
contact@zfort.net
Fingerprint
can
be
provided
(anonymously) to third-party person
as a separate file and on saas
basis.
Fingerprint
can
be
used
(anonymously) by User as unique
access token to connect to thirdparty services.
2 App
Native mobile application developed for

Android and iOS. Will have the same
functionality.
3 API
Custom API to connect server and App.

Will be developed on RESTful basis.
4 Admin Panel
Client side for 3 types of users:

SuperAdmin, Editor, Client. Will have only
desktop view.
1.4.
Executive Summary
Main project idea is to create a new technology of data gathering and

authorization. The service duality presumes a huge set of different features
divided for each user group. By data gathering we assume process of
creating survey type questions and providing them to our Users via native
mobile applications (iOS/Android). User answers questions and create a
database. The DB can be used by marketing companies to mine Data. Work
with data will be available via desktop website (admin panel).
Authorization features is more complex. We assume that after User
completes to answer questions, the answers will be combined with User
specific parameters in a specific data object. This data object can be used as
unique authorization token to access third-party services.
The high-level values are described on the chart below:

www.zfort.com
contact@zfort.net
Beneficiary
1 SPKDRM Owner
2 Marketing companies
3 Users
Values
-
Selling Premium Account for Users;
Selling Access to DB of answered

questions on different basis;
Selling fingerprint
service providers;
Ability to work with fresh and live

data;
Ability to
surveys;
User fingerprint technology as

unique access token to get access
to service providers;
create
technology
questions
to
and

www.zfort.com
contact@zfort.net
2. Overall Description
In this section short overall description about all main project parts is
provided.
2.1.
System Architecture
SPKDRM is a website which consists of 4 main parts: Client, Web server and
files storage, Database. We will use classic scheme of client side APIs
server side application. As a client side we will have mobile application. Our
APIs will work on RESTful basis. The system will be managed via des
The simple chart with description is provided below:
Element
Description
Users
All people who are interested in access and

usage of our service.
Client
Mobile application Android/iOS
Web server and

file storage
Apache or Nginx as s web server and usual

server for file storage provided by hoster.
Database
MySQL or MariaDB for data storage.
Each type of user has its own website structure in accordance with the
important features. E.g. Super Admin has all features to work with website
functionality, Editor to manage questions. Client to work with BigData. User
will work with mobile application..

www.zfort.com
contact@zfort.net
2.2.
General User Characteristics
We will have 4 main user types in our system:
User user of the app;
Super Admin;
Editor;
Client.
Each user type has its own peculiarities. The short description you can find
on chart below:
User Type
Description
User
User will use the mobile app only and can use all
mobile app features (login, blog, history etc.):
-
SignUp;
Login (authentication);
Answer questions;
Change previously answered questions;
Read blog section;

www.zfort.com
contact@zfort.net
Premium User
Super Admin
Editor
Client
2.3.
Update to Premium;
In advance to default User options, Premium user

has the following options:
-
Create new questions;
View answered questions by other Users;
Admin will manage system settings, create new

admins if needed. Can create other users. Can
view statistics.
Editor will work with questions.
Marketing and Brand companies. Client will be
able to create new questions and to view
statistics.
General Flow
The General Workflow will be the following:

#
Section
Description
SPKDRM owner
We have our, who creates first set of questions

and promotes the application.
User
Our User submits answers creating his unique

fingerprint (which is stored in the SPKDRM DB).
For premium features Users pays to SPKDRM
owner. Marketing companies
Client
Creates new questions and works with answers in

the Admin panel. Clients may be 3rd party
analytics providers OR analytics software
providers with spkdrm providing the analytics
using their software
Service provider
Use fingerprints as Authorization server.

www.zfort.com
contact@zfort.net
2.4.
Screen flow
In the chart below you can check the screenflow between all main screens in
the app:

www.zfort.com
contact@zfort.net
Screen
Description
Splash
This screen we need to upload all new data to

app before user start use the app. Here will be a
small animation.
Login /
Authentication
On this screen we will ask our user

authentication/login questions. Also here we will
ask the targeting questions.
About/Tutorial
Using simple animation we will have a set of

couple screens to describe all main user actions
in the app. Also here the main information about
app description will be provided.
Spectrum
User Account
Here all user information will be stored. User can

change personal data here.
History
The list of answered questions. User will be able

to change them later.
TOS
Side menu
The main CTA screen. User will spend here the

majority of time. Here all questions will be
displayed.
Webview with Terms of Use.

Control element. By tap on it we will have a
drawer and can navigate through the app.

www.zfort.com
contact@zfort.net
The detailed descriptions of the each screen will be provided in the section
#3.
2.5.
Admin Panel Sitemap
Admin panel will be a classic website based on yii 2.0 php framework or
same. It will have a range of pages/sections with separate features. In this
section the full description of all sections will be provided. For each user
sitemap will be different. Admin Panel will be use by Admin, Editor, Client.
Please check the chart below:
Page
Dashboard
Account
Description
Main page. Different for each user. Will contain
widgets with all main indicators of work for fast
access.
Section where personal data will be stored. Users
can change here login/password.
Topic management Section in which we can manage questions.

CRUD new items.
User management
Blog
Settings
Available for Admin. RU of system parameters.
Statistics
Available for Admin and Client. In this section we

can work with BigData.
Section in which we can CRUDS user.

CRUD blog items.

www.zfort.com
contact@zfort.net

www.zfort.com
contact@zfort.net
3. Functional Requirements
All the features are divided by the different Users. Please find below the list
of features in accordance with the User type. Functional requirements will be
divided in 6 main parts:
Application (interface part);
Admin Panel (interface part);
Entities (description and requirements)
API;
BigData (work with fingerprints);
Business goals (monetization tools);
3.1.
Application General Layout
We will utilize 2 native applications as a client side for the SPKDRM platform:
based on iOS and Android. App layouts will use best practices of each
platforms design guidelines to provide best user experience. More
information regarding peculiar OS versions could be founded in section #4.
Particular UI decisions will be described on design stage. In the SRS only
functional sections will be provided and requirements to general layout will
be laid out.
#
Page
Description
Menu
UI element (e.g. hamburger button) by clicking

on which the sidebar opens.
Sidebar
List of screens by clicking on which we can

navigate within the app.

www.zfort.com
contact@zfort.net
3.2.
Splash
We will have animated screen an app preloader, which needs to download

and run the app without delays. Splash screen will be simple and easy to
use. The guideline is provided below:
-
White screen;
Spkdrm logo appears for min 3 seconds;
Logo appears with transparency 50% and then changes to

transparency 100%.

www.zfort.com
contact@zfort.net
3.3.
Application Authentication Flow Sign Up
Our Authentication flow has 2 related sides: Sign Up and Sign In processes.
User is able to create new account on the app beginning. The Sign Up flow is
described on chart below:
#
Step
User fills the Step

1
Description
On this step we need our User to fill the Email
field and Password field.
-
Email has validation to email (@ sign,

minimum 1 sign after @, after @ should be
a . And characters.
Password will be hided with stars.
User fills the Step

2
On this step we need our User to fill the targeting

questions: Sex, Age, Zip, Income.
User fills the Step
User needs to choose billing option: PayPal or

www.zfort.com
contact@zfort.net
Visa. Different users can have the same accounts

(families).
CheckPoint
If internet connection was established, app will

send a request to server with filled data. User
status will be changed to Draft, as we have his
email and can communicate with him later
(abandoned registration flow).
Confirmation email Server sends the email with confirmation link to

the filled email.
User confirmed
invitation
If user clicks on the link, he will be redirected to

the app again, but the user profile will be
approved.
-
User Status changed to Pending (as we

assume, that user can confirm the email
later);
User Status to
Active
If user confirmed the link, his status changed to

Active
Access to App
User opens the app with the full rights.
Deleted from
Pending
If User didnt confirm the email within 30 days,

his record will be deleted from Pending table.
Lets describe the flow with help of screens:

www.zfort.com
contact@zfort.net
Element
Description
Step 1
The SignUp process is a multistep process

divided in 3 steps. This is dynamic indicator
determines the precise step and can be used as a
breadcrumbs within SignUp process.
Create Account /
Sign In
We assume that new User doesnt have the

account, so the main goal action is to create a
new account. However, we can have an old user
that wants to use his own account on different
device. By click on Sign In, the Sign In section
opens.
Email/Password


www.zfort.com
contact@zfort.net
a . And characters.
4
Next button
If the fields are filled and validated, the Step 2

screen will be opened.
Step 2
Element
Description
Disclaimer
To provide user with hints we will have a

disclaimer which will describe what for we ask
these questions. Disclaimers will be hardcoded.
Sex
Radio button with ability to choose sex.
Age
Input field only for numeric digits.

www.zfort.com
contact@zfort.net
ZIP
Income
Validation for ZIP (USA)

Validation only for numeric digits.
Step 3
Element
Description
Payment Option
Dropdown with ability to select a payment option.

We need Payment Option to provide our user with
higher level of anonymity and security of the
account. Also, this will help us to avoid fake
users.
Billing details
Default billing details fields: Card Number, CVV,

Month and year.

www.zfort.com
contact@zfort.net
Step 4
Element
Success
3.4.
Description
Message if the server request was successful.
Application Authentication Flow Sign In
If User clicks on Sign In, he gets the following screen:

#
Element
Email/Password
Remember me
Login
Description
-

a . And characters.
By clicking on this checkbox, the data will be

stored in cache.
Submit button.

www.zfort.com
contact@zfort.net
3.5.
About / Tutorial
In this section we need to give our Users a short description of how the app
works. This will be slider with 3 screens. Each screen contains short Text
message and Image. Navigation will be made with swipes. The examples of
the
UI
of
this
section
you
can
check
below
(http://lkgv1m.axshare.com/start.html#p=about_tutorial):

www.zfort.com
contact@zfort.net
The goal of this section to provide our User with exact descriptions of Typical
user cases (main user activities). We will have the following list of activities:
-
Answering Topics;
Changing history (previously answered Topics);
Accessing third-party service;
3.6.
Spectrum
The main screen, where our User will spend the biggest part of his time. In
this screen new Topics appears and User answers on them.
#
Element
Description
Topic
The section for question (text). Requirements to

question is the following:
-
Not longer than 25 characters (example:

Hillary as President in 2016. or
Designated Hitter Rule);
Doesnt contain url;

www.zfort.com
contact@zfort.net
Spectrum
The special, custom UI element described on

chart below. Divided into small rectangles by X
and Y axis.
By Answer we mean click on a specific point within Spectrum section, e.g.

check the chart below:

www.zfort.com
contact@zfort.net
After we click on the Spectrum, the answer will be send to the DB and User
will have next question. Screen changes will be made with default screen
animation.
User will have 30 seconds to answer question. After 30 seconds we will
highlight the question section with red color to attract him once again.
3.7.
DASM
Create the technical feature with help of which we can select the possible
smallest area on the smartphone screen.
Client request: We definitely want as many distinguishable touchable points
(colors) on the DASM as we possibly can. We want many more points
available than a finger, thumb or even a stylus can choose. The finger,
thumb or stylus will be too big to cover just one "pixel", BUT I am sure one
point will be identified within the space being touched on the screen.
3.7.1. Problem
The main problem of DASM realization is the limits of the current touch
interaction paradigm. It means that when we are unable to choose with a
finger/thumb can choose. Stylus can choose smaller piece of screen,
however, not all devices support the stylus. Please check the screen below:

www.zfort.com
contact@zfort.net
Finger/thumb can get the rectangle with 10*10 pixels. We want to get the
smallest available piece.
3.7.2. Solution Concept
Our idea is to create a special scaling feature with ability to place special
pointer on the exact pixel place. For simplicity, lets name it Lens. To
implement this feature we need the following.
-
Divide the clickable are to the rectangles 1*1px. It will be totally

useless for default touch event. However, it will suit the best for touch
effect with Lens interaction.
Implement the snap to grid ability.
After that, the clickable area will be ready to work with Lens.

www.zfort.com
contact@zfort.net
3.7.3. Lens
By Lens we understand scaling of the clickable area and ability to provide
manipulation within selected area. You can check the short preview below:
Lens consists of 2 main parts:

-
Scaling feature (described as circle on chart above);
Interactive Pointer (described as black square on chart above);
Lens scales the selected area to the state, when Pointer (which is 1*1px) can
be placed to exact place on the grid. In the MVP version of SPKDRM we
assume to have Lens static it will show only selected piece of DASM and it
will not allow moving scale to another place. This is a scope of extended
version.
3.7.4. Flow
Basically, to make an answer we need to tap on the DASM and then Lens
appears. Then we need to place pointer and submit the choice. The detailed
explanations are provided below:
1. Initial click on the preferred color area

www.zfort.com
contact@zfort.net
We have our DASM UI element. We want to answer topic by choosing the

exact color. We click on preferred color area. Then Lens appears.
3.7.5. Lens
Lens appears with scaled color area and pointer. We need to place the
pointer on the exact place as the pointer will move within a grid with cells of
1*1 px.

www.zfort.com
contact@zfort.net
3.7.6. Confirm
To submit the choice we need click on submit button (the wireframe provided
below, on design stage in can be changed). After that, the next Topic will be
showed.

www.zfort.com
contact@zfort.net
3.8.
Topic Interaction
We will have 2 types of topic interaction: when the Topic was answered and
when not.
When the Topic was answered, the Topic UI element will take the selected
color:

www.zfort.com
contact@zfort.net
When it was not answered in 30 second we will highlight the topic UI element
with red color.

www.zfort.com
contact@zfort.net
3.9.
User Account
In this section we will operate with the User Account and abilities to change
data entered on Sign Up stage. Also, in this section we will have an ability to
upgrade Account to premium.
#
Element
Description
Change button
By clicking on this UI element we will have a

screen with ability to view the filled data and to
change it.
Upgrade
Opens new screen

account to premium.
with
ability
to
upgrade

www.zfort.com
contact@zfort.net
3.9.1. Upgrade to premium

In this section we can upgrade our account to premium.
#
Element
Description text
Submit
3.10.
Description
TBD with Client
Button sends the request to server and after
approving it, the Premium features will be
available for User.
Blog
In this section our user can read Blog items. We have 2 screen states here:
List of Blog items, Blog Item. We can get Blog item by clicking on image or
Heading of the Blog Item. Each Blog Item has the following items:

www.zfort.com
contact@zfort.net
Title,
Image,
Short description;
Full description;
Date;
Author;
Element
Description
Blog Item Short
Blog item Full
We have full heading, Image, Full description,

Date and Author. Also we have sharing options
for this particular Blog Item.
Sharing
We have an ability to share our blog item via

Twitter and Facebook native SDK.
We have full
description.
heading,
Image
and
Short

www.zfort.com
contact@zfort.net
3.11.
History
In this section our User will be able to change the previously made answers.
We will have a list of all our answered questions. By click on item we will be
able to change it.
#
Element
Answer
Spectrum
Description
The UI element with an Answer (text). Clickable.
We will have a spectrum with marked ID. We
need to the dot on other place and click save.

www.zfort.com
contact@zfort.net

www.zfort.com
contact@zfort.net
4. Serverside application
In this section the requirements to the serverside application are provided.
The serverside application will be developed on the Yii 2 php framework or
similar. This framework allows a huge extendibility which is important for
further modifications.
By Serverside application we mean a website which will be available via
browsers on desktops, tablets and mobiles. This application will be build
using best practices of web development and will use default web
development scheme of server architecture: Linux (Centos or Ubuntu) as
server OS, Webserver (Nginx or Apache), DB (MariaDB or MySQL), PHP 5.4.
4.1.
Role-based access control
We have 3 main user types: Admin, Editor, Client. Depend on the user type
we will have different sitemap and available features. More detailed
explanation of user goals you can find in section #2.
Admin can proceed with the following operations:
-
CRUD Editors;
CRUD Clients;
Read System Statistics;
Change own Account;
Editor can proceed with the following operations:

-
Read Users;
CRUD Topics;
CRUD Blog items;
Change own Account;
Client can proceed with the following operations:

-
CRUD Topics;
CRUD DataMining operations;
Change own Account;
Based on these main operations, the sitemap for each user type was made.

www.zfort.com
contact@zfort.net
4.2.
Entities
The main Entities we work with on SPKDRM project are: User, Topic. Around
these entities all product life is concentrated.
4.2.1. User Entity
User is our mobile app user. This is a core object of our work very important
for Authorization service section. User has the following options:
-
ID (count);
Name is equal to email (string);
Password (string);
Age (count);
Sex (string);
Income (count);
ZIP (count);
Payment (array);
Creation Date (count);
Status (string);
These options will be used by our API. To the User entity the Topic will be
connected. Connection of User and Topic generate the unique fingerprint of
User individuality, which can be used by Authorization service.
4.2.2. Topic Entity

Topic is a question created by Editor, Client or Premium User. It has the
following options:
-
ID (count);
Body (string, not more than 25 characters);
Category (ID of category);
Status (string);
Author (string);

www.zfort.com
contact@zfort.net
After Topic was answered by User, we need to add the Answer to question, so
it will transform to Answered Topic. Answer has the following question:
-
ID;
Coordinate (count);
Date;
4.2.3. Fingerprint
The unique connection of the User and Answered topic is a Fingerprint. It
inherited all the features of 2 entities, where User is a parent array and
Answered questions are child arrays.
4.2.4. Client
Client is a marketing/brand company that have access to DB with answered
topics and can work with them. Client has the following options:
-
ID;
Name;
Password;
Status (Active, Inactive);
PricingPlan (PlanA, PlanB);

www.zfort.com
contact@zfort.net
Billing Details;
Details;
Restrictions (full, minor);

4.2.5. Blog/FAQ
We have almost the same entities Blog and FAQ. They have the following
options:
-
ID
Full Title;
Short Title;
Full Description;
Short Description;
Image;
Author;
CreationDate;
Category;
Status;
4.2.6. Admin/Editor
Has the following options:

-
ID;
Name;
Password;
Phone;
Status;

www.zfort.com
contact@zfort.net
5. API
-
We will use RESTful approach to create request connection between

mobile application and silverside.
The data will be returned/stored with JSON.
The list of API is based on current mobile app features and can be changed
during development process.
5.1.
-
User
To send request with registered user data we need the following API
item:
POST Registered User {User ID, Email string, Password string, Age string, ZIP count,
Income count, Payment details }.
By sending this API request we will trigger SignUp flow described in

section #3.
If User changed profile data, we need to use the following API item:
PUT Updated Use {User ID, Email string, Password string, Age string, ZIP count,
Income count, Payment details array}.
Important, the Payment option is our anti-bot check. If user doesnt

have Payment option, we assume that he is a fake user.
5.2.
Topics
To work with questions we need the following API items:

-
This API item is responsible for getting the scheduled pack of Topics:
GET NEW Topics {Topic ID, Topic body, Topic category}
Important, User always should have topics to answer on. If User

doesnt have topics, the notification should be prompt: Youve answered on
all our Topics
This API item is responsible for sending answered Topics to server:
POST Answered Topics {Topic ID, Topic body, Topic category, Answer(coordinate) count,
User ID}
Important, to connect User with answered topic for further DataMining.

www.zfort.com
contact@zfort.net
This API item is responsible for sending updated answered Topics to

server (History):
POST Answered Topics {Topic ID, Topic body, Topic category, Answer(coordinate) count,
User ID}.
This API item is responsible for sending new create Topic by Premium
User to server:
POST Created Topics {Topic ID, Topic body, Topic category, Answer(coordinate) count, User
ID}.
5.3.
Blog
To work with the News/Blog section.

-
This API item is responsible for getting list of Blog Items (short
description):
GET ListBlogItems {BlogItemID, ShortDescription,Image, Author, Date, Category}.
This API item is responsible for getting full version of Blog Item:
GET ListBlogItems {BlogItemID, FullDescription,Image, Author, Date, Category}.

www.zfort.com
contact@zfort.net
6. Serverside application
In this section the requirements to the serverside application are provided.
The serverside application will be developed on the Yii 2 php framework or
similar. This framework allows a huge extendibility which is important for
further modifications.
By Serverside application we mean a website which will be available via
browsers on desktops, tablets and mobiles. This application will be build
using best practices of web development and will use default web
development scheme of server architecture: Linux (Centos or Ubuntu) as
server OS, Webserver (Nginx or Apache), DB (MariaDB or MySQL), PHP 5.4.
6.1.
Role-based access control
We have 3 main user types: Admin, Editor, Client. Depend on the user type
we will have different sitemap and available features. More detailed
explanation of user goals you can find in section #2.
Admin can proceed with the following operations:
-
CRUD Editors;
CRUD Clients;
Read System Statistics;
Change own Account;
Editor can proceed with the following operations:

-
Read Users;
CRUD Topics;
CRUD Blog items;
Change own Account;
Client can proceed with the following operations:

-
CRUD Topics;
CRUD DataMining operations;
Change own Account;
Based on these main operations, the sitemap for each user type was made.

www.zfort.com
contact@zfort.net
6.2.
Responsive views
We plan create a responsive markup for each Admin, Editor, Client website
section therefore it will be available on desktops, tablets and smartphones.
Element positioning will be determined on markup stage. Preliminary look of
each state you can find below:
Desktop
Tablets

www.zfort.com
contact@zfort.net

www.zfort.com
contact@zfort.net
Smartphone
6.3.
Admins Dashboard
We will use Admins dashboard to explain the main serverside elements

purpose. Basically, each user will have the Dashboard as a main, start screen
with widgets that contains main information, and couple of sections to work
with aimed sectors.
#
Element
Description
Navigation
Dynamic navbar with links to the other website

sections.
Statistics widget
A small widget with couple of main statistics

indicators.
Functional widget
Basically, action logs. With help of these widgets

Admin can get a short report of the current
status: activities of all main Actors on the

www.zfort.com
contact@zfort.net
website.
4
Footer
Footer
contains
2
dynamic
elements:
Breadcrumbs and Search. We will use default
frameworks
options
to implement these
features.
The Navigation on the website is build with help of 2 main tools: Menus and
Search. By Menus we understand link placed in Sidebar, footer and Navbar.
By Search we mean search field in navbar. It searches among page titles.
6.4.
Functional widgets
We have the following widgets:

#
Element
Description
Statistics
We have 2 types of statistical widgets: dynamic

charts and number widgets. For Admin we will
have the following charts: Users growth, Topics
Growth, Payments Growth.

www.zfort.com
contact@zfort.net
Last Clients
List of all last Clients we had. By click on the

heading we will be redirected to the Client
section.
Payment
By clicking on the title of this widget we will be

redirected to Billing section.
List of payments.
6.5.
Activity Stream
This is a sort of widget. This is a list of all activities we have recently in the
system related to the User. Admin is able to see all actions made by ALL
users (editors and client). Editor is able to see actions of other Editors. Client
is able to see actions of the members of Company.
#
Element
Activity Stream
Item
Description
Has the following options:

www.zfort.com
contact@zfort.net
{userName} name of the user;
Action name;
We have the date filter. In the upper part we have

new items. In the above part low items.
1.6.
Statistics widget
We will have specially created statistics widget which will give brief current
status to Admin. It will have an indicator and its value. Widget contains the
following indicators:
Created Topics;
Answered Topics;

www.zfort.com
contact@zfort.net
Users;
Premium;
Clients;
In Trial (need discuss);
The values are always numeric;
6.6.
User Management
In this section Admin is able to manage all type of users. Admin is able to
CRUD Editors, Read Users and work with Client (TBD by Joel). The page have
a statistics widget and 3 tabs with links to separate section for managing
Users, Editors and Clients.
The Users page has the following functionality: view the list of Users and
ability to delete them. It will be shown in a grid, which will have the following
options:

www.zfort.com
contact@zfort.net
User details: Email, Age, Zip, Income, Billing type;
System details: Registration date, Status (Active, Drafted, Expired), ID;
Basically, the main idea of this section is to view the list of Users and delete
those Users the term of what was expired.
6.7.
Editor
In this section we are able to work with Editors.
Element
Grid
Actions
Description
ID, Name, Email, Phone. Multyselect checkbox.
Create new Editor (in a pop-up) and Delete Editor.
Create new Editor:

#
Element
Popup
Description
Default system popup with form.

www.zfort.com
contact@zfort.net
Form
Invitation
Name, Email, Phone Number.

The invitation will be send to Editors email with
pre-generated password.
Editors Profile:
The fields filled in previous step will be visible in the Editors profile page

www.zfort.com
contact@zfort.net
6.8.
Statistics
In this section we have the ability to view statistics based on main indicators.
We will view statistics based on 4 main entities: User Growth, Topic/Answers
Growth, Revenues, Client growth.

www.zfort.com
contact@zfort.net
Element
Description
Tabs
We have 4 tabs by click on which we can

navigate through 4 main Charts.
Chart
We will use one of js libraries on front-end to

visualize the chart.
Datepicker
We have the ability to set a desirable period for

showing data via simple datepicker.
6.9.
Billing
In this section our Admin is able to work with the integrated Billing system
(PayPal) to control incomes and costs. Basically, we will work with Payment
entities here. So, if I want to provide some client with service I need to create
a Payment with amount of money for this work. This payment will be
assigned to a Client. There can be more than 1 payment. Payment can be of
2 types agreement payment and upsell. When payment was created our
spkdrm system will generate an invoice that will go the Client. After Client
paid the invoice I need to edit a payment and change it with the paid amount
of money. This value will be taken by our Statistics system, so in the
Revenues section I will have an analytics of incomes.

www.zfort.com
contact@zfort.net
List of Client. Our hierarchy starts from the Client. Client is on top of
our pyramid.
The Client item is expandable;
In the Client item we have assigned payments;
Payment Item has the following options:

-
Payment name;
Payment type;
Amount due;
Due date;
Actions: Edit, Paid; Delete;

www.zfort.com
contact@zfort.net
6.10.
Account
By clicking on the user icon in the upper left corner of the website we can
open the Account section with short details about Admin.
#
Element
Description
Image
Ability to upload new image. Will be shown in

messages and on navbar.
Details
We have the following fields:
Actions
Name
Email
Phone
Notes
Update button will submit changes. Delete will

purge all changes.

www.zfort.com
contact@zfort.net
6.11.
Editor
Editor starts the work from a Dashboard. It has the same structure as
Admins Dashboard.
Element
Navbar
Sidebar
Activity stream
Description
We have here the following elements:
-
Breadcrumbs;
Search;
Avatar link to profile;
We have the following menu links:

-
Dashboard;
Topic editor/scheduler;
Manage FAQ;
Manage notifications;
Blog.
The same Activity stream as for the Admin,

www.zfort.com
contact@zfort.net
however only with actions of other editor.

4
6.12.
Widgets
We have the following widgets:

-
Scheduled Topics with ability to go directly

to scheduler;
Clients to work with clients;
Statistics;
Editor Topic Editor and Topic Scheduler
In this section Editor is able to work with the Topics and Schedule Topics in
packs. The initial screen is the following:
Element
Description
Tabs
We have 2 tabs that lead to 2 pages with Editor

and with Scheduler.
Categories
In category section we are able to create new

Topic categories. We assume that we will use 1-1
dependency.

www.zfort.com
contact@zfort.net
Topic
Here we can manage with Topics itself.
The Categories editor has the following functionality:
Element
Description
Search
Autocomplete search with A-Z sorting. This

element we need to navigate through the
Categories.
Actions
Select All by click on this checkbox we

can select all our questions;
Create we can create new Category;
Delete selected Category;
List
Simple list of all created categories with ability to

select more than one.
Category
Has the name and edit icon by click on which we

will be able to change name and related Topics.

www.zfort.com
contact@zfort.net
In the topic creation section we have the following features:
Element
Description
Control toolbar
The same toolbar for working with items: Select

All, Create, Delete, Search, A-Z sorting.
List of items
Topic
All related to category Topics.

Just a text item with restriction in 25 character.
In Topics scheduler we can work with the grouping Topics to pack and
scheduling them for showing on mobile devices:

www.zfort.com
contact@zfort.net
Element
Description
Control toolbar

All, Create, Delete.
List of pack
We have a list of all packs with related to them

Topics.
Settings
Here we can tune the pack.
To create a pack we need to do the following:

#
Element
Description
Create/Edit pack
We can create a Pack from scratch or we can edit

an existing pack.
Add Items
We can add items from a full category.

We can add items separately.
To find items we have a search.

www.zfort.com
contact@zfort.net
To tune the Pack we have a Settings block:
Element
Name
Random/In order
Description
Here we can setup a name if pack was created
from scratch. Or change it if we want to edit it.
Here we can setup the order of Topics rather it
will be random order or one-by one as they were

www.zfort.com
contact@zfort.net
created.
3
Times
We can setup a cycle order if we want to go

through the questions once again. Or we can
setup At once. Then we will have an ability to
setup a start date only.
Publish
After all steps were done we can publish the pack

and it will go live starting from the Start date.
6.13.
Manage FAQ section
In this section we can manage with FAQ websites section and help chat.
Element
Chat
FAQ items
Description
We have a help chat for clients to assist in
solving issues and consult them how to use
system.
We have a list of all FAQ items with ability to
create new, delete old, edit, filter by Categories,
Search and sort. Categories are preinstalled by

www.zfort.com
contact@zfort.net
Super Admin.
To Create a new FAQ item we need to do the following:
Element
Description
FAQ Content
We need to setup FAQ title, Short description and

Full description.
Details
Details about created FAQ item: Status (Draft,

Published), Published date, Author.
Media
We are able to add Media item image or video

using simple uploader.
Category
Action
We are able to select a category for the FAQ item.

Publish will publish the item;
Draft will save it as a draft without publishing;
Trash move item to trash;

www.zfort.com
contact@zfort.net
6.14.
Manage Notifications
In this section editor is able create new notifications and view the list of old
notifications.
Element
Toolbar
List
Description
We have the following options in the toolbar:
-
Select all items;
Sort A-Z and Date filter

(Ascending/Descending);
Create notification;
Delete notification;
We have a list of all our notifications. Each

notification has the Avatar of sender, Subject and
text.
To create a notification we need to click on Create:

www.zfort.com
contact@zfort.net
Element
Description
Content
We need to setup Subject and Message
Details
Details about created item: Status (Draft,

Category
Action
We are able to select a category for the item.

6.15.
Blog/Pulse
In this section Editor is able to create items for Blog (app users) and Pulse
(Clients) via the simple WYSIWYG editor and content form described for FAQ
and Notification.
#
Element
Description
Control toolbar

List
The list of items with ability to edit.

www.zfort.com
contact@zfort.net
To Create a new Blog/Pulse item we need to do the following:

www.zfort.com
contact@zfort.net
Element
Description
Content
We need to setup title, Short description and Full

description.
Details

Media
We are able to add Media item image or video

using simple uploader.
Category
Action

6.16.
Account
In this section Editor is able to change details of its profile.

www.zfort.com
contact@zfort.net
Element
Description
Image
Ability to upload new image. Will be shown in

messages and on navbar.
Details
We have the following fields:
Actions
Name
Email
Phone
Notes
Update button will submit changes. Delete will

purge all changes.

www.zfort.com
contact@zfort.net
6.17.
Dashboard Client
In this section Clients start the work.
Element
Widgets
Description
We have 3 widgets:
-
Statistics widget with dynamic chart;
Topics;
Notifications;
By clicking on the widget we will be redirected to

the appropriate section.
Also, we have the Activity stream widget.
2
Sidebar
We have the following menu items in the sidebar:

-
Dashboard;
Pulse;
DataMining;

www.zfort.com
contact@zfort.net
6.18.
Navbar
Footer
Topics;
We have the following elements in the navbar:

-
Breadcrumbs;
Search;
FAQ;
Notifications;
Account;
We have default footer with links to our main

website:
-
About Us;
Store;
Jobs;
Privacy;
Terms;
Support;
Pulse
This section is a special corporate Blog only for clients.

#
Element
Description
List of Items
We have a Pulse wall with the list of all Pulse

items.
Pulse Item
It has the following options:

-
Author (Editor Name and Avatar);
Published Date;
Title;
Image
Sharing options;

www.zfort.com
contact@zfort.net
6.19.
Topics
This section has the same functionality as Editor Topic Editor Section has.

www.zfort.com
contact@zfort.net
Element
Description
Tabs
We have 2 tabs that lead to 2 pages with Editor

and with Scheduler.
Categories
In category section we are able to create new

Topic categories. We assume that we will use 1-1
dependency.
Topic
Here we can manage with Topics itself.
The Categories editor has the following functionality:

www.zfort.com
contact@zfort.net
Element
Description
Search
Autocomplete search with A-Z sorting. This

element we need to navigate through the
Categories.
Actions
Select All by click on this checkbox we

can select all our questions;
Create we can create new Category;
Delete selected Category;
List
Simple list of all created categories with ability to

select more than one.
Category
Has the name and edit icon by click on which we

will be able to change name and related Topics.
In the topic creation section we have the following features:

www.zfort.com
contact@zfort.net
Element
Description
Control toolbar

List of items
Topic
All related to category Topics.

Just a text item with restriction in 25 character.
In Topics scheduler we can work with the grouping Topics to pack and
scheduling them for showing on mobile devices:

www.zfort.com
contact@zfort.net
Element
Description
Control toolbar

All, Create, Delete.
List of pack
We have a list of all packs with related to them

Topics.
Settings
Here we can tune the pack.
To create a pack we need to do the following:

#
Element
Description
Create/Edit pack
We can create a Pack from scratch or we can edit

an existing pack.
Add Items
We can add items from a full category.

We can add items separately.
To find items we have a search.

www.zfort.com
contact@zfort.net
To tune the Pack we have a Settings block:
Element
Name
Random/In order
Description
Here we can setup a name if pack was created
from scratch. Or change it if we want to edit it.
Here we can setup the order of Topics rather it
will be random order or one-by one as they were

www.zfort.com
contact@zfort.net
created.
3
Times
We can setup a cycle order if we want to go

through the questions once again. Or we can
setup At once. Then we will have an ability to
setup a start date only.
Publish
After all steps were done we can publish the pack

and it will go live starting from the Start date.
6.20.
FAQ
In this section Client is able to view FAQ questions and communicate with
Editor as a consultant.
Element
Chat
Description
We have a help chat for clients to assist in
solving issues and consult them how to use
system.

www.zfort.com
contact@zfort.net
6.21.
FAQ items
We have a list of all FAQ items with ability to

create new, delete old, edit, filter by Categories,
Search and sort. Categories are preinstalled by
Super Admin.
Client Notifications
In this section we can work with received notification. The icon on a navbar
will be highlited with if Client received new notification.
Element
Toolbar
List
Description
We have the following options in the toolbar:
-
Select all items;
Sort A-Z and Date filter

(Ascending/Descending);
We have a list of all our notifications. Each

notification has the Avatar of sender, Subject and
text.

www.zfort.com
contact@zfort.net
Content
We need to setup Subject and Message
Details

Category
6.22.
Client Account
In this section Client is able to change Account details and add new members
of Company.
Element
Client Details
Description
In this section we are able to change Account
details:
-
Name;
Email;

www.zfort.com
contact@zfort.net
6.23.
Company
Members
Actions
Phone;
In this section we are able to change Company

details:
-
Name;
Details;
In this section we have a list of all Active

users assigned to the Company.
We are able to add new user. The form will

have the following fields: Name, Email,
Phone.
We can Update profile;
We can purge all data;
Client Data Mining TBD

www.zfort.com
contact@zfort.net
7. Non Functional requirements

7.1.
Performance Requirements
Web-application speed will depend on two factors: server response speed

and a number of clients requests. The application will be designed in such
way as to achieve maximum server speed owing to optimal data caching,
and a minimal number of requests from each client owing to correct data
structuring and load for requests. The system must ensure the simultaneous
operation of at least 1000 connections in the version 1.0.
7.2.
Design and browser compatibility
User-friendly UI/UX with easy to read content, appropriate for users of any
age and all tech expertise level will be provided. Flat, clean, minimalist
aesthetics with focus on typography and content hierarchy is preferred for
the layout. By default all our websites are compatible with the following
browsers:
Internet Explorer 9 (Windows 7 OS)
Internet Explorer 10 (Windows 8 OS) Desktop & Metro
Internet Explorer 11 (Windows 8 OS) Desktop & Metro
Mozilla FireFox 35 (Windows OS)
Chrome 39 (Windows 7 OS)
Safari 7.1 (Mac OS X Lion)
7.3.
Devices and OS version compatibility
Apple iPhone: 5/5s/5c/6/6+. For iPhones 6+ we will need additional

designs.
iOS version starting from v8.
Android: compatibility with devices starting from Android 4.2.
Landscape and portrait orientation;
Tablet Support TBD;
7.4.
Operating Environment
Admin panel website will be based on the following environment: Linux,

Ngingx, MySQL/MariaDB, and PHP.
Hosting question TBD.

www.zfort.com
contact@zfort.net
7.5.
Security
The access permissions for system data may only be changed by the
systems data administrator. All system data must be backed up every 24
hours and the backup copies stored in a secure location which is not in the
same building as the system. All external communications between the
systems data server and clients must be encrypted.
SSL-protected environment is required to secure the business data. The SQL
database is protected against SQL injection vulnerabilities, and will use
access restriction for updating sensitive information.
7.6.
Backup
For the complete system automated backup is done by cron script once a
given period of time (set up by Super Admin). We can manage and schedule
a variety of backup operations with the option to rollback the changes to
reverse any modifications. This feature is particularly useful when testing
new modules or customizations, or when upgrading to a new version of
Magento. Three types of backup are supported:
System Backup
Database Backup
Database and Media Backup

www.zfort.com
contact@zfort.net
8. Development Approaches
This section contains brief descriptions of the approaches, methodologies
and procedures which will be used in project development to achieve high
level of product quality and communication.
8.1.
Methodology
The methodology includes a set of project artifacts, formal management

procedures and the organizational structure of the team. We use a structured
but agile process involving close collaboration between Zfort Group and
Customers. Development process will consist of Iterations & Versioning. Each
version will have the approved scope and SRS.
8.2.
Risk Management
A formalized risk management procedure will be followed for the purpose of

minimizing the possibility of problems and for efficiently managing financial,
duration and staff resources within the scope of project management.
The main purpose of this procedure is to detect project risks as soon as
possible and efficiently minimize them.
8.3.
Change Management
In the course of software projects implementation there is almost always an

inescapable need to introduce changes into various product requirements.
Please note that changes may occur at any phase of project implementation.
Successful project completion requires a state-of-the-art changes
management mechanism approved between Customer and Contractor. The
methodology we suggest has been repeatedly tested and, according to some
of our customers, is more efficient than prevalent non-formal methods used
in on-site development.
Change requests can be originated both by
Customer and Contractor, but the final change implementation decision rests
with Customer.
Hereunder is a general change management scenario:
The party which initiates a change (initiating party) submits a change

request(s) to the Contractor.
If necessary, Contractor will discuss and clarify the request with

Customer;
Contractor will appoint Change Control Board (CCB) from the pool of its
employees. Its duties will include:

www.zfort.com
contact@zfort.net
assigning ID to each change request;
assessing the effect a change will have on the components and

artifacts which have been already implemented (if necessary, the other
requirements will be approved by Customer);
assessing the effort, duration (and perhaps the cost) of implementing a
change in the product and the artifacts related to the above (Object Model,
DB schema, Test Cases, Help, User Guide, Installation Instruction, etc).
assigning a specific priority and a particular phase of delivery at which
the change will be implemented.
Following the assessment, Contractor will provide Customer with a

proposal for priority, duration and cost of implementing each change
request;
Customer approves priority, implementation time and cost for each

change request;
After the approval a change request is processed by Contractor;
After change request implementation Contractor must perform QA, if

necessary;
Customer confirms request implementation.
All requests are put in the special repository that enables to store ID, status
and other request attributes, to generate various reports, and also
guarantees correct processing of all change requests. Customer can use any
form and method of connection to submit change requests, but it is
recommended that the general change management scheme should be used
to save time and maintain high quality of project implementation. As soon as
the project implementation contract is concluded, Contractor is ready to
provide the document that describes unified software/hardware environment
related to change management.

SPKRDRM Project - Srs - v5

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SPKRDRM Project - Srs - v5

Hochgeladen von

Copyright:

Verfügbare Formate

Zfort Group Friendly Web Technologies

Zfort Group Friendly Web Technologies

Zfort Group Friendly Web Technologies

3.8. Topic Interaction........................................................................................... 32

Zfort Group Friendly Web Technologies

Non Functional requirements............................................................................. 83

Zfort Group Friendly Web Technologies

7.2. Design and browser compatibility................................................................83

Zfort Group Friendly Web Technologies

Intended Audience and Reading Suggestions

Zfort Group Friendly Web Technologies

2 Yii php framework

3 iOS design concepts

4 Android design concepts

Definitions of main entities

The fingerprint consists of each

Fingerprint is a parent entity and

Fingerprint is a unique for each

Fingerprint should be stored with

Zfort Group Friendly Web Technologies

Native mobile application developed for

Custom API to connect server and App.

Client side for 3 types of users:

Main project idea is to create a new technology of data gathering and

Zfort Group Friendly Web Technologies

Selling Premium Account for Users;

Selling Access to DB of answered

Ability to work with fresh and live

User fingerprint technology as

Zfort Group Friendly Web Technologies

All people who are interested in access and

Mobile application Android/iOS

Web server and

Apache or Nginx as s web server and usual

MySQL or MariaDB for data storage.

Zfort Group Friendly Web Technologies

General User Characteristics

We will have 4 main user types in our system:

User user of the app;

Change previously answered questions;

Read blog section;

Zfort Group Friendly Web Technologies

In advance to default User options, Premium user

Create new questions;

View answered questions by other Users;

Admin will manage system settings, create new

The General Workflow will be the following:

We have our, who creates first set of questions

Our User submits answers creating his unique

Creates new questions and works with answers in

Use fingerprints as Authorization server.

Zfort Group Friendly Web Technologies

Zfort Group Friendly Web Technologies

This screen we need to upload all new data to

On this screen we will ask our user

Using simple animation we will have a set of

Here all user information will be stored. User can

The list of answered questions. User will be able

The main CTA screen. User will spend here the

Webview with Terms of Use.

Zfort Group Friendly Web Technologies

Admin Panel Sitemap