Professional Documents
Culture Documents
SPKRDRM Project - Srs - v5
SPKRDRM Project - Srs - v5
www.zfort.com
contact@zfort.net
Software Requirements
Specification
For
SPKDRM Project
Version 5 draft
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
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
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
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.
Development Approaches.................................................................................. 85
8.1. Methodology................................................................................................. 85
8.2. Risk Management......................................................................................... 85
8.3. Change Management................................................................................... 85
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.
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.
1.2.
#
References
Description
Link
1 Prototype
http://lkgv1m.axshare.com/
http://www.yiiframework.com/
https://developer.apple.com/library/ios/do
cumentation/UserExperience/Conceptual/
MobileHIG/
http://developer.android.com/design/
1.3.
#
1 Fingerprint
Term
Definition
Fingerprint is a unique data object
encapsulating the security identity of a
user.
Fingerprint has the following features:
Number of available
questions is not limited.
answered
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
3 API
4 Admin Panel
1.4.
Executive Summary
Beneficiary
1 SPKDRM Owner
2 Marketing companies
3 Users
Values
-
Selling fingerprint
service providers;
Ability to
surveys;
create
technology
questions
to
and
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
Client
Database
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..
2.2.
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;
Premium User
Super Admin
Editor
Client
2.3.
Update to Premium;
General Flow
Section
Description
SPKDRM owner
User
Client
Service provider
2.4.
Screen flow
In the chart below you can check the screenflow between all main screens in
the app:
Screen
Description
Splash
Login /
Authentication
About/Tutorial
Spectrum
User Account
History
TOS
Side menu
The detailed descriptions of the each screen will be provided in the section
#3.
2.5.
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.
User management
Blog
Settings
Statistics
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:
API;
3.1.
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
Sidebar
3.2.
Splash
White screen;
3.3.
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
Description
On this step we need our User to fill the Email
field and Password field.
-
CheckPoint
User confirmed
invitation
User Status to
Active
Access to App
Deleted from
Pending
Element
Description
Step 1
Create Account /
Sign In
Email/Password
a . And characters.
4
Next button
Step 2
Element
Description
Disclaimer
Sex
Age
ZIP
Income
Step 3
Element
Description
Payment Option
Billing details
Step 4
Element
Success
3.4.
Description
Message if the server request was successful.
Element
Email/Password
Remember me
Login
Description
-
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):
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;
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
Spectrum
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:
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.
-
After that, the clickable area will be ready to work with Lens.
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 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
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.
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.
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:
When it was not answered in 30 second we will highlight the topic UI element
with red color.
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
Upgrade
with
ability
to
upgrade
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:
Title,
Image,
Short description;
Full description;
Date;
Author;
Element
Description
Sharing
We have full
description.
heading,
Image
and
Short
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.
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.
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 Users;
CRUD Topics;
CRUD Topics;
Based on these main operations, the sitemap for each user type was made.
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);
Password (string);
Age (count);
Sex (string);
Income (count);
ZIP (count);
Payment (array);
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.
ID (count);
Status (string);
Author (string);
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;
Billing Details;
Details;
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
ID;
Name;
Password;
Phone;
Status;
5. API
-
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 }.
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}.
Topics
This API item is responsible for getting the scheduled pack of Topics:
POST Answered Topics {Topic ID, Topic body, Topic category, Answer(coordinate) count,
User ID}
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
This API item is responsible for getting list of Blog Items (short
description):
This API item is responsible for getting full version of Blog Item:
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.
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 Users;
CRUD Topics;
CRUD Topics;
Based on these main operations, the sitemap for each user type was made.
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
Smartphone
6.3.
Admins Dashboard
Element
Description
Navigation
Statistics widget
Functional widget
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
Element
Description
Statistics
Last Clients
Payment
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:
Action name;
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;
Users;
Premium;
Clients;
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:
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
Element
Grid
Actions
Description
ID, Name, Email, Phone. Multyselect checkbox.
Create new Editor (in a pop-up) and Delete Editor.
Element
Popup
Description
Default system popup with form.
Form
Invitation
Editors Profile:
The fields filled in previous step will be visible in the Editors profile page
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.
Element
Description
Tabs
Chart
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.
List of Client. Our hierarchy starts from the Client. Client is on top of
our pyramid.
Payment name;
Payment type;
Amount due;
Due date;
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
Details
Actions
Name
Phone
Notes
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;
Dashboard;
Topic editor/scheduler;
Manage FAQ;
Manage notifications;
Blog.
6.12.
Widgets
Statistics;
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
Categories
Topic
Element
Description
Search
Actions
List
Category
Element
Description
Control toolbar
List of items
Topic
In Topics scheduler we can work with the grouping Topics to pack and
scheduling them for showing on mobile devices:
Element
Description
Control toolbar
List of pack
Settings
Element
Description
Create/Edit pack
Add Items
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
created.
3
Times
Publish
6.13.
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
Super Admin.
Element
Description
FAQ Content
Details
Media
Category
Action
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:
-
Create notification;
Delete notification;
Element
Description
Content
Details
Category
Action
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
Element
Description
Content
Details
Media
Category
Action
6.16.
Account
Element
Description
Image
Details
Actions
Name
Phone
Notes
6.17.
Dashboard Client
Element
Widgets
Description
We have 3 widgets:
-
Topics;
Notifications;
Sidebar
Dashboard;
Pulse;
DataMining;
6.18.
Navbar
Footer
Topics;
Breadcrumbs;
Search;
FAQ;
Notifications;
Account;
About Us;
Store;
Jobs;
Privacy;
Terms;
Support;
Pulse
Element
Description
List of Items
Pulse Item
Published Date;
Title;
Image
Sharing options;
6.19.
Topics
This section has the same functionality as Editor Topic Editor Section has.
Element
Description
Tabs
Categories
Topic
Element
Description
Search
Actions
List
Category
Element
Description
Control toolbar
List of items
Topic
In Topics scheduler we can work with the grouping Topics to pack and
scheduling them for showing on mobile devices:
Element
Description
Control toolbar
List of pack
Settings
Element
Description
Create/Edit pack
Add Items
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
created.
3
Times
Publish
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.
6.21.
FAQ items
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:
-
Content
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;
6.23.
Company
Members
Actions
Phone;
Name;
Details;
Performance Requirements
7.4.
Operating Environment
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
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
Risk Management
Change Management
Contractor will appoint Change Control Board (CCB) from the pool of its
employees. Its duties will include:
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.