Cloud Nine Retail - Phase 1 Specification

Cloud Nine Retail | Phase 1
Cloud Nine Retail: Phase 1

Introduction to Cloud Nine Retail
Cloud Nine Retail is intended to be a cloud based retail management system. Retailers can sign up an
account and subscription. They use a website based BackOffice to manage their business, products
and run reports. They will use an iPad app as a Point of Sale with native receipt printing and cash
drawer functionality.
The system is platform-centric. We intend to develop the core functionality for the system, however
our API will be 95% publically exposed for third parties to develop “Add ons”, and we will be using
OAuth as an authentication method to develop our own App Store.
Cloud Nine Retail is hosted by Rackspace cloud hosting, a scalable solution running LAMP. The API is
written in Ruby on Rails.
The design and Layout of the site has already been completed and it will be required to be used as a
template.
Deliverables
As part of this project, you will be expected to achieve the following objectives.
1. Completion of a Marketing Website, the functionality of which is described in this document.

2. First stage of an Administration Portal, the functionality of which is described in this
document.
3. Second stage of the Administration Portal, started in deliverable 1.
The design and Layout of the sites have already been completed and should be used as the
templates for the functional code. All user interface elements should be taken from the template.
Deliverable Completion
The completion date quoted by the contractor will be deemed as the “Delivery Date” for each
deliverable. On this date you will be expected to hand over the code and deploy it to the RTL
Rackspace Server.
A deliverable will be defined as “Delivered” when the following conditions are met.
• The code is deployed to the RTL Rackspace environment

• Each function defined in this requirement for that deliverable operates as is designed
• Each function has been sufficiently tested, including negative testing, with appropriate error
handling
• Each function has been documented as to its designed usage
• The associated APIs have been developed and documented in line with RTL’s existing API
documentation.
Details on these requirements and the expectations of RTL’s quality control can be found in the
appendices.
Page 1 of 16 Confidential
Payment Structure
RTL will pay 25% of the overall project fee up front.
RTL will then pay 25% for each successfully completed deliverable.
• If a deliverable is completed on time, a 5% bonus (5% of the deliverable payment) will be

awarded.
• If the deliverable is completed within 5 working days of the delivery date, full payment for
the deliverable will be awarded.
• If the deliverable is more than 5 working days overdue, a 5% penalty (Of the deliverable
payment) will be deducted from the deliverable payment.
RTL will guarantee responses to email queries within 24 hours, Monday to Friday to help ensure the
delivery date is met.
API Development
As is defined in the opening page, all functions which the website performs, must be done through
the API. This project is designed in such a way that the marketing Website and Administration Portal
will both largely make use of the same APIs.
The API’s must be developed in JSON format using RESTful principles, as have already been defined
and documented so far from our feasibility projects.
If the API requires additional definition and modification, it must be discussed and approved by RTL
prior to its development. Typically, this will involve the contractor assessing the scope of the
requirement in the early days of the process in order to ensure the API will meet their development
requirement. This is then modified in the API documentation, and sent to matthew@rtl-mail.com
and can be discussed via skype.
All API calls need to be validated for authentication (OAuth) and also data integrity purposes, with
appropriate fail messages and error codes employed.
Documentation for the API must be maintained at all times. This must include documentation about
error codes, required data and practical usage examples. This documentation must fall in line with
the existing templates and formats established from the feasibility study.
The API will be tested according to the documentation by a third party developer to ensure it is of
sufficient standard and meets the requirement.
Contents
Deliverable 1: Marketing Website .......................................................................................................... 4
1.1. Overview ................................................................................................................................. 4
1.2. Multi Language ....................................................................................................................... 4
1.3. Customer Signup ..................................................................................................................... 4
1.4. Content Management ............................................................................................................. 6
Deliverable 2: Administration Portal (Part 1).......................................................................................... 7
2.1. Overview ................................................................................................................................. 7
2.2. Menu ....................................................................................................................................... 7
2.3. Users ....................................................................................................................................... 7
2.4. Retailer Accounts .................................................................................................................... 8
2.5. Suppliers.................................................................................................................................. 9
2.6. Customers ............................................................................................................................. 10
2.7. Partners ................................................................................................................................. 10
2.8. Apps ...................................................................................................................................... 10
Deliverable 3: Administration Portal (Part 2)........................................................................................ 11
3.1. Policies .................................................................................................................................. 11
3.2. Pages ..................................................................................................................................... 11
3.3. Support Tickets ..................................................................................................................... 11
Appendix A: Testing and Validation Expectations ................................................................................ 16
Appendix B: Documentation Expectations ........................................................................................... 16
Deliverable 1: Marketing Website

1.1. Overview
This document specifies the functions and features required for Cloud Nine Retail’s Marketing
Website.
The Marketing website is where visitors “Land” and can sign up for an account. It needs to be
visually appealing, conveying the fact that the site is a retail system.
The website layout and design is already completed and will be provided to you. This project is to
put the functionality required, behind the design.
All functionality must be performed through the API. If API methods do not currently exist, they
need to be discussed, defined and developed. There should be no direct database access.
1.2. Multi Language

The site must be designed with multi-language capability.
English is the primary language, and it should automatically detect the locale of the user and display
the relevant language.
If the language does not exist, it will use English.
RTL will provide 1 additional language (Dutch) in order to test the capabilities.
These language strings should be editable by RTL and easy to add additional languages. The
processes required to do this should be appropriately documented.
1.3. Customer Signup

The Customer Signup process will allow customers to sign up an account quickly and easily in order
to get started with the system.
1.3.1. Signup Form

The first step is a very simple form consisting of three fields, appearing in the “Main Content”
section of the landing page.
• Company Name
• Email Address
• Password
This is similar to how Shopify gets a quick signup. The form field “Labels” should also appear in the
form boxes, a bit like this example. The button should simply say “Signup”
This will create the retailer account in the system.
1.3.2. Account Creation

It will convert the Company Name field into the Subdomain. For example if a customer enters
“Grahams Shoes” as the company name, this will automatically become “grahams-shoes.c9r.co”.
If the subdomain is already taken it will add a number to the end of the subdomain until it creates a
valid one. “grahams-shoes-1.c9r.co”, “grahams-shoes-2.c9r.co”
While it is building the customer account it should show some sort of overlay saying “Your account is
being created, it’ll only take a moment or two”
When the account has been created it will automatically log them into their account, which is at
http://their-subdomain.c9r.co. The first screen they see will be the main backoffice dashboard
screen, with a lightbox style overlay showing their account details. This is not yet developed, so it
will need to be documented where this “Redirect” is configured. For the time being it can redirect to
a sample page.
Welcome to Cloud Nine Retail!
You’ve made a great first step in choosing Cloud Nine Retail, and we are sure you are going
to love it. Your account login details are shown below, so be sure to note these down or
print a copy. We’ve emailed them to you too, just in case.
Address: http://yourdomain.c9r.co
Email Address: youremail@yourdomain.com
Password: password
Use our wizard at the bottom of the screen to take the tour and help you get started, or you
can choose to skip it and take your own personal look around. Rest assured we are here to
help!
Regards,
The Cloud Nine Retail Team
It will also generate an email and send it to them.
From: welcome@c9r.co
Subject: Welcome to Cloud Nine Retail!
Body:
Welcome to Cloud Nine Retail!
You’ve made a great first step in choosing Cloud Nine Retail, and we are sure you are going
to love it. Your account login details are shown below, so be sure to keep this email safe or
print a copy.
Address: http://yourdomain.c9r.co
Email Address: youremail@yourdomain.com
Password: password
If you need any help, check out our great documentation!
Regards,
The Cloud Nine Retail Team
RTL may wish to edit the content of these emails later on, so please ensure these are developed in a
way that makes it easy for RTL to update them if necessary, and document accordingly.
The user which is created on signup will become the Account owner for that retailer account.
Multiple users can be added to their system later.
The process also needs to record the country of the business, which it can detect by IP/location of
the person performing the signup.
The system then also needs to record the date it was created.
1.3.3. First Store and POS Setup

The signup process should also create the first store (Named “Store 1”) and the first POS for that
store “POS 1”)
1.4. Content Management

We need a mechanism which will let us add and edit content pages. This will be accessible in the
Administration portal.
However the Marketing site needs to have the ability for RTL to add a link to a site which will call a
page created in the Administration portal. It should also display that page in the relevant local
language, if one exists.
The method for creating a link to the relevant page needs to be appropriately documented.
Deliverable 2: Administration Portal (Part 1)

2.1. Overview
The administration portal is where RTL staff can see the list of signed up retailers, access their
accounts and check billing information. It will also grant overall access to Suppliers and Customers,
and be where RTL Staff administer things like Supplier Integration data.
It should be found at http://admin.c9r.co
Much like the marketing website, this should support multi language, starting with both English and
Dutch.
2.2. Menu
The Admin portal will consist of a simple menu running across the top of the page. The left hand side
will have the Cloud Nine Retail logo, and the right hand side will have the following menu options.
Please use the same theme/CSS concepts taken from the marketing website to ensure a uniform
experience.
• Users (Only visible to the Owner Account) [See 2.3]

• Retailers [See 2.4]
• Suppliers [See 2.5]
• Customers [See 2.6]
• Partners [See 2.7]
• Apps [See 2.8]
• Policies [See 3.1]
• Pages [See 3.2]
• Tickets [See 3.3]
• My Account [Does the same as 2.3.4, but for the logged in user]
2.3. Users
It will be possible for many different RTL users to be granted access to the Administration Portal.
However there will be one “Account Owner” which is the primary super account.
2.3.1. Owner Account

This will be the first account created in the system and is the master user. It must have a complex
password and is granted overall access to everything
Username: admin@c9r.co
Password: complex random string
2.3.2. User List

This is a list of Admin Users (RTL Employees) who have access to the Administration Portal. It is a
simple table of users (Sortable ascending/descending by clicking column headings), and paginated.
It should show the following fields
• First Name
• Last Name
• Email Address
• Type
• Last Login Date
• Edit (Button)
• Delete (Button)
2.3.3. Create User

There needs to be the ability to create a new Admin User. Pressing the button should show a
lightbox style overlay containing a form. Only users of type “Admin” have the ability to create a user.
• First Name
• Last Name
• Email Address
• Type (Admin | Standard)
• Password
• Confirm password
The password boxes should require a complex password, and perhaps show a “Complexity score”.
It should also offer a Password Generator which will generate a secure password.
It should only allow creation of a password with a complexity score over 70 (Out of 100)
2.3.4. Edit User

Pressing Edit on the User List screen should show an overlay lightbox form allowing the edit of the
following fields. Only users of type “Admin” have the ability to create a user.
• First Name
• Last Name
• Email Address
• Type (Admin | Standard)
• Password
• Confirm password
The password/confirm boxes should only do something if something is entered in them. If the first
name for example is modified and saved, it should not save the password.
The password boxes should require a complex password, and perhaps show a “Complexity score”.
It should also offer a Password Generator.
It should only allow creation of a password with a complexity score over 70 (Out of 100)
2.4. Retailer Accounts

The purpose of this list is to show the list of retailers signed up to cloud nine retail, their key billing
information, and allow admin users direct access to the relevant customer’s Backoffice Portal.
2.4.1. Retailer List

This is a list of retailers who have signed up to Cloud Nine Retail. It is a simple table of retailers
(Sortable ascending/descending by clicking column headings), and paginated.
• Company Name
• First Name
• Last Name
• Email Address
• City
• Country
• Telephone Number
• Mobile Number
• Partner
• Signup Date
• Billing Date
• Last Billing Date
• Status ( Trial| Active | Overdue | Disabled )
Company name should be a hyperlink to http://their-subdomain.c9r.co, and it will log into their back
office automatically.
The partner column can be left blank for now, but it is there in case we want to introduce a referral
scheme.
There is no Edit function here. The idea being that things like Editing the retailer details, and closing
their accounts can all be performed by clicking their Company Name and accessing their back office.
The Status field has 4 states. When they are in their 30 day trial, then the status shows “Trial” and is
coloured orange/amber. When they are live and paying, they are Active, coloured green. If their
billing has failed, they are Overdue and coloured Red. And if they have terminated their account,
they are Disabled, coloured grey.
2.4.2. Search and Filter

In order to quickly find retailers, there should be a Search field at the top of the page. The search
field should check the string entered against the following fields.
• Company name
• First Name
• Last Name
• Email Address
There should be some filters on this page too, and they should work in combination with each other.
• City
• Country
• Partner
• Status
2.5. Suppliers
The purpose of this list is to show the list of suppliers who are granted access to Cloud Nine Retail.
These are people who have signed up through the Suppliers portal (Section 6).
2.5.1. Supplier List

This is a list of suppliers who have signed up to Cloud Nine Retail. It is a simple table (Sortable
ascending/descending by clicking column headings), and paginated.
• Supplier Name
• Contact First Name
• Contact Last Name
• City
• Country
• Telephone Number
• Mobile Number
• Catalogue Provider
• Sales Data
• Despatch Data
• Target Stock Data
• Stocktake Data
• Signup Date
• Billing Date
• Last Billing Date
Company name should be a hyperlink, which opens a data editing screen in a lightbox style so the
user data can be edited.
All fields except for Signup Date, Billing Date and Last Billing Date should be editable – those fields
should just be read only text.
Sales, Despatch, Target Stock and Stocktake Data are all check boxes. On the supplier ist a simple
check graphic is enough to indicate their status, but in the edit screen this should be toggleable.
This screen should also have a “Reset Password” function, which will generate and resend a secure
password to the email address associated with the supplier.

In order to quickly find retailers, there should be a Search field at the top of the page. The search
field should check the string entered against the following fields.
• Company name
• Email Address
• City
• Country
2.6. Customers
This should show a sample page, as this function will be developed at a later stage.
2.7. Partners
2.8. Apps
Deliverable 3: Administration Portal (Part 2)

3.1. Policies
This page will show 2 sections. Each of them consisting of a WYSIWYG editor
Section 1 – Terms and Conditions
Section 2 – Privacy Policy
It is a place where RTL can update these policies so all users can see them.
It should also support the use of variables. {retailer} when rendered in the retailers backoffice portal
will show their retailer name.
3.2. Pages
This should be a content management system. We should be able to create “Pages” of content
which can then be called from. It will be necessary for each page to be displayed in each language
that is held in the system.
3.2.1. Pages List

A simple table of pages, showing:
• Page Name
• Page Link
• Delete Button
When you try and delete a store, a confirmation prompt should appear (Lightbox style – NOT a
Javascript OK/Cancel button) it asks “Deleting a page will permanently delete all content in all
languages. Are you sure you want to continue?”
3.2.2. Pages Form

Clicking the page name will show a lightbox which will allow the edit of the page. It should show a
tab for each language. English will always be the default, and there should be an option to “Copy for
all languages” which will take the existing content for English and copy it to every language in the
system.
There should also be a new button, which shows the same detail as the edit button, but in a blank
form.
The editor should be WYSIWYG, but produce fully standards compliant HTML including complex DIVs
and custom CSS.
3.3. Support Tickets

As with any IT type system there is a requirement for users to lodge support tickets. We would like
this to be an integrated part of our platform. In later stages of the overall project, it will be possible
for users to create these tickets, but in this phase we need the ability for an RTL user to create and
update tickets.
3.3.1. Ticket List

When clicking “Tickets” from the main portal menu, the default screen is a sortable, paginated table
of support tickets. It should show the following details.
• Ticket Number
• Subject
• Retailer
• Contact Name
• Ticket Owner
• Ticket Status
• Priority
• Opening Time
• Last Updated Time
• [Close]
These fields are explained in detail in section 3.3.3. There should be a “Create Ticket” button here
too.
Clicking the Ticket Number or Subject will take the user to a lightbox overlay form containing the
ticket details.
Pressing the Close button will close the ticket.
This list should only show tickets which are NOT closed. There should be a check box which will let
the user see closed tickets “Show Closed Tickets” and clicking this will automatically refresh the list
to show closed tickets.

In order to quickly find support tickets, there should be a Search field at the top of the page. The
search field should check the string entered against the following fields.
• Retailer
• Ticket Number
• Subject
• Ticket Owner
• Ticket Status
• Priority
The search and filter should respect the “Show Closed Tickets” option in 3.3.1.
3.3.3. Ticket Form

The ticket form is Blank if “Create Ticket” is pressed, and is a fully open form with all the data entry
fields available to be entered.
If the ticket has been clicked from the ticket list, this shouldn’t be a form. Instead it should display all
the entered data in a read only format, and NOT look like it is in a form. There should be an edit
button, and when pressed it turns this page into a form.
The form consists of the following fields.
Ticket Number This is ALWAYS automatically generated and is not editable under any
circumstances.
Retailer This is a text entry box with AJAX. When typing, it should perform a wildcard search
of retailers in the database and display their names so that a retailer can be clicked
and selected.
Contact Name Text entry box with AJAX. When typing, it should perform a wildcard search of users
(Users that are created for the already selected retailer) in the database and display
their names so that a user can be clicked and selected.
Ticket Owner Text Entry box with AJAX. When typing it should perform a wildcard search of RTL
Employees (People with access to the administration portal) in the database and
display their names so they can be clicked and selected. This should default to be
the current logged in user.
Ticket Status This is a selectable combo box which offers the following statuses. Open/On Hold/In
Progress/Awaiting Customer/In Development
Priority Combo box with the following options. POS Issue/Back Office Issue/App Issue
Subject A text entry box which will let someone type in the subject of their ticket.
Description A large box which the user can enter in all the details of their ticket
Attachments The user should be able to upload attachments to the ticket. This should be a
javascript/AJAX type uploader and they can upload multiple attachments to the
ticket. It is possible to upload attachments when in Edit mode OR read only mode,
and it should also be possible to delete attachments.
Comments It will be possible for all tickets to have comments entered against them. These
comments get listed and should display the person who made the comment (Could
be an RTL employee or the customer), the date and time the comment was made,
and the content of the comment. It should also display if it is a public comment or
not. Comments are not editable, however when in Edit mode it should be possible
to delete a comment. Comments are listed in date order, oldest first.
When creating a ticket, it needs to record the date/time it was opened. When a ticket is modified, it
should record the date/time it was last updated.
When creating a ticket, it will email the user contact with the details of the ticket. The email content
is defined below. If the end user adds the ticket, this should email support@c9r.co. If an RTL
employee adds a ticket, it should email the user contact.
Subject C9R Support Ticket {Ticket Number} – {Subject}
Content {Contact First Name},
This email is notifying you that a Cloud Nine Retail support ticket has been created.
Here are the details of the ticket.
Ticket Number: {Ticket Number}

Subject: {Subject}
Description: {Description}
A C9R representative will be in touch with you to assist you with this issue. You can
add further comments and keep up to date on this ticket’s progress from your
Backoffice portal.
Regards,
The Cloud Nine Retail Support Team
3.3.4. Comments
Like any support ticket system, it will be possible for RTL employees or the ticket owner to add
comments to a ticket. Therefore, whenever a ticket is being looked at (In read only or edit mode)
there should be a little form at the bottom which will allow a user to add a comment to the ticket.
There are two fields.
Public This is simply a checkbox that indicates if the comment is visible to the end user or
not. Also, if this box is checked it will email the user to let them know a comment
has been made to their ticket.
Comment The content of the comment.
Adding a comment should do it in an AJAX style – and not refresh the whole page.
Adding a comment will also update the last updated field.
If the comment is “Public” it should email the user contact with the details of the ticket. The email
content is defined below. If the end user adds a comment, this should email support@c9r.co. If an
RTL employee adds a comment, it should email the user contact.
This email is notifying you that a comment has been added to your support ticket.

Subject: {Subject}
Comment: {Description}
Regards,
3.3.5. Closing Tickets

The only way to close a ticket is from the Ticket List. Clicking the Close button will show a lightbox
type overlay which will allow the user to enter the Resolution details of the ticket. A resolution
MUST be entered.
When closing the ticket, in addition to recording the resolution it also needs to record the closing
date/time, and the person who closed the ticket (Which could be an RTL employee or the end user).
It will also email the user. The email content is defined below. If the end user closes the case, this
should email support@c9r.co. If an RTL employee closes a case, it should email the user contact.
This email is notifying you that your support ticket has been closed.

Subject: {Subject}
Resolution: {Description}
If the issue is not closed to your satisfaction, the case will be reopened if you add a
comment through your backoffice portal.
Regards,
Appendix A: Testing and Validation Expectations

Functional Testing
All functions must be working in line with the specification. If RTL, during their testing identify a
function which has not been met it will be returned and does not meet the criteria for the
completion date. Only when all functions are developed will the delivery date be accepted.
Negative Testing
All data entry fields need to be negative tested, with different strings of special characters and
unexpected data entered. This is true of both the Functional Websites AND the API. Appropriate
error handling should be employed.
Standards Compliance
RTL will be passing the code through W3C validation for both XHTML and CSS. If the pages do not
validate then delivery is not classed as being met.
Appendix B: Documentation Expectations

Functional Documentation
All functions which the website performs should be documented, so that the scope of the
functionality designed is fully understood.
Code Commenting
All code must be commented and will be inspected by a third party developer to ensure it is
understandable and is possible to be worked on by other developers.

Cloud Nine Retail - Phase 1 Specification

Uploaded by

Copyright:

You might also like

Cloud Nine Retail - Phase 1 Specification

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Cloud Nine Retail - Phase 1 Specification

Uploaded by

Copyright:

Cloud Nine Retail | Phase 1

Cloud Nine Retail: Phase 1

1. Completion of a Marketing Website, the functionality of which is described in this document.

• The code is deployed to the RTL Rackspace environment

• If a deliverable is completed on time, a 5% bonus (5% of the deliverable payment) will be

Deliverable 1: Marketing Website

1.2. Multi Language

If the language does not exist, it will use English.

1.3. Customer Signup

1.3.1. Signup Form

This will create the retailer account in the system.

1.3.2. Account Creation

Welcome to Cloud Nine Retail!

The Cloud Nine Retail Team

It will also generate an email and send it to them.

Welcome to Cloud Nine Retail!

If you need any help, check out our great documentation!

The Cloud Nine Retail Team

1.3.3. First Store and POS Setup

1.4. Content Management

Deliverable 2: Administration Portal (Part 1)

It should be found at http://admin.c9r.co

• Users (Only visible to the Owner Account) [See 2.3]

2.3.1. Owner Account

2.3.2. User List

It should show the following fields

2.3.3. Create User

2.3.4. Edit User

It should also offer a Password Generator.

2.4. Retailer Accounts

2.4.1. Retailer List

It should show the following fields

2.4.2. Search and Filter

2.5.1. Supplier List

It should show the following fields

2.5.2. Search and Filter

Deliverable 3: Administration Portal (Part 2)

Section 1 – Terms and Conditions

Section 2 – Privacy Policy

3.2.1. Pages List

3.2.2. Pages Form

3.3. Support Tickets

3.3.1. Ticket List

Pressing the Close button will close the ticket.

3.3.2. Search and Filter

3.3.3. Ticket Form

The form consists of the following fields.

Subject C9R Support Ticket {Ticket Number} – {Subject}

Content {Contact First Name},

Ticket Number: {Ticket Number}

The Cloud Nine Retail Support Team

Comment The content of the comment.

Adding a comment will also update the last updated field.

Subject C9R Support Ticket {Ticket Number} – {Subject}

Content {Contact First Name},

Ticket Number: {Ticket Number}

The Cloud Nine Retail Support Team

3.3.5. Closing Tickets

Subject C9R Support Ticket {Ticket Number} – {Subject}

Content {Contact First Name},

Ticket Number: {Ticket Number}

The Cloud Nine Retail Support Team

Appendix A: Testing and Validation Expectations