Running Head: Lab II – EmVi Product Specification Outline
Lab II - Product Specification Outline
CS 411W Lab II
Prototype Product Specification
For
EmVi
Version 3
Prepared by: Keith Walsh, Orange Team
Date: 11/25/2013
1
2
Table of Contents
3.
SPECIFIC REQUIREMENTS............................................................................................. 3
3.1 Functional Requirements ................................................................................................................ 3
3.1.1
Logon Experience, Account Maintenance and Security (David Wise) ......................................... 3
3.1.2
Work Flow Process (Tamara Jones) ............................................................................................. 9
3.1.3
Content Creation (Yolanda Quinones) ...................................................................................... 11
3.1.4
Content Storage, Retrieval, Version Control and Validation (Keith Walsh) .............................. 13
3.1.5
Content Distribution Network (CDN) Interface (Richard Truchanowicz) .................................. 18
3.1.6
Email Testing (Chris Dashiell) .................................................................................................... 22
3.2
Performance Requirements .......................................................................................................... 24
3.3
Assumptions and Constraints ....................................................................................................... 24
3.4
Non-Functional Requirements ...................................................................................................... 24
APPENDIX........................................................................................................................... 25
List of Figures
Figure 3-1 Registration and logon flow chart ..................................................................... 3
Figure 3-2 Email to Content Relationship ........................................................................ 13
List of Tables
Table 3-1 User Table .......................................................................................................... 8
Table 3-2 Message Table .................................................................................................... 8
Table 3-3 Campaigns Table .............................................................................................. 10
Table 3-4 Workflow Table................................................................................................ 11
Table 3-5 Reviewer’s Table .............................................................................................. 11
Table 3-6 Campaign to Content Example......................................................................... 14
Table 3-7 Content Table ................................................................................................... 17
Table 3-8 Content to Campaigns Mapping Table ............................................................. 17
Table 3-9 Content Types Mapping Table ......................................................................... 17
Table 3-10 Email Content Mapping Table ....................................................................... 18
Table 3-11 Email Images Mapping Table ........................................................................ 18
3
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Logon Experience, Account Maintenance and Security (David Wise)
This section will provide the requirements associated with access to the EmVi
tool. Described in this section will be the pages associated with the registration and
logon experience along with the security that follows a user throughout the current
session. Figure 1 provides a process flow of the requirements outlined in this section.
The following functional requirements must be met:
Figure 3-1 Registration and logon flow chart
3.1.1.1 Logon Experience
The way a user request access and logs into the EmVi tool will be defined in this
section. These requirements are necessary to lay out the proper foundation on which to
4
build the rest of the system. Without users the tool would not work. The following
functional requirements must be met:
3.1.1.1.1 Must contain a Registration page.
3.1.1.1.1.1 The registration page must retrieve and store in the database the following
information:
a.
First name
b.
Last name
c.
Username
d.
Email address
e.
Phone number
f.
Password (Hashed)
g.
Confirm password (Hashed)
3.1.1.1.1.2 There must be a submit feature on the registration page.
3.1.1.1.1.2.1 Submit must enforce best practice naming conventions for accounts.
a. Must verify that the username is an Email address.
3.1.1.1.1.2.2 Submit must verify minimum password requirements.
a. Password must be at least eight characters long.
b. Password must contain at least one capitol letter.
c. Password must contain at least one lower case letter.
d. Password must contain at least one number.
e. Password must contain at least one special character.
3.1.1.1.1.2.3 Submit must compare password and confirm password before storing.
5
3.1.1.1.1.2.3.1 If compare fails, there must be a notification to the user.
3.1.1.1.1.2.3.2 If compare fails, the form must be prepopulated with all data except
password and compare password fields.
3.1.1.1.1.2.3.3 On submit, the account data must be created in the database.
3.1.1.1.1.2.4 After successful submit, a message must be displayed informing the user
that the account was created successfully.
3.1.1.1.1.2.4.1 Must use a table to retrieve messages.
3.1.1.1.1.2.5 After successful submit, must send confirmation email to inform user that
account was created.
3.1.1.2 Account Maintenance
EmVi administrators must be able to manage accounts that are registered for access
to the system. The ability to enable accounts and modify information within an account is
key to keeping everything working in the system. Individual users must also be able to
modify their own accounts to update personal details and passwords. For account
maintenance, the following functional requirements must be met:
3.1.1.2.1 User account.
3.1.1.2.1.1 Must have the capability for any user to create an account.
3.1.1.2.1.2 Upon account creation, the account must be disabled.
3.1.1.2.1.3 Users must have the ability to modify the following values on their own
account.
a. First name
6
b. Last name
c. Email address
d. Password
e. Phone number
3.1.1.2.1.4 After successful account update, the system must inform the user of
successful edit.
3.1.1.2.1.5 Users must not have access to the system maintenance page.
3.1.1.2.2 Administrative account.
3.1.1.2.2.1 Administrators must have access to the system maintenance area.
3.1.1.2.2.2 Must have the ability to enable an account.
3.1.1.2.2.3 Must have the ability to update all values associated with any account.
3.1.1.2.2.4 Must have the ability to disable any account.
3.1.1.2.2.5 Must have the ability to update a user’s role.
3.1.1.2.2.6 Must have the ability to delete any account.
3.1.1.2.2.7 After an account has been updated by the administrator, the system must
inform them of successful edit (refer to 3.1.1.4.2 for table)
3.1.1.2.2.8 After a successful removal by the administrator, the system must inform them
of successful remove. (refer to 3.1.1.4.2 for table)
7
3.1.1.3 Account Security
This section will provide the requirements necessary to implement the security to
protect the data and email content that will be stored in EmVi. The following functional
requirements must be met.
3.1.1.3.1 EmVi must have a logon location.
3.1.1.3.1.1 Must present informative errors messages to handle invalid logon attempts.
a. Wrong username or password.
b. No user account exists.
c. No password entered.
d. Account is disabled.
3.1.1.3.1.2 Logon function must provide for a maximum number of failed logon
attempts.
3.1.1.3.1.3 When maximum failed attempts is reached, the user account must be
disabled.
3.1.1.3.1.4 An administrator must re-enable a disabled account.
3.1.1.3.1.5 EmVi must generate a session cookie on successful logon.
3.1.1.3.1.6 Must set cookie timeouts to require re-authentication after a set period of
time.
3.1.1.3.1.7 Cookie checking requirements need to be embedded in all pages of the
system to verify that user is still logged in.
8
3.1.1.4 Account database requirements
The database will store all the information necessary to authenticate users and set
their permission levels in the system.
3.1.1.4.1 The database must have a user table that contains the following fields:
Table name: tbl_user
Field Name
Data Type
Description
userID
int
Auto increment assigned
at registration
userFirstName
userLastName
text
text
User’s first name
User’s last name
userEmailAddress
text
User logon name and
Email address
userPhoneNumber
text
User’s Phone number
userPassword
text
Hashed password
userStatus
int
Enabled 1/ Disabled 0
userRole
int
Admin 1/User 0
userDateRegistered
datetime
Date that the user
registered for an account
userLastLogon
datetime
Last time and date of
successful logon
userFailedAttempts
int
Tracks incorrect logon
attempts
Table 3-1 User Table
3.1.1.4.2 The database must have a message table that contains the following fields:
Table name: tbl_msg
Field Name
msgID
msgTxt
Data Type
int
Text
Table 3-2 Message Table
Description
Message ID
Message Test
9
3.1.2 Work Flow Process (Tamara Jones)
This section outlines the process in which email marketing campaigns are
distributed with statuses, the capabilities a user can perform, and the database
requirements. The following functional requirements must be met:
3.1.2.1.
EmVi must allow a new campaign to be created.
a. Name of campaign can be entered.
b. Description of campaign can be entered.
3.1.2.2.
EmVi must allow a campaign to be viewed.
a. Preview can be sent for all attached email.
b. Reviewer’s previous and current comments are listed.
3.1.2.3.
EmVi must allow a campaign to be edited.
a.
Campaign properties are listed.
1. Content Name
2. Content Description
3. Content Keywords
4. Launch Date of campaign
5. Campaign Status
b. List of Reviewers can be chosen (up to five).
3.1.2.4
EmVi must allow emails to be attached.
a.
Provides a list of emails to be attached.
b.
Shows any existing emails that may be attached.
10
3.1.2.4.1 EmVi must allow a campaign to be cloned. Cloning a campaign will
make a copy of the existing campaign and attach the same content from the source
campaign to the new. Attachments can be seen in the view link.
a. Campaign clone properties are listed.
1. Content Name
2. Content Description
3. Content Keywords
4. Launch Date of campaign
5. Campaign Status
3.1.2.4.2 EmVi must allow a campaign to be placed in a status of in review by a
reviewer (approver).
3.1.2.4.3 EmVi must allow a campaign to be recalled.
3.1.2.4.4 EmVi must allow a campaign to be reassigned.
3.1.2.4.5 EmVi must allow a campaign to be placed in a complete status.
3.1.2.4.6 Database Requirements
3.1.2.4.6.1 Required campaign table layouts are depicted in tables 3-3 to 3-5.
Table Name: tbl_campaigns
Field Name
Data Type
campaignID
int, autoincrement, key
campaignName
text, unique
campaignOwner
int, foreign key to Users
campaignDescription
text
campaignKeyWords
text
campaignCreateDate
Datetime
campaignStatus
Int, foreign key to tbl_wfStatus
campaignLaunchDate datetime
Description
Unique identifier for each campaign.
Name for each campaign.
User who created the campaign.
Description of campaign
Keywords associated with campaign
Table 3-3 Campaigns Table
11
Table Name: tbl_wfStatus
Field Name
Data Type
wfStatusID
int, autoincrement, key
wfStatusName
text, unique
wfStatusDescription
wfOrder
Text
int
Description
Unique identifier for each workflow
status.
Name for each of the workflow
statuses.
Description of status
Integer representing the steps
Table 3-4 Workflow Table
Table Name: tbl_reviewers
Field Name
Data Type
campaignID
reviewerID
int, foreign key to tbl_campaigns
statusID
int, foreign key to tbl_wfStatus
isComplete
bool
Description
int, foreign key to tbl_content
Table 3-5 Reviewer’s Table
3.1.3 Content Creation (Yolanda Quinones)
This section will provide the requirements associated with the creation and
modification of email marketing content through the integration of a WYSIWYG editor.
HTML or text content can either be created or modified by a user.
3.1.3.1 Content Creation
The capability of a user to create content will be described in this section. Content
can be either a text file, which can be created or modified in the WYSIWYG editor, or an
image file. For those files where the WYSIWYG editor is relevant, the necessary features
are as follows:
3.1.3.1.1 Must provide spellcheck.
3.1.3.1.2 Must provide capability to view the HTML source code.
3.1.3.1.3 Must provide the ability to paste text from another application.
12
3.1.3.1.4 Must provide an undo function.
3.1.3.1.5 The new content must be saved to a file.
3.1.3.1.6 The content file name must be stored in the content table.
3.1.3.2 Content Modification
The capability to modify existing content will be described in this section. Once
content is created, it is saved as a file. Users must be able to modify HTML and text files
by utilizing a WYSIWYG editor. The necessary features are as follows:
3.1.3.2.1 Must load content into the WYSIWYG editor for editing.
3.1.3.2.2 Must provide spellcheck.
3.1.3.2.3 Must provide capability to view HTML source code.
3.1.3.2.4 Must provide the ability to paste from other applications.
3.1.3.2.5 Must provide an undo function.
3.1.3.2.6 Must be able to save content back to existing location with existing file name.
3.1.3.2.7 Must be able to update content tables with update information.
3.1.3.3 Database requirements
Content creation and editing leverage the data tables for users and content.
No additional tables are necessary.
13
3.1.4 Content Storage, Retrieval, Version Control and Validation (Keith
Walsh)
Content is a file that goes into making up an email. Content can be an image, an
HTML file or a plain text file. Emails are made up of an HTML file, a text file and zero
or more image files. Any user of EmVi can create content, but once it exists it must only
be updated or removed by a user who has explicit permission to do so. Figure 3-4 and
Table 3-6 depict the relationship between content and emails. For content storage,
retrieval and version control, the following functional requirements must be met:
Figure 3-2 Email to Content Relationship
(This space intentionally left blank)
14
Table 3-6 Campaign to Content Example
3.1.4.1 Content Creation
All content files, along with their defined properties, must be stored by the
application. For content creation, the following requirements must be met:
3.1.4.1.1 The application must provide the capability to upload content files from the
user’s desktop.
3.1.4.1.2 Acceptable file formats must be defined within the table tbl_contentTypes.
3.1.4.1.3 When a user adds content to the application, that content file must be saved to
disk.
3.1.4.1.4 Once content is created, the user with permission to update or delete that
content must be identifiable within the table tbl_content.
3.1.4.1.5 When updates are made to content, the identity of the user who made the
update must be stored in the table tbl_content.
3.1.4.2 Email Creation
Email content consists of one HTML and one text file. Additionally, it may
contain images that appear within the HTML content.
15
3.1.4.2.1 The application must provide the capability to associate HTML content with an
email.
3.1.4.2.2 The application must provide the capability to associate text content with an
email.
3.1.4.2.3 The application must provide the capability to associate zero or more image
contents with an email.
3.1.4.2.4 The application must provide the capability to associate a subject line with an
email.
3.1.4.2.5 The application must provide the capability to associate a from name with an
email.
3.1.4.2.6 The application must provide the capability to associate a from address with an
email.
3.1.4.2.7 The application must provide the capability to view both the HTML and text
files in a browser.
3.1.4.3 Content Version Control
The system must have a way of ensuring that a user’s updates do not overwrite
another’s in an unpredictable way. For version control, the following functional
requirements must be met:
3.1.4.3.1 The user who creates content is the only user who can edit or delete that
content provided that content is not associated with an email.
3.1.4.3.2 A user who creates an email and associates content to that email is the only
user can edit or delete any associated content provided that the email is not
16
associated with a campaign and the content is not associated with any other
emails.
3.1.4.3.3 A user who creates a campaign and associates email to that campaign is the
only user who can edit or delete any associated emails or content provided that
the campaign is not associated with any other emails, campaigns or workflows.
3.1.4.3.4 A user assigned the current task in the workflow may edit or delete any emails
associated with the campaign provided that email is not associated with any
other campaigns.
3.1.4.3.5 A user assigned the current task in the workflow may edit or delete any content
associated with any emails in the campaign provided that content is not
associated with any other emails or campaigns.
3.1.4.3.6 Any user can view content.
3.1.4.3.7 Any user can copy, or “clone,” content.
3.1.4.3.8 Any user can view an email.
3.1.4.3.9 Any user can copy, or “clone,” an email.
3.1.4.4 Content Database
The database must store all necessary information (metadata) about campaign
content. The actual files that make up the campaign must be stored as files outside of the
database. Tables 3-7 to 3-10 depict the schema for the content tables.
Table Name: tbl_content
Field Name
Data Type
contentID
int, autoincrement, key
contentName
contentDescription
contentKeyWords
text
text
text
Description
Unique identification for each
content file.
Name for content element.
Description for content element.
Keywords associated with content.
17
contentType
int, foreign key to
tbl_contentType
createdDate
datetime
updatedDate
datetime
createdBy
int, foreign key to User
updatedBy
int, foreign key to User
fileLocation
text
canEdit
int
cdnID
in
Comma separated string.
Distinguishes between different file
types.
When the content file was saved for
the very first time.
Most recent saved time.
User who saved the content file for
the very first time.
User who saved the content file
most recently.
Local path to the file contents.
User who can make changes to the
content.
ID of the CDN if published.
Table 3-7 Content Table
Table Name: tbl_contentToCampaigns
Field Name
Data Type
contentID
int, foreign key to tbl_content
campaignID
int, foreign key to
tbl_campaigns
Description
Content ID
Campaign ID
Table 3-8 Content to Campaigns Mapping Table
Table Name: tbl_contentTypes
Field Name
Data Type
typeID
int, autoincrement, key
typeName
text
typeFormat
text
Description
Unique identifier for each content
type.
Name of type for each content type
(i.e. “image,” “text”)
The file extension for the image (i.e.
“html,” “gif,” “png”).
Table 3-9 Content Types Mapping Table
Table Name: tbl_emailContent
Field Name
Data Type
emailID
int, autoincrement, key
emailName
emailDescription
emailHTMLID
emailTextID
text
text
int
int
Description
Unique identifier for each content
type.
Maps to content table
Maps to content table
18
emailSubject
emailFromName
emailFromAddress
canEdit
text
text
text
Int
Maps to userID
Table 3-10 Email Content Mapping Table
Table Name: tbl_emailImages
Field Name
Data Type
emailID
int, autoincrement, key
contentID
int
Description
Unique identifier for each content
type.
Maps to content table
Table 3-11 Email Images Mapping Table
3.1.5 Content Distribution Network (CDN) Interface (Richard
Truchanowicz)
The CDN Interface coordinates uploading of images from the local database to
the selected CDN for testing and final distribution while also updating image URLs
(Uniform Resource Locator) to reflect the locations on the CDN. The interface shall be
implemented with a modular design that allows for the easy addition of CDNs by
decoupling the CDN specific interface from the database interface. The following
functional requirements must be met:
3.1.5.1 CDN Interface UI must contain the following pages:
3.1.5.1.1 CDN Configuration Page. This interface page allows the addition, deletion and
modification of CDNs available for uploading.
3.1.5.1.2 Must display the following fields:
3.1.5.1.2.1.1 CDN Listings:
a. CDN Name
19
b. CDN Account Name
c. Status
d. Date added
3.1.5.1.2.2 Configuration Interface must allow for the following actions:
a. Add CDN
b. Modify CDN
c. Delete CDN
3.1.5.1.3 Must contain a Campaign-CDN Management Page. This interface page lists all
campaigns in the system, which CDN they are configured for and their current
upload status.
3.1.5.1.3.1 Campaign-CDN Management Page must display the following fields:
3.1.5.1.3.2 Campaign Listings:
a. Campaign Name
b. Creator Name
c. Start Date
d. End Date
e. Selected CDN
f. Upload Status
3.1.5.1.3.3 Navigation Links:
a. CDN Configuration Page
b. Return to CDN Landing Page
20
c. Logoff
3.1.5.2 The CDN Interface must contain a CDN-Database Exchange Interface
processing module.
3.1.5.2.1 This module is a CDN agnostic interface that is responsible for pushing and
pulling data between the database and the selected CDN specific module. The
CDN-Database Exchange is composed of the following functional areas.
3.1.5.2.2 The Outbound Assets Process is responsible for retrieving assets from the
database and handing those assets off to the CDN Specific Interface. The
following functional requirements must be met:
3.1.5.2.3 Must retrieve assets from database
3.1.5.2.4 Must pass assets to appropriate CDN Specific Interface
3.1.5.2.5 CDN Asset URL Update Process is responsible for updating the CDN Asset
URL database entry for each asset uploaded to the CDN. The following
functional requirements must be met:
3.1.5.2.5.1 Must receive CDN upload URLs from CDN Specific Module
3.1.5.2.5.2 Must store Asset CDN URLs in database (See 3.1.4.4)
3.1.5.3 The CDN Specific Interface Module is responsible for passing assets and
asset locations between the CDN-Database Interface and the selected CDN.
3.1.5.3.1 The CDN Interface is composed of the following functional areas.
21
3.1.5.3.2 The Outbound Assets Process is responsible for receiving assets from the
Database-CDN Interface and uploading them to the selected CDN. The
following functional requirements must be met:
3.1.5.3.2.1 Must be able to receive assets from CDN-Database Exchange
3.1.5.3.2.2 Must be able to upload assets to CDN
3.1.5.3.3 The CDN URL Retrieval Process is responsible for retrieving the new URLs
for recently uploaded assets and passing these to the CDN-Database Exchange.
The following functional requirements must be met:
3.1.5.3.3.1 Must be able to retrieve asset URLs upon successful upload
3.1.5.3.3.2 Must be able to pass asset URLs to CDN-Database Exchange Interface
3.1.5.3.4 The CDN Asset Deletion Process is responsible for removing uploaded assets
from the CDN. The following functional requirements must be met:
3.1.5.3.4.1 Must be able to delete uploaded assets from CDN
3.1.5.3.4.2 Must be able to verify assets are no longer reachable from the previous CDN
URL
3.1.5.4
Database Requirements
The database must store all necessary credentials for configuring a CDN to accept
asset uploads. It must also keep track of which assets have been uploaded and the
assigned URLs for those assets.
22
Table Name: tbl_cdn
Field Name
cdnID
cdnUsername
Data Type
Int, foreign key to tbl_cdn
string
cdnAPIKey
string
createdDate
datetime
Description
CDN ID
Authentication username for
accessing CDN.
Passkey generated by CDN to
authorize username.
When the CDN was added to
EmVi.
Table 3-13 CDN Configuration Table
Table Name: tbl_cdnUploads
Field Name
Data Type
contentID
int, foreign key to tbl_content
campaignID
int, foreign key to
tbl_campaigns
cdnID
Int, foreign key to tbl_cdn
uploadedDate
datetime
modifiedDate
datetime
cdnURL
string
Description
Content ID
Campaign ID
CDN ID
When the file was last uploaded
Modification time stamp of
uploaded file. Used for
determining if latest version is
uploaded.
CDN URL for uploaded asset
Table 3-14 CDN Uploaded Assets Table
3.1.6 Email Testing (Chris Dashiell)
Two options must be provided for testing how emails are rendered in the across
different email clients. The preferred method provides the user to view a page that has
screenshots of what the rendered email looks like in each client. Because a third party
service will be used for the creation of the screenshots as a backup in case the service is
not currently working there must be ability to send the emails to a set of user provided
email addresses. This allows the user to manually log in to each of the email addresses to
see what the email looks like in each client. The following functional requirements must
be met:
23
3.1.6.1 Must have an Email Testing page.
3.1.6.1.1 The testing page must be associated with and accessed through the campaign
page.
3.1.6.1.2 The testing page must display a table with the following columns:
3.1.6.1.2.1 Email name.
3.1.6.1.2.2 View preview button.
3.1.6.1.2.3 Generate preview button.
3.1.6.1.2.4 Send to list button.
3.1.6.1.3 The view preview button must take the user to a page displaying a set of
images of what the email looks like rendered in each email client supported.
3.1.6.1.4 The generate preview button must generate a new set of images using a third
party service.
3.1.6.1.4.1 Must save the set of images to the file system.
3.1.6.1.4.2 Must delete the old set of images from the file system.
3.1.6.1.4.3 Must update the database with the new file paths.
3.1.6.1.4.4 Must display any errors to the user that are encountered in this process.
3.1.6.2 Must have an Email Address List page
3.1.6.2.1 The email address list page must be associated with and accessed through the
campaign page.
24
3.1.6.2.2 Must display a list of email addresses currently associated with the campaign.
3.1.6.2.3 Must provide a method of adding a new email address to the list.
3.1.6.2.4 Must provide a method of deleting an email address from the list.
3.1.6.3 Testing database requirements
3.1.6.3.1 The database must have a table to store the file system paths to image previews
for each email.
Table Name: tbl_TestEmailPreviews
Field Name
Data Type
Description
emailID
int, foreign key
Email ID
to
tbl_emailContent
fileLocation
text
Local path to the image file
of the rendered email.
emailClientName
text
Name of the email client the
email was rendered in.
Table 3-15 Email Preview Table
3.1.6.3.2 The database must have a table to store the list of email addresses for each
campaign.
Table Name: tbl_TestEmailList
Field Name
campaignID
testEmailAddress
Data Type
int, foreign key to
tbl_campaigns
text
Table 3-16 Email List Table
3.2 Performance Requirements
3.3 Assumptions and Constraints
3.4 Non-Functional Requirements
Description
Campaign ID
Email Address
25
Appendix