head	1.10;
access;
symbols;
locks; strict;
comment	@# @;


1.10
date	2005.11.01.15.27.23;	author RicardoPereira;	state Exp;
branches;
next	1.9;

1.9
date	2005.11.01.13.48.38;	author RicardoPereira;	state Exp;
branches;
next	1.8;

1.8
date	2005.11.01.11.01.41;	author RicardoPereira;	state Exp;
branches;
next	1.7;

1.7
date	2005.11.01.09.51.11;	author RicardoPereira;	state Exp;
branches;
next	1.6;

1.6
date	2005.10.28.19.27.15;	author RicardoPereira;	state Exp;
branches;
next	1.5;

1.5
date	2005.10.28.12.02.51;	author RicardoPereira;	state Exp;
branches;
next	1.4;

1.4
date	2005.10.28.09.52.54;	author RicardoPereira;	state Exp;
branches;
next	1.3;

1.3
date	2005.10.28.01.24.24;	author RicardoPereira;	state Exp;
branches;
next	1.2;

1.2
date	2005.10.27.17.20.13;	author RicardoPereira;	state Exp;
branches;
next	1.1;

1.1
date	2005.10.27.16.58.24;	author RicardoPereira;	state Exp;
branches;
next	;


desc
@none
@


1.10
log
@none
@
text
@%META:TOPICINFO{author="RicardoPereira" date="1130858843" format="1.1" version="1.10"}%
%META:TOPICPARENT{name="CurrentWebsiteDocuments"}%
---+!! TDWG Website Requirements

%TOC%

---++ Introduction

This report provides requirements for an operational environment (called "The Website" in this report) for the development and communication of its standards.

Project scope and requirements are controlled by using the TAG.MoSCoW (Must, Should, Could, Won't) convention.

   * _Please read TAG.HowToContribute for advice on how to provide constructive contributions. Feel free to add comments next to the appropriate requirement. Make sure you add your comments in italic, in a bullet item, sign and date it (just like this paragraph). The editor (Main.RicardoPereira) will address your comment and change text accordingly._

-- Main.RicardoPereira - 27 Oct 2005

---++ R1. Standards Requirements

---+++ R1.1. Comprehensive Standards Repository (Must)

The Website must serve and advertise its standards effectively. The Website must provide a comprehensive and up-to-date repository of TDWG standards. Users must be able to locate and download standard specifications easily, either by using regular website navigation or via search engines. 

Standards have a better chance of being adopted if they are well advertised and accessible. Users will spend less time looking for standards if they are well organized and presented in a centralized repository.

---+++ R1.2. Standards Metadata (Must)

The website must provide accurate and up-to-date metadata record for each standard in the repository. Each metadata record should contain the standard name, version, publication date, type (such as Data Exchange, Controlled Vocabulary), editor (and contact information), current status, status change history, purpose, rationale, standard change history, previous versions, upcoming releases, relationship to other standards, reference implementations, and a list of projects and systems currently using the standard.

Team members carefully analyze several aspects of standards before adopting them, such as quality, level of maturity and deployment. Rich and updated metadata records that follow a standard profile facilitate the decision making process and thus are likely to increase adoption of standards. 

Some standard metadata fields, such as name, document number, date, type, and editor, must not change in time (except in case of errors). Other fields, such as upcoming releases, related standards, relationships, reference implementations, and projects using the standard, must be updated regularly.

For requirements on the standards contents and formats, please refer to the companion document *"TDWG Standards Documentation and Software Requirements."*

---+++ R1.3. Configurable Standards Statuses and Types (Must)

Standards must have an associated status, which can change in time. The list of standards statuses shall be defined by the Process Subgroup. Statuses coincide with standard maturity levels present on the standards track. Adopted standards must take precedence over retired or superseded ones for presentation and accessibility purposes. The website should allow administrators to configure the list of standards types and statuses.

The status of a standard conveys its level of maturity and helps users to decide whether to adopt a standard or not. Over time, TDWG is likely to make adjustments to its standards development processes, thus imposing changes to the standard statuses. Similarly, new kinds of standards can be created, thus requiring the list of standard types to be extended.

---+++ R1.4. Relate Standards to Respective Subgroups (Must)

Standards must be easily related to the subgroup that produced it.

There is more information about a standard than that is found in its specification and metadata record. Additional contextual information can be gathered from the subgroup that produced it. Such information is helpful to users when deciding to adopt a standard or when they need to understand the reasoning behind a particular design decision. 

---+++ R1.5. Stable Web Address for Standards (Should)

Standards specifications (downloadable file) and its information page should have stable web addresses regardless of changes in status to allow persistent references, book marking, and to preserve external linking. Each TDWG standard could be assigned a global unique identifier.

---++ R2. Subgroup Requirements

---+++ R2.1. Dedicated Area for Subgroups on Website (Must)

Each TDWG subgroup must have a dedicated area on the Website. This area must be easy to locate by users navigating through the website or coming from search engine results. 

TDWG standards are developed in the context of subgroups. Gathering subgroup information into individual areas within the website improves subgroup operation and makes communication more effective.

---+++ R2.2. Subgroup Metadata (Must)

Subgroup areas must contain updated information about the group, such as purpose, scope, recent and upcoming events, activities, call for reviews, milestones, schedule, drafts, standards produced, related subgroups, documentation, other resources, list of members, convener, contact information, and instructions to participants (how to join, contribute, review drafts, for example). 

Such information enables subgroup members and interested parties to identify subgroup status. Requiring subgroup information to conform to a fixed profile improves readability and makes it easier for existing users to locate relevant information, thus improving subgroup operation.

Subgroup conveners and secretaries are responsible for keeping subgroup progress and efficient operation. Therefore, the website should allow conveners and secretaries to edit information about their respective subgroups. It is in their best interest to keep subgroup information profile updated. If it is simple enough to use, the website can replace other non-standard means of communication convener use to publish news, advertise events and calls for review. 

---+++ R2.3. Subgroup Statuses (Must)

Subgroups must be assigned statuses that classify them according to their level of activity and requirements in terms of progress, production and scheduling. Subgroup statuses can change in time. The currently defined subgroup statuses are three: Task Group, Interest Group, and Closed Group. More active groups must take precedence for presentation and accessibility purposes.

---+++ R2.4. Stable Web Addresses for Subgroup Areas (Should)

Subgroup home pages should have stable URLs regardless of possible changes in status (i.e. being retired) to allow book marking and to preserve external linking. Information about closed subgroups should be less prominent than active subgroups. 

---++ R3. Subgroup Operation Requirements

---+++ R3.1. Flexible Document Development Tools for Subgroups (Must)

Standards are specifications – documents. The website must provide flexible tools to support collaborative and incremental development of documents. 

---+++ R3.2. Documented Standards Development Process (Must)

TDWG website should support new standards development process by providing accessible on-line documentation and tutorials, and by automating repetitive steps in the process.

TDWG should provide guidelines and training materials for subgroup conveners and members. Guidelines should contain general recommendations on how to guide subgroup work, maintain openness, fairness, how to keep the subgroup progress, how to achieve and measure consensus while allowing for debate. 

---+++ R3.3. Structured Review Process (Should)

TDWG should provide subgroups with effective on-line collaborative tools to assist with reviewing drafts and standards. Such tools will enable editors to break down the complexity of the documents being reviewed, guide reviewers through a structured review process, and facilitate synthesis of comments made into a refined draft. The tools should require contributors to author and comment drafts within a well defined time frame.

Current TDWG subgroups are not reviewing drafts. This appears to be because the work is not broken into manageable tasks.

---+++ R3.4. Defect Control (Should)

TDWG should provide simple mechanisms for users of standards to report problems and comments. Such valuable information should be incorporated into a subgroup's information system for subsequent evaluation.

---+++ R3.5. Traceability of Design Decisions (Should)

TDWG subgroups should document all changes in standards development and record the reasoning behind such changes. 

Traceability prevents defects late in the development process and allows designers to trace the evolution from the original design requirements.

---++ R4. Website Design Requirements

---+++ R4.1. Ease of Use (Must)

The Website must be easy to use, intuitive, and therefore require a minimum effort to be learnt. Advanced computer users will benefit from ease of use and administration. Client-side requirements should be minimized, requiring only a moderately updated web browser.

---+++ R4.2. Ease of Maintenance (Must)

The Website must be able to be maintained with minimal administrative effort. 

It is anticipated that TDWG resources may be limited. If so, any system developed to support TDWG activities must require minimal administrative effort to maintain effective functionality.

---+++ R4.3. Flexible Navigation (Must)

The website must allow administrators to change overall navigation structure with minimal effort. Administrators must be able to add pages to, remove pages from, and rename pages on the website through the administration user interface. Administrators must also be able to easily move an entire hierarchy of pages. 

TDWG organizational structure and goals will change over time and so the navigation structure must be capable of change as well. Changes to website navigation might require changes to content to maintain consistency.

---+++ R4.4. Separation of Contents and Presentation (Must)

The Website graphical design should be decoupled from its contents. In other words, it should be easy to change the Website look without requiring rewriting of any content items. The Website should be driven by templates and style sheets. 

Flexible navigation and separation of contents from presentation together allow the website to be completely rearranged to follow organizational changes without much effort. 

---+++ R4.5. Efficient Communication (Must)

The website must provide communication facilities to boost member activity and to keep interested parties updated. The website must use a combination of "push" and "pull" technologies to achieve that goal.

As one TDWG member put it, people need to see action to take action. Push technologies must be used to notify members of relevant events and to request action. The notifications should target appropriate parties as much as possible to avoid disturbing other members. Members must be able to subscribe or unsubscribe for individual notification streams easily.

On the other hand, the website must be often updated to reflect latest news and developments regarding standards and subgroups activities. 

---+++ R4.6. Cross-Browser Cross-Platform Compatibility (Must)

To reach a broader audience, the website must be rendered properly in wide range of browsers across several platforms, such as Windows, Mac, Linux, and other flavors of UNIX. List of compatible browsers should be presented on the website. Browser compatibility must be tested.

Slight differences in page rendering across browsers are allowed as long as they do not disrupt any website functions or disarrange its layout or graphical design.

---+++ R4.7. Search Engine Friendliness (Should)

Many users find a website for the first time through search engines such as Google and Yahoo. 

Therefore, the website must be designed to optimize search engine indexing, to ensure good positions in search engine results.

---+++ R4.8. Fast to Load (Should)

Website pages should be fast to download and display. The time it takes to display a page includes both dynamic page rendering and download times. Download times are determined by the bandwidth available for both client and server, while page processing and rendering times depend on server performance, its load, and web application optimization. 

Users are willing to wait for pages to load for a certain amount of time. After that they give up and go away. For that reason, web pages should take no more than 5 to 10 seconds to display, which would allow up to about 50KB to be downloaded in standard dial-up connections.

---+++ R4.9. Ability to Track Usage (Should)

The website must record usage and inform the user about it. The website must also describe how this information will be used (see requirement R5.1).

Analysis of detailed website usage information allows the discovery of usability problems and uncovers common usage pattern. Such information is fundamental subsidy to guide website enhancements.

---+++ R4.10. Compliance to Web Standards (Should)

The Website itself should also comply with web standards, such as W3C CSS, HTML, and accessibility standards. 

Conformance to current web standards improves accessibility and user experience, reduces website development and maintenance costs, and maximizes compatibility with current and future web browsers.

---+++ R4.11. Content Migration (Must)

The creation of website content, especially standards specifications, is a significant investment and may be risked if the technology used to deliver the content fails or becomes obsolete. 

The Website should provide mechanisms to support migration of contents to a new platform, in full, without loss of content or requiring rewriting of artifacts.

---+++ R4.12. Internationalization (Could)

English is the official language of TDWG website. However, the Website could be able to accept and present content in other languages as well. 

---+++ R4.13. No Broken Links (Could)

The website should not contain any broken links. They could be detected by automated tools made available to website administrators.

Broken links are an annoyance to users. They reduce trust of user on the website and on the organization as a whole.

---+++ R4.14. Shared Maintenance

Different users should be responsible for maintaining specific pages on the Website. Subgroup conveners or secretaries should have appropriate privileges to update and modify content items on their own subgroup areas. Content managers should be able to modify web pages and post news items. Users responsible for organizing annual or subgroup meetings should have access to modify the respective website sections. Administrators should have control over the entire website.

Users and administrators should be able to manage the Website remotely. 

Website administration should be redundant to avoid bottlenecks.

---+++ R4.15. Security (Must)

The Website must be immune to attack of malicious users and software. Administrators must have a clear strategy to keep themselves up-to-date with latest security threats and to address these threats properly.

Although TDWG may not present the profile of heavy targeted systems, there is enough malicious software on the Internet that can attack and bring down the website, disrupting members work and eroding users trust.

---+++ R4.16. Look and Feel (Should)

The website should look and feel good. Nice look and feel make users them wish to return to the website.

---++ R5. Content and Documentation Requirements

---+++ R5.1. Process Descriptions, Tutorials and Guidelines

The website should provide good quality documentation about its processes. 

Having well documented processes speeds up standards development and other subgroup related operations. Members spend less time thinking about structure and more time writing content.

---+++ R5.2. Privacy Policy (Should)

The website should describe which user information is recorded and how that information is used. Users should be able to locate and read the privacy information page easily.

---+++ R5.3. "How to Use This Website" Page (Could)

The website could provide an overview on how it is organized to guide new users, i.e., provide a "how to use this website" page. 

---+++ R5.4. Relationship with Other Standards Organizations (should)

The website should describe the relationship between TDWG and other standards organizations, such as GBIF, OGC, ISO, and CODATA.

---++ R6. Requirements Outside the Project Scope (Won't)

The following requirements are outside project scope, thus will not be addressed by the Website.

---+++ R6.1. Website Will Not Support Software Development (Won't)

The Website will not provide any tools for software development, such as version control, defect tracking system (except for standards specifications). There is a number of websites offering such services. TDWG will not be able to match their service quality and level of support and will not have enough resources to maintain such services.

-- Main.RicardoPereira - 1 Nov 2005
@


1.9
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130852918" format="1.1" version="1.9"}%
a16 5
   * _This page is under active development so you might want to come back later to check progress._

-- Main.RicardoPereira - 28 Oct 2005


d137 1
a137 1
Any moderately updated web browser must be able to render website pages properly. List of compatible browsers must include the most commonly used ones in each of the main computer platforms (Windows, Mac, Linux, and other flavors of UNIX). List of compatible browsers should be presented on the website. Browser compatibility must be tested
a140 2
There is wide variation to the extent that web browsers implement particular web standards. Also, rendering of standard tags is slightly different from one browser to another. To reach a broader audience, the website must be rendered properly in wide range of browsers.

d149 1
a149 1
Website pages should be fast to download and display. In the worst case, web pages should take no more than 5 to 10 seconds to display. This threshold should take into account both page rendering and download times. Download times are related to available bandwidth for the client and server, while page processing and rendering times depend of server performance, its load, and web application optimization. 
d151 1
a151 1
Users are willing to wait for pages to load for a certain amount of time. After that they loose interest, give up and go away. The threshold is between 5 to 10 seconds, which allow up to about 50KB to be downloaded in standard dial-up connections.
d155 1
a155 1
The website must record usage and inform the user about it. The website must also describe how this information is to be used (see requirement R5.1).
d163 1
a163 1
Conformance to current web standards improve accessible and user experience, lower website development and maintenance costs, and maximize compatibility with current and future web browsers.
d167 1
a167 1
The creation of website content, especially standards specifications, is a significant investment and it should not be risked in the technology used to deliver that content fails or becomes obsolete. 
d177 1
a177 1
The website must not contain any broken links. Website administrators could use automated tools to detect such links.
d179 1
a179 1
Broken links are an annoyance to users. They reduce trust of user on the website and the organization, and make them go away.
d191 1
a191 1
The Website must be immune to attack of malicious users and software. Administrators must have a clear strategy to keep up-to-date with latest security threats and to address them properly.
d193 1
a193 1
Although TDWG may not present the profile of heavy targeted systems, there are automated worms and malicious software that can attack and bring down the website, disrupting members work and eroding users trust.
d197 1
a197 1
The website should look and feel good. Nice look and feel make users them want to come back to the website.
d205 1
a205 1
Having well documented process speeds up the standards development process and other subgroup related operations. Members spend less time thinking about structure and more time concerned about content.
d209 1
a209 1
The website should describe what user information it records and how that information is used. Users should be able to locate and read the privacy information page easily.
d225 1
a225 1
The Website will not provide any tools for software development support, such as version control, defect tracking system (except for standards specifications). There is a number of websites offering such services. TDWG will not be able match their service quality and level of support and will not have enough resources to maintain such services.
d227 1
a227 1
-- Main.RicardoPereira – 1 Nov 2005
@


1.8
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130842901" format="1.1" version="1.8"}%
d28 1
a28 1
Standards have a better chance of being adopted if they are well advertised and easily accessible. Users will spend less time looking for standards if they are well organized and presented in a centralized repository.
d32 1
a32 1
The website must provide accurate and up-to-date metadata record for each standard in the repository. Each metadata record should contain the standard name, version, publication date, type (such as Data Exchange, Value), editor (and contact information), current status, status change history, purpose, rationale, change history, previous versions, upcoming releases, references to related standards and relationship to them (such as "supersedes", "superseded by", "deprecates", and "deprecated by"), reference implementations, and a list of projects and systems currently using the standard.
d34 1
a34 1
Team members carefully analyze several aspects of available standards before adopting them, such as its intrinsic quality as well as its level of maturity and deployment. Rich and updated metadata records that follow a standard profile facilitate the decision making process and thus are likely to increase adoption of standards. 
d44 1
a44 1
The status of a standard conveys its level of maturity and helps users decide whether to adopt a standard or not. Over time, TDWG is likely to make adjustments to its standards development processes, thus imposing changes to the standard statuses. Similarly, new kinds of standards can be created, thus requiring the list of standard types to be extended.
d50 1
a50 1
There is more information about a standard than is contained in its specification and metadata record. Additional contextual information can be gathered from the subgroup that produced it. Such information is helpful to users when deciding to adopt a standard or when they need to understand the reasoning behind a particular design decision. 
d60 1
a60 1
Each TDWG subgroup must have a dedicated area on the Website. Users must be able to locate subgroup area easily, either by using regular website navigation or via search engines. 
d62 1
a62 1
It is in the context of subgroups that TDWG standards are developed. Gathering subgroup information into individual areas within the website improves subgroup operation and makes communication within more effective.
d66 1
a66 1
Subgroup areas must contain updated information about the group, such as purpose, scope, recent and upcoming events, activities, call for reviews, milestones, schedule, drafts, standards the subgroup produced, related subgroups, resources, instructions to participants, members, convener, and contact information. 
d70 1
a70 1
Website should allow subgroup conveners and secretaries to edit information about their respective subgroups. Subgroup conveners and secretaries are responsible for keeping subgroup progress and efficient operation. It is in their best interest to keep subgroup information profile updated. If it is simple enough to use, the website can replace other non-standard means of communication convener use to advertise news, events, and calls for review. 
d88 1
a88 1
TDWG website should support new standards development process by providing easily accessible on-line documentation and tutorials, and by automating repetitive steps in the process.
d112 1
a112 1
The Website must be easy to use, intuitive, and therefore require a minimum effort to learn. Advanced computer users will benefit from ease of use and administration. Client-side requirements should be minimized, requiring only a moderately updated web browser.
d122 1
a122 1
The website must allow administrators to change overall navigation structure with minimal effort. Administrators must be able to add, remove, and rename pages to the website through the administration user interface. Administrators must be able to easily move entire hierarchy of pages as well. Changes to website navigation might require changes to content to maintain consistency.
d124 1
a124 1
TDWG organizational structure and goals will change over time and so the navigation structure must be capable of change as well. 
d138 1
a138 1
On the other hand, the website must be updated frequently to reflect latest news and developments regarding standards and subgroups activities. 
d150 1
a150 1
Many users find a website for the first time through a search engines such as Google and Yahoo. 
d234 1
a234 1
-- Main.RicardoPereira – 1 Nov 2005@


1.7
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130838671" format="1.1" version="1.7"}%
a79 6
---+++ R2.5. Flexible Document Development Area for Subgroups (Must)

The website must provide flexible tools to support subgroups in developing documents and specifications. 

(FixMe: elaborate)

d82 1
a82 1
---+++ R3.1. Documented Standards Development Process
d84 1
a84 1
One of the most important website requirements is to support the new TDWG Standards Development Process. This process is under active formulation by the TDWG Process Subgroup. For that reason, some of the requirements will be left open to accommodate demands imposed by the Process Subgroup. The Website group will rely on current knowledge of the new TDWG Process as it is being created. Such requirements will be clearly marked. Most of the other requirements will be based on previous assessment of best practices in use by TDWG itself and other standards development organizations and thus will be more stable. 
d86 1
a86 1
(FixMe: cut the small talk and improve style)
d88 1
a88 1
Regardless of any details of the new standards development process, TDWG website should support it by providing easily accessible on-line documentation and tutorials, and by automating repetitive steps in the process.
d92 1
a92 1
---+++ R3.2. Structured Review Process (Should)
d94 1
a94 1
TDWG should provide subgroups with effective on-line collaborative tools to assist with reviewing and refining drafts and standards. Such tools will enable editors to break down the complexity of the documents being reviewed, guide reviewers through a structured review process, and facilitate synthesis of comments made into a refined draft. The tools should require contributors to author and comment drafts within a well defined time frame.
d98 1
a98 1
---+++ R3.3. Defect Control (Should)
d102 1
a102 1
---+++ R3.4. Traceability of Design Decisions (Should)
d130 2
d136 1
a136 1
As one TDWG member put it, people need to see action to take action. Push technologies must be used to notify members of relevant events and to request action. The notifications should target appropriate parties as much as possible to avoid disturbing members. Notifications can be stratified into categories such as subgroup news, events, and requests, as well as community wide events and news about standards. Members must be able to subscribe or unsubscribe for individual notification streams easily.
d138 1
a138 3
On the other hand, pull technologies should focus on informing users about current and past activities, and how they can contribute.

(FixMe: elaborate)
d150 1
a150 1
TDWG Website should be optimized for search engine indexing.
d152 1
a152 1
(FixMe: elaborate)
d162 1
a162 1
The website must record usage and inform the user about it. The website must also describe how this information is to be used (see requirements R5.1).
d168 1
a168 1
The Website itself should also comply with several standards, like W3C CSS, HTML, and accessibility standards. Text should be as readable as possible. Users should be able to set font size.
d170 1
a170 1
(FixMe: elaborate)
d174 1
a174 1
The Website should provide mechanisms to support migration of contents to a new platform, in full, without loss of content or requiring rewriting of artefacts.
d176 1
a176 1
(FixMe: elaborate)
d192 1
a192 1
Users and administrators should be able to manage the Website remotely.
a195 2
(FixMe: elaborate)

d210 4
d234 1
a234 1
-- Main.RicardoPereira – 1 Nov 2005
@


1.6
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130527635" format="1.1" version="1.6"}%
d26 1
a26 1
The Website must serve and advertize its standards effectively. The Website must provide a comprehensive and up-to-date repository of TDWG standards. Users must be able to locate and download standard specifications easily, either by using regular website navigation or via search engines. 
d28 1
a28 1
Standards have a better chance of being adopted if they are well advertized, centralized, and easily accessible. 
d34 2
a39 2
Team members carefully analyse several aspects of available standards before adopting them. Besides analysing the standard intrinsic quality, team members are also concerned about its level of maturity, adoption, and deployment, as well as its relationships to other standards. Rich and updated metadata records facilitates this decision making process and thus are likely to increase adoption of standards. 

d42 1
a42 3
Standards must have an associated status, which can change in time. The list of standards statuses shall be defined by the Process Subgroup. Statuses coincide with standard maturity levels present on the standards track. Adopted standards must precede retired or superseded ones for presentation and accessibility purposes. The website should allow administrators to configure the list of standards types and statuses.

(FixMe: improve style)
d44 1
a44 1
The status of a standard conveys its level of maturity and helps users decide whether to adopt a standard or not. Over time, TDWG is likely to make adjustments to its standards development processes, thus imposing changes to the stantard statuses. Similarly, new kinds of standards can be created, thus requiring the list of standard types to be extended.
d62 2
d66 3
a68 1
Subgroup areas must contain updated information about the group, such as purpose, scope, recent and upcoming activities and events, milestones, schedule, standards the subgroup produced, drafts, resources, instructions to participants, members, convener and contact information. Such information enables subgroup members and interested parties to identify subgroup status.
d70 1
a70 1
Website should allow subgroup conveners and secretaries to edit information about their respective subgroups.
d84 1
a84 1
(FixMe: ellaborate)
d144 1
a144 1
(FixMe: ellaborate)
d154 1
a154 1
---+++ R4.7. Search Engine Friendlyness (Should)
d158 1
a158 1
(FixMe: ellaborate)
d176 1
a176 1
(FixMe: ellaborate)
d182 1
a182 1
(FixMe: ellaborate)
d202 1
a202 1
(FixMe: ellaborate)
d208 1
a208 1
Although TDWG may not present the profile of heavy targetted systems, there are automated worms and malicious software that can attack and bring down the website, disrupting members work and eroding users trust.
d238 1
a238 1
-- Main.RicardoPereira - 28 Oct 2005
@


1.5
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130500971" format="1.1" version="1.5"}%
d9 1
a9 1
This report provides requirements for an operational environment (called ‘The Website’ in this report) for the development and communication of its standards.
d26 1
a26 1
The Website must provide a comprehensive and up-to-date list of all TDWG standards. Users must be able to locate and download standard specifications easily, either by using regular website navigation or via search engines. 
d28 1
a28 1
*Motivation:* Standards are the most important deliverables that TDWG produces. ...
d32 1
a32 1
The website must provide accurate and up-to-date metadata record for each standard in the repository. Each metadata record should contain the standard name, version, publication date, type (such as Data Exchange, Value), editor (and contact information), current status, status change history, purpose, rationale, change history, previous versions, upcoming releases, references to related standards and relationship to them (such as “supersedes”, “superseded by”, “deprecates”, and “deprecated by”), reference implementations, and a list of projects and systems currently using the standard.
d34 1
a34 1
Some standard metadata fields, such as name, document number, date, type, and editor, must not change in time (except in case of errors) while others, such as upcoming releases, related standards, relationships, reference implementations, and projects using the standard, must be updated regularly.
d36 1
a36 1
For requirements on the standards contents and formats, please refer to the companion document *“TDWG Standards Documentation and Software Requirements.”*
d38 1
a38 1
*Motivation:* 
d40 1
a40 1
---+++ R1.3 Configurable Standards Statuses and Types (Must)
d42 1
a42 1
Standards must have an associated status, which can change in time. The list of standards statuses shall be defined by the Process Subgroup. Statuses coincide with standard maturity levels present on the standards track. More mature standards must take precedence over less mature ones, which in turn must take precedence over retired, superseded or archived standards for presentation and accessibility purposes.
d44 3
a46 1
The website should allow administrators to configure the list of standards types and statuses.
d52 1
a52 1
*Motivation:* ...
d54 1
a54 1
---+++ R1.5. Stable Web Address for Standards (Must)
d60 1
a60 1
---+++ R2.1. Dedicate Area for Subgroups on Website (Must)
d62 1
a62 1
Each TDWG subgroup must have a dedicated area on the Website. Users must be able to locate subgroup area easily, either by using regular website navigation or via search engines. Subgroups areas must present all standards it has produced. 
d68 2
d74 1
a74 1
---+++ R2.4. Stable Web Addresses for Subgroup Areas (Must)
d78 5
a82 1
*Motivation:*
d90 2
d96 1
a96 1
---+++ R3.2. Structured Review Process
d100 1
a100 1
Current TDWG subgroups are not reviewing drafts. This appears to be because the work is not broken into management tasks.
d102 1
a102 1
---+++ R3.3. Defect Control
d104 1
a104 1
TDWG should provide simple mechanisms for users of standards to report problems and comments. Such valuable information should be incorporated into a subgroup’s information system for subsequent evaluation.
d110 1
a110 1
*Motivation:* Traceability prevents defects late in the process and allows designers to trace the evolution from the original design requirements.
d124 19
a142 1
---+++ R4.3. Efficient Communication (Must)
d144 1
a144 1
The Website should support 'push' and 'pull' communication methods. Tools, techniques and procedures should be provided to keep subgroup members and users updated.
d146 1
a146 1
---+++ R4.4. Cross-Browser Cross-Platform Compatibility (Must)
d148 1
a148 1
Any moderately updated web browser must be able to render website pages properly. List of compatible browsers must include the most commonly used ones in each of the main computer platforms (Windows, Mac, Linux, and other flavors of UNIX). List of compatible browsers should be presented on the website.
d150 1
a150 1
Small rendering differences across browsers are allowed as long as it does not disrupt any website functions or disarrange its layout or graphical design.
d152 1
a152 1
---+++ R4.5. Search Engine Friendlyness (Should)
d156 1
a156 1
---+++ R4.6. Fast to Load (Should)
d158 1
a158 1
---+++ R4.7. Ability to Track Usage (Should)
d160 1
a160 1
---+++ R4.8. Flexible Navigation (Must)
d162 1
a162 1
The Website overall navigation structure should be easy to change to allow for changes in organizational structure, mission, and goals. After changes to navigation, minimal changes to contents might be required to maintain consistent terminology.
d164 1
a164 1
---+++ R4.9. Separation of Contents and Presentation (Must)
d166 1
a166 1
The Website graphical design should be decoupled from its contents. In other words, it should be easy to change the Website look without requiring rewriting of any content items. The Website should be driven by templates and style sheets. 
d168 1
a168 1
*Motivation:* Changes to organizational structure are common and desired …
d172 3
a174 1
The Website itself should also comply with several standards, like W3C CSS, HTML, and accessibility standards.
d180 1
a180 1
*Motivation:* In the future, changes in the organizational structure and function might require ...
d186 5
a190 1
---+++ R.4.13. No Broken Links (Could)
d192 1
a192 1
---+++ R.4.14. Shared Maintenance
d200 21
a220 1
---++ R5. Content Requirements
d222 1
a222 1
---+++ R5.1. Privacy Policy (Should)
d224 1
a224 1
---+++ R5.2. Website Structure Representing Organizational Structure (Should)
d226 1
@


1.4
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130493174" format="1.1" version="1.4"}%
d17 1
a17 1
---++ Requirements
d19 6
a24 1
---+++ R1. Standards Presentation and Distribution (Must)
d28 3
a30 1
Standards must be easily related to the subgroup that produced it.
d32 1
a32 1
The website must provide accurate and up-to-date metadata record for each standard on its repository. Each metadata record should contain the standard name, version, publication date, type (such as Data Exchange, Value), editor (and contact information), current status, status change history, purpose, rationale, change history, previous versions, upcoming releases, references to related standards and relationship to them (such as “supersedes”, “superseded by”, “deprecates”, and “deprecated by”), reference implementations, and a list of projects and systems currently using it.
d36 6
d46 5
a50 1
Standards specifications (downloadable file) and its information page should have stable web addresses regardless of changes in status to allow persistent references, book marking, and to preserve external linking. Each TDWG standard could be assigned a global unique identifier.
d52 1
a52 1
For requirements on the standards contents and formats, please refer to the companion document *“TDWG Standards Documentation and Software Requirements.”*
d54 1
a54 1
*Motivation:* One of TDWG most important goals… 
d56 1
d58 1
a58 1
---+++ R2. Dedicate Area for Subgroups on Website (Must)
d62 2
d66 2
d70 2
d76 1
d78 1
a79 1
---+++ 6. Documented Standards Development Process
d86 2
a87 1
---+++ 7. Structured Review Process
d92 1
a92 1
---+++ 8. Defect Control
d96 1
a96 1
---+++ 9. Traceability of Design Decisions
d100 3
a102 1
Traceability prevents defects late in the process and allows designers to trace the evolution from the original design requirements.
d104 1
a104 1
---+++ 10. Ease of Use
d108 1
a108 1
---+++ 11. Ease of Maintenance
d114 3
a116 1
---+++ 12. Shared Maintenance
d118 1
a118 1
Different users should be responsible for maintaining specific pages on the Website. Subgroup conveners or secretaries should have appropriate privileges to update and modify content items on their own subgroup areas. Content managers should be able to modify web pages and post news items. Users responsible for organizing annual or subgroup meetings should have access to modify the respective website sections. Administrators should have control over the entire website.
d120 1
a120 1
Users and administrators should be able to manage the Website remotely.
d122 1
a122 1
Website administration should be redundant to avoid bottlenecks.
d124 1
a124 1
---+++ 13. Efficient Communication
d126 1
a126 1
The Website should support 'push' and 'pull' communication methods. Tools, techniques and procedures should be provided to keep subgroup members and users updated.
d128 1
a128 1
---+++ 14. Content Migration
d130 1
a130 1
The Website should provide mechanisms to support migration of contents to a new platform, in full, without loss of content or requiring rewriting of artefacts.
d132 1
a132 1
---+++ 15. Flexible Navigation
d136 1
a136 1
---+++ 16. Separation of Contents and Presentation
d140 3
a142 1
---+++ 17. Compliance to Web Standards
d146 9
a154 1
---+++ 18. Internationalization
d156 1
a156 1
English is the official language of TDWG website. However, the Website should be able to accept and present content in other languages as well. 
d158 1
a158 1
It may be very difficult to include multi-language support if that feature is not included early on the development process. Besides, many CMS available today provide good multi-language support out-of-the-box.
d160 3
a162 1
The TDWG Process Subgroup will provide a more precise definition of requirements and usage of internationalization support. 
d164 18
a181 1
-- Main.RicardoPereira - 27 Oct 2005
@


1.3
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130462664" format="1.1" version="1.3"}%
d25 1
a25 1
The website must provide accurate and up-to-date metadata record for each standard on its repository. Each metadata record should contain the standard name, version, publication date, type (such as ), editor (and contact information), current status, status change history, purpose, rationale, change history, previous versions, upcoming releases, references to related standards and relationship (such as “supersedes”, “superseded by”, “deprecates”, and “deprecated by”), reference implementations, and a list of projects and systems currently using it.
d27 1
a27 1
(FixMe: Some standard metadata fields, such as name, document number, date, etc, must not change in time while others, such as upcoming releases, related standards, relationships, reference implementations, and projects using the standard, must be updated regularly).
d33 1
a33 1
Standards specifications (downloadable file) and its information page should have stable web addresses regardless of changes in status to allow persistent references and book marking and to preserve external linking. Each TDWG standard could be assigned a global unique identifier.
d40 1
a40 1
---+++ R2. Dedicate Area for Subgroups on Website
d42 1
a42 1
Each TDWG subgroup must have a dedicated area on the Website. The website must provide easy access to the list of subgroups. Users must be able to locate subgroup area easily, either by using regular website navigation or via search engines. Subgroups areas must present all standards it has produced. 
d44 1
a44 1
Subgroup areas must contain updated information such as purpose, scope, recent and upcoming activities and events, milestones, schedule, standards the subgroup produced, drafts, resources, instructions to participants, members, convener and contact information. Such information enables subgroup members and interested parties to identify subgroup status.
d46 1
a46 1
Subgroups must be assigned statuses that classify them according to their level of activity and requirements in terms of progress, production and scheduling. Subgroup statuses can change in time. The currently defined subgroup statuses are three: Task Group, Interest Group, Retired or Closed Group. More active groups must take precedence for presentation and accessibility purposes.
d48 1
a48 1
Subgroup home pages should have stable URLs regardless of possible changes in status (i.e. being retired or closed) to allow book marking and to preserve external linking. Information about less active, closed, or retired subgroups should be less prominent than active subgroups. 
d122 1
a122 1
-- Main.RicardoPereira - 27 Oct 2005@


1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130433613" format="1.1" version="1.2"}%
d17 1
a17 1
---++ Functional Requirements
d19 1
a19 2
---+++ 1. Comprehensive Standards Repository
TDWG should provide a comprehensive and up-to-date list of adopted standards up front on its Website. 
d21 1
a21 5
Benefits include:
 
   * Increased publicity and adoption of standards;
   * Increased participation in standards development;
   * Increased awareness of TDWG achievements.
d23 1
a23 1
---+++ 2. Easy Access to Standards
d25 1
a25 1
TDWG should provide easy access to its standards. Standards should have stable URLs regardless of possible changes in status (i.e. being retired or superseded) to allow book marking and to preserve external linking. Information about older standards should be less prominent.
d27 24
a50 2
---+++ 3. Related Information (Metadata)
Each standard should be accompanied by accurate and up-to-date metadata records. Those records would include: standards name, version, purpose, rationale, previous versions, related standards and upcoming releases. Metadata increases the likelihood of standards adoption.
a51 2
---+++ 4. Subgroup Information
TDWG subgroups should have a dedicated area on the Website. Each subgroup area should contain updated information such as purpose, scope, recent activities, milestones, standards, drafts, resources, and contact information. Such information enables subgroup members and interested parties to identify subgroup status.
a52 2
---+++ 5. Easy Access to Subgroup Information
The TDWG website should provide easy access to the list of active subgroups. Subgroup home pages should have stable URLs regardless of possible changes in status (i.e. being retired or closed) to allow book marking and to preserve external linking. Information about less active, closed, or retired subgroups should be less prominent than active subgroups. 
d122 1
a122 1
-- Main.RicardoPereira - 27 Oct 2005
@


1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="RicardoPereira" date="1130432304" format="1.1" version="1.1"}%
d13 4
d19 1
a19 2
---+++ 1. Comprehensive List of Standards

a32 1

d35 2
a36 1
---+++ 4. Easy Access to Subgroup Information
d38 1
a40 4
---+++ 5. Subgroup Information

TDWG subgroups should have a dedicated area on its website. Each subgroup area should contain updated information such as purpose, scope, recent activities, milestones, standards, drafts, resources, and contact information. Such information enables subgroup members and interested parties to identify subgroup status.

d42 1
d44 1
a44 1
TDWG standards should adhere to more strict development requirements. TDWG should provide automated support for the standards development process by providing easily accessible on-line documentation and tutorials, and by automating repetitive steps in the process.
a48 1

d67 15
a81 1
---+++ 11. Efficient Communication
d85 1
a85 1
---+++ 12. Content Migration
d87 1
a87 1
The Website should provide mechanisms to support migration of contents to a new platform, in full, without lost of content or requiring rewriting of artefacts.
d89 1
a89 1
Such a feature would reduce the risk of service disruption in case some of the software used in the Website becomes unsupported or TDWG adopts new technology to manage and communicate standards.
d91 1
a91 1
---+++ 13. Mirroring
d93 1
a93 1
The Website should support mirroring. It should be easy to move all Website contents to a separate server in case the main server becomes unavailable.
d95 1
a95 1
---+++ 14. Maintenance
d97 1
a97 1
The Website must be able to be maintained with minimal administrative effort. 
d99 1
a99 1
It is anticipated that TDWG resources may be limited. If so, any system developed to support TDWG activities must require minimal administrative effort to maintain effective 
d101 1
d103 1
d105 1
d107 1
@