Приклади специфікацій 12.09.13 / Project Requirements and Architecture
.pdf
|
|
|
|
one user should never exceed 50 ms. |
|
|
Evident |
Group according |
The site should display content and |
|
|
|
to the content |
links to content grouped according to |
|
|
|
tree |
the content tree. |
3.2 |
Display relationally linked |
Evident |
|
|
|
content |
|
|
|
Video Library: Front End
The CMS will drive the video library – however, the video library will be delivered in SMIL format:
Ref # |
Function |
Cat. |
|
Attribute |
Details/Constraints |
|
3.1.1 |
Display content |
Evident |
SMIL |
The video library will display in |
||
|
|
|
|
|
|
RealPlayer 7.0 or later, using SMIL. |
|
|
|
|
|
|
The opening ‘page’ will show a list of |
|
|
|
|
|
|
videos. Clicking on a video title will |
|
|
|
|
|
|
play that video in the same window |
|
|
|
|
|
|
(see below). |
|
|
Hidden |
Platform |
The video library will use RealSystem |
||
|
|
|
|
|
|
G2. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Video library opening screen
Opt-In Email Newsletter and New Content Notification
Site visitors will have the opportunity to provide their name and email address, and specify:
•That they want to receive regular emails regarding BIGORG events
•That they want to receive regular emails regarding events in a specific region
SAMPLE |
20 |
•That they want to receive regular emails regarding events in a specific industry
•That they want to receive an email when new content is added to a specific site area
Ref |
|
Function |
Cat. |
|
Attribute |
Details/Constraints |
# |
|
|
|
|
|
|
4.1 |
|
Opt-in email: Clicking ‘Email |
Evident |
|
Double Opt-in |
When someone registers for the |
|
|
newsletter signup’ will bring site |
|
|
|
email list, the system sends them an |
|
|
visitors to a form where they |
|
|
|
email asking that they verify that they |
|
|
can enter their name and email |
|
|
|
want to receive emails from |
|
|
address and indicate that they |
|
|
|
BIGORG. If they don’t want to, they |
|
|
want to receive updates from |
|
|
|
can send an email to BIGORG and |
|
|
the site. |
|
|
|
ask to be removed. |
|
|
|
Evident |
|
Feature selection |
A subscriber can choose to receive |
|
|
|
|
|
|
the BIGORG-wide newsletter, a |
|
|
|
|
|
|
newsletter specific to their territory (if |
|
|
|
|
|
|
available), and/or email when new |
|
|
|
|
|
|
content is posted to a specific site |
|
|
|
|
|
|
section. They can return and reenter |
|
|
|
|
|
|
their email address to change their |
|
|
|
|
|
|
settings at any time. |
|
|
|
Evident |
|
Newsletter |
Subscribers can choose to receive a |
|
|
|
|
|
|
newsletter dealing with BIGORG- |
|
|
|
|
|
|
wide issues and current events |
|
|
|
Evident |
|
Territory-specific |
Subscribers can choose to receive a |
|
|
|
|
|
newsletter |
newsletter specific to their territory |
|
|
|
Evident |
|
Industry-specific |
Subscribers can choose to receive a |
|
|
|
|
|
newsletter |
newsletter specific to their profession |
|
|
|
Evident |
|
New content |
Subscribers can choose to receive |
|
|
|
|
|
notification |
an email when new content is added |
|
|
|
|
|
|
to a specific section of the web site. |
|
|
|
Hidden |
|
CMS integration |
New subscribers should be inserted |
|
|
|
|
|
|
into the ‘users’ table of the CMS as |
|
|
|
|
|
|
‘public’ users |
|
|
|
Evident |
|
Opt-Out |
Every email will have a link to a web |
|
|
|
|
|
|
form – if the list member enters their |
|
|
|
|
|
|
email address into that form, they will |
|
|
|
|
|
|
be unsubscribed from that list. |
4.2 |
|
Email will be plain text |
|
|
|
|
|
|
|
Evident |
|
Attachments |
Editors will be able to attach files to |
|
|
|
|
|
|
emails. |
4.3 |
|
Email system administration |
Hidden |
|
CMS integration |
The email system should be part of |
|
|
|
|
|
|
the same interface as the CMS. |
|
|
|
Hidden |
|
General Security |
When someone logs into the system |
|
|
|
|
|
|
the security module detects whether |
|
|
|
|
|
|
they have access to the email tools, |
|
|
|
|
|
|
and the specific tools they can use. |
|
|
|
Hidden |
|
Content Security |
The security system also determines |
|
|
|
|
|
|
which specific email groups the |
|
|
|
|
|
|
logged-in staff can use: They may, |
|
|
|
|
|
|
for example, only be able to send |
|
|
|
|
|
|
email to a single territory. |
|
|
|
Evident |
|
Tree structure |
The email system should use the |
|
|
|
|
|
|
same tree paradigm as the CMS. |
|
|
|
|
|
|
The basic branches will be ‘General’, |
|
|
|
|
|
|
‘Territories’ and ‘Industries’. When an |
|
|
|
|
|
|
editor adds a sub-branch to any of |
|
|
|
|
|
|
these areas, that selection becomes |
|
|
|
|
|
|
available on the email subscription |
|
|
|
|
|
|
form. |
SAMPLE |
|
|
21 |
|
Ref |
Function |
Cat. |
Attribute |
Details/Constraints |
# |
|
|
|
|
|
|
Evident |
Branch-specific |
Editors will be able to send email to |
|
|
|
specific territories, industries or all of |
|
|
|
|
|
BIGORG’s email subscribers by |
|
|
|
|
selecting a specific branch of the |
|
|
|
|
email system tree. |
|
|
Evident |
Footer creation |
Administrators will be able to set up a |
|
|
|
|
single ‘footer’ that is used in every |
|
|
|
|
email sent. |
|
|
Evident |
Opt-Out |
Administrators will be able to see a |
|
|
|
searching/deletion |
list of all opted out users, and delete |
|
|
|
|
them. |
|
|
Evident |
Searchable/list |
Administrators will be able to list |
|
|
|
editing |
members by specified search criteria |
|
|
|
|
(group, opt-in status, name, etc) and |
|
|
|
|
edit status for those members. |
Microsites
The BIGORG site will eventually use existing CMS functionality to allow territories and other specific groups within BIGORG to build and maintain ‘microsites’. Microsites will be specific, second or third level branches of the site tree.
Ref # |
Function |
Cat. |
Attribute |
Details/Constraints |
5.1 |
Allow specific individuals to |
Evident |
CMS integration |
This feature will use existing security |
|
maintain BIGORG microsites. |
|
|
layer and CMS tools |
|
|
Evident |
Domain-specific |
The public will be able to access |
|
|
|
access |
these microsites either by entering a |
|
|
|
|
specific URL such as |
|
|
|
|
BigOrg.org?site=nursing, by providing |
|
|
|
|
a subdomain of BIGORG, such as |
|
|
|
|
nursing.BigOrg.org, or by using a |
|
|
|
|
referrer page to point a full domain, |
|
|
|
|
such as www.nursingBigOrg.org at |
|
|
|
|
the correct area. The latter two |
|
|
|
|
options will require assistance from a |
|
|
|
|
webmaster. |
Survey Engine
Portent Interactive has an existing survey engine – this engine is in use on the BIGORG.org site right now. While it is ColdFusion based, and therefore does not meet the ASP requirement of this project, the best solution is very likely to provide BIGORG with their own license for the survey system, and to let BIGORG continue to use our server to host the survey engine. The license price is only $200 and is included in this contract.
Site Partnership/Linking Program
Because ‘popularity’ –the number of links to your site – is the single strongest tool in increasing search engine ranking, Phase 2 of this project should include a site partnership
SAMPLE |
22 |
and linking program. While this will not involve any actual coding, there are several requirements worth noting:
Ref # |
Function |
Cat. |
Attribute |
Details/Constraints |
6.1 |
Provide specific instructions for |
Evident |
|
A page on the BIGORG web site will |
|
linking to the BIGORG web |
|
|
include code and graphics for |
|
site.. |
|
|
creating a link to BIGORG.ORG. |
6.2 |
Provide four possible graphics |
Evident |
|
We will provide four GIF images for |
|
for use |
|
|
linking to BIGORG: Two square and |
|
|
|
|
two rectangular, with one each for a |
|
|
|
|
dark or light background. |
|
|
|
|
|
SAMPLE |
23 |
Capital Advantage
BIGORG will provide information regarding connecting BIGORG to Capital Advantage.
Ref # |
Function |
Cat. |
Attribute |
Details/Constraints |
7.1 |
Capital Advantage functions |
Evident |
|
BIGORG’s site will continue to link to |
|
|
|
|
Capital Advantage resources. |
SAMPLE |
24 |
Section
7
Use Cases
Workflow diagrams
This section includes diagrams of typical workflows for each site component. Use cases display, step-by-step, how users interact with the system.
Security
Login:
SAMPLE |
25 |
Adding/editing users:
SAMPLE |
26 |
Content Management
Adding/editing/deleting nodes:
SAMPLE |
27 |
Content addition and approval:
SAMPLE |
28 |
Content edits are the same, except that only editors can modify content that has already been approved.
Content Deletion:
SAMPLE |
29 |