RSS Aggregation and Syndication SOW v. 4.1.doc

DOC document 244 KB Posted

Attached to
RSS Aggregation and Syndication Services Federal contract opportunity
Solicitation number
GS-00V-08-PD-C-0090
Issued by
General Services Administration Office of the Administrator

About this file

Statement of work (SOW)

View the file

Other files for this federal contract opportunity

Other files attached to RSS Aggregation and Syndication Services, newest first.
File Type Posted
RSS Instructions to the Offerors.doc DOC document

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

SHAPE \* MERGEFORMAT

General Services Administration

Office of Citizen Services & Communications (OCSC)

RSS Aggregation/Syndication Services Statement of Work

1. OBJECTIVEs The objective of this solicitation is to establish an Indefinite Delivery/Indefinite Quantity contract for a hosted solution for USA.gov and its related web properties. The contract will cover the hosted solution and services related to continued maintenance and implementation of the solution. The solution will enable the government to acquire/aggregate content from RSS feeds accessible via the Internet and, conversely, to distribute the content using packages of information designed to enable users to easily package, store and utilize the content, e.g. using pre-packaged “widgets” or other similar devices. The government is requesting proposals for advanced content aggregation and syndication services that will complement and/or replace existing tools maintained by the USA.gov Technologies Division.

2. Scope

The scope of work detailed in the RFP includes a commercial solution offered as Software as a Service (SaaS), which employs a multi-tenant architecture, centralized feature updating, and the associated training, mentoring, consulting, and support required to meet or exceed the Government’s performance objectives and comply with Government security and usability constraints. Offerors shall elect to configure or extend their standard SaaS service provisions to meet the objectives and constraints described by the government. Any service configurations or extensions of the product must be documented in the proposal.

The Government anticipates the possibility of awarding multiple task orders under this contract to utilize the provided hosted solution for numerous websites and multiple displays of the aggregated data. Each task order will include one or more of the following items:

1. An expansion of the hosted service usage to accommodate natural growth in traffic

2. Professional Service hours to assist the Government in any needed preparation work (configuration, customization, etc…) of the hosted solution to meet the requirements of the individual task order

3. Professional training on use of the hosted service. This training may be virtual, on-line training, or it may require the Offeror to travel to Washington D.C. to provide this training onsite, as specified in the individual task order.

The first task order under this contract is expected to be awarded at the same time as the awarding of this contract. This task order will create, on news.usa.gov, an RSS aggregation and syndication service, as described in Attachment A. The Offeror shall include a technical and pricing proposal for this first task order.

Offerors may provide separate proposals for value added services beyond the basic requirements; however, they must be presented as separately priced options. The government’s source selection will be based on the solutions presented for the basic requirements as well as the solution provided for the first task order.

Future task orders may involve additional websites and/or additional content aggregation/distribution methods.

Future task orders will be similar in scope to the first task order, and may involve additional websites and/or additional content aggregation/distribution methods.

The government estimates the gross value of the entire contract (including the first and future task orders) will not exceed $600,000.

3. basic Requirements The government has a new requirement for an enterprise solution for (1) RSS-based aggregation and (2) content syndication, offered as a Software as a Service (SaaS), that can meet the initial project objectives yet also scale to meet the needs of future large scale projects.

Additionally, the solution must have multiple integration points, from a web-based user interface to allow users to create custom RSS Widgets, to a robust application interface (API) allowing government technical teams to integrate the solution at the web service level into enterprise portal applications.

The Basic Requirements, established by the key stakeholders for the content aggregation and syndication service are:

3.1. Content Aggregation / Syndication

At a minimum, the vendor shall provide

· A constantly updated library of RSS feeds, with the option to add new ones.

· Solution to be offered as a SaaS, with no software to install or manage

· Centralized web-based user interface for the creation, customization, and rollout of widgets.

· User accessible interfaces that are 508 compliant

· Ability to create widgets in HTML/Javascript or Flash

· A pricing model with associated billing detail

· Mitigated risk of denial of service or loss of Government owned data

· An administrative interface to maintain user accounts and configure the system

· A public facing page, built using API’s, to display syndicated content on a Government provided sub-domain (such as news.usa.gov)

· Allow content managers to select, categorize, and prioritize for display individual RSS items to syndicate

3.2. Integration

Integration capabilities including, at a minimum

· Available, documented, robust API

· Integration capability with major web analytics platforms

3.3. Reporting

· Standalone metrics reporting for tracking usage: visits, page views, and inheritance of widgets.

· Reporting dashboard for usage, visits, and page views of syndicated content and published page.

· Reporting showing inheritance from viral distribution.

3.4. Professional Services Consulting and Support

· Services to assist in configuring the product for the initial use (see Task Order 1, Attachment A)

· Best practices training, mentoring, help desk and support, including possible follow-on user communities.

· Engagement services to assist the Government in configuring the COTS product for specific projects.

4. Period and Place of Performance

The period of performance is for a one year base period and four (4) one year option periods. The base period is a full year beginning at award date and lasting twelve months.

Offerors shall designate the location of the proposed service hosting facilities, and document the procedures for Government representatives to enter the facilities for security surveillance.

Offerors shall work cooperatively with the Government to configure, initialize, and maintain the service to meet the requirements of each task order. This will require occasional co-location, or “virtual” co-location with personnel at the General Services Administration (GSA) facilities located in the DC metropolitan area, to include the GSA Central Offices at 18th and F Streets NW, Washington, DC., 20405.

5. Security requirements The Government and the Contractor will work in concert to establish an a Memorandum of Understand (MOU), following the guidelines and format of that provided in the National Institute of Standards and Technology (NIST) Special Publication 800-47, Security Guide for Interconnecting Information Technology Systems, Appendix A and B. The Government’s intent is to accept the Contractor’s commercial information security practices that are as functionally equivalent to those provided by NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems as can be expected for a commercial product. There is no requirement that any modifications will be made to the commercially offered product in terms of security.

References:

OMB Circular A-130, Appendix III, Security of Federal Automated Information Resources http://www.whitehouse.gov/omb/circulars/a130/a130appendix_iii.html NIST 800-47, Security Guide for Interconnecting Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-47/sp800-47.pdf NIST 800-53, Recommended Security Controls for Federal Information Systems http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf

6. constraints The Offeror shall address the following constraints in its proposal:

a. The Government’s schedule target is an operational capability sixty days after contract award.

b. The Offeror shall satisfy technical constraints in coordination with the COTR:

c. The use of persistent or third party cookies is prohibited.

d. The Offeror shall provide web browser accessible user interfaces.

e. The Offeror shall provide a service level agreement/assurance (SLA).

f. The Offeror shall provide in-classroom or online training for end users as required by each task order.

Section 508/Accessibility of Deliverables

All electronic and information technology (E&IT) procured through this contract must meet the applicable accessibility standards at 36 CFR 1194, unless an agency exception to this requirement exists. The 36 CFR 1194 implements Section 508 of the Rehabilitation Act of 1973, as amended and is viewable at http://www/access-board.gov. All deliverables will be Section 508 compliant. Complete technical descriptions are provided on the following website at http://www.section508.gov.

Where appropriate, the contractor shall indicate for each line item in the schedule whether each product or service is compliant or non-compliant with the accessibility standards at 36 CFR 1194. Further, the proposal must indicate where full details of compliance can be found (e.g., vendor’s website or other exact location).

To help GSA assess an electronic product or information technology’s conformity to Section 508 guidelines, offerors are requested to complete the following as part of their technical bid proposal:

1. Completion of the Voluntary Product Accessibility Template (VPAT): http://www.itic.org/archives/ITI%20Voluntary%20Product%20Accessibility%20Template.htm

2. Provide contact information (email and telephone number) for a technical representative who can respond to questions regarding accessibility and compliance. USA.gov will determine what constitutes compliant and accessible as driven by guidelines provided by the U.S. Access Board (http://www.access-board.gov) and the experience of our users.

Protection of Information The Contractor shall be responsible for properly protecting all information used, gathered, disclosed, or developed as a result of work under the contract. The Contractor shall also protect all government data by treating the information as sensitive. All information gathered or created under this contract should be considered as Sensitive But Unclassified (SBU) information. If contractor personnel must remove any information from the system they should protect it to the same extent they would their proprietary data and/or company trade secrets.

SECURITY, CONFIDENTIALITY, AND NONDISCLOSURE

1 The preliminary and final deliverables and all associated working papers and other material deemed relevant by the agency that have been generated by the Contractor in the performance of this project, are the property of the U.S. Government and must be submitted to the Project Manager at the conclusion of the contract.

2 All documents and data produced for this project are the property of the U.S. Government and cannot be reproduced, distributed, or retained by the contractor without express permission of the Government. All appropriate project documentation will be given to the agency during and at the end of this contract. The Contractor shall not release any information without the written consent of the Program Manager.

3 The Contractor shall provide the level of security normally afforded to users of their hosted solution. Data and access should be protected as would be expected for a commercial client at a minimum. The Contractor shall complete a Non-Disclosure Agreement.

7. Government Points of Contact

Contracting Specialist:

Emil P. Loczko, Jr.; Phone: 202-219-3476; Email: emil.loczko@gsa.gov Contracting Officer’s Technical Representative:

Carter Raines; Phone: 202-219-1438; Email: carter.raines@gsa.gov Security Officer:

Rich Kellett; Phone: 202-501-1650; Email: rich.kellett@gsa.gov

8. Procedures for payment

Billing and payment will be accomplished in accordance with the task order. The Contractor shall invoice thirty days after receipt of order. The COTR must receive a copy of the invoice and all supporting documentation before or at the same time as the GSA Finance Office.

Invoices are authorized for payment upon the Government’s receipt and acceptance of deliverables specified in the contract and the receipt of a valid invoice. Invoices must include the following:

(1).

Name and address of the Contractor

(2).

Invoice date, invoice number, and Task Order number (3).

Contract Number and GP Number and any contract line item numbers;

(4).

Description of the services provided including labor category, quantity, unit of measure, unit price and extended price of the item(s) delivered; period of service and/or dates that services were provided, etc.

(5).

Name and address of official to whom payment is to be sent;

(6).

Name, title, and phone number of person to be notified in event of defective invoice; and

(7).

Taxpayer Identification Number (TIN). The Contractor will include its TIN on the invoice only if required elsewhere in this contract.

Invoice submission to these locations:

Please Note: Failure to send both copies could delay your payment

The Contractor shall submit an original invoice for payment to GSA Financial Operations & Disbursement Division.

(1) GSA Financial Operations & Disbursement Division (Payment Office)

PO Box 419279

1500 E. Bannister Road

Room 1011

Kansas City, MO 64141

Telephone Number: (816) 926-7287

FAX Number: (816) 926-5189

A duplicate invoice with supporting documentation is sent to the Contracting Officer’s Technical Representative (COTR) who will confirm deliveries or performance made against the invoiced line items to ensure that the correct amounts have been billed and documents any price deductions. The COTR will then sign the invoice and complete the Receiving Report to authorize the GSA’s payment office to process payment of the invoices.

(2) Contracting Officer’s Technical Representative:

Carter Raines USA.gov technologies

Office of Citizen Services and Communications (OCSC)

1800 F Street, NW, Rm G-001

Washington, DC 20405

Telephone Number: (202) 219-1437 FAX Number: (202) 219-2408

E-mail: carter.raines@gsa.gov

BASIS OF AWARD AND EVALUATION FACTORS

Contract Award Basis

The Government will use a best value evaluation methodology. Award will be made on two factors – Technical and Cost. In the evaluation, technical is significantly more important than cost. While cost is not as important as technical, it does have significance to the Government. The Government will perform a cost/technical trade-off analysis in accordance with the above methodology and select the offer that provides the best value.

The Contractor’s proposal will be evaluated according to the factors shown below.

Factor 1 - Past Performance

Describe the experience and capability of your organization in conducting similar work. “Similar" is meant to convey similarity in subject matter, dollar value, duration, and complexity. Provide a summary of at least three recent similar contracts performed by your organization over the last three years. Include a brief description of the project, project title, contract number, period of performance, contract amount, client identification including agency or company name, and point-of-contact with e-mail and current telephone number. Contact information must be current and accurate.

Factor 2 - Technical Approach in meeting Basic Requirements The technical approach shall be simple, easy to read, and shall clearly and concisely describe project responsibilities and personnel, communication and coordination, scheduling of all tasks and subtasks, meetings, and deliverables. All staff needed to conduct the work and produce all required products and deliverables must be identified. In meeting deliverables, the Contractor shall elaborate on how they plan to measure their efforts to ensure the highest quality of performance.

Factor 3 - Technical Approach in meeting requirements of USA.gov News Task Order (Task Order 1) The technical approach shall be simple, easy to read, and shall clearly and concisely describe project responsibilities and personnel, communication and coordination, scheduling of all tasks and subtasks, meetings, and deliverables. All staff needed to conduct the work and produce all required products and deliverables must be identified. In meeting deliverables, the Contractor shall elaborate on how they plan to measure their efforts to ensure the highest quality of performance.

Attachment A: USA.gov News Task Order 1

Introduction

The Government is seeking a hosted service that will allow content managers to manage a news aggregation service that will be provided to visitors of the USA.gov web portal. The source for the news to be aggregated will be RSS feed items. The service provided shall allow content managers to select which news items are displayed to users from a list of managed RSS feeds. As a result, the system is envisioned to contain two parts:

· An administration interface to allow content managers to control the news items displayed to site visitors.

· A news display interface for site visitors to access the selected new items.

As these two parts are separate entities, their respective requirements are listed separately in this document.

Tasks Required

1. The selected vendor shall provide a hosted service (and any professional services required to customize or configure the hosted solution) that meets the requirements for the Administration Interface and the Public Interface outlined in this document within 60 days of the award date for the contract . The public interface will be used on the USA.gov Web Portal, but hosted on the vendor’s infrastructure. This public interface must be available at news.usa.gov. Before the service launches, the Government envisions working with the vendor to ensure the public interface has a user-interface that is acceptable to the Government in an iterative process. The use cases in this document are meant to assist the vendor in understanding how the Government envisions the service provided may operate.

It is expected that this task may require custom coding using the vendor’s APIs. If this is the case, it is assumed that the Government could replicate the application on its own web hosting infrastructure at a later date. The Offeror shall validate this assumption as part of their technical proposal.

2. The Government expects traffic of this service to be less than 15 million views a month for the public interface. The administrative interface will be accessed by no more than 10 content managers.

3. The selected vendor shall provide system training for a maximum of 15 content managers, at the General Services Administration, 1800 F Street, NW Washington DC 20405.

Administration Interface Requirements

User Management

Requirement

Number

Requirement Description
Importance
1.
The service provided shall allow administrators to create, delete, and edit users and user passwords.
High

Category Management

Requirement

Number

Requirement Description
Importance
2.
The service provided shall allow editors to add a category.
High
3.
The service provided shall allow editors to remove a category.
High
4.
The service provided shall allow editors to modify a category.
High
5.
The service provided shall allow editors to set a category’s display order.
Low

Feed Source Control Requirement

Number

Requirement Description
Importance
6.
The service provided shall collect government RSS feeds which are published on the World Wide Web on a regular cycle.
High
7.
The service provided shall allow managers to add and remove feeds.
High
8.
The service provided shall allow managers to select a default category for a feed's items.
High
9.
The service provided shall allow manager to assign each feed a title.
High
10.
The service provided shall allow managers to select a language of each feed.
Low

Display list of items from all feed sources Requirement

Number

Requirement Description
Importance
11.
The service provided shall allow content editors to assign one or more categories for each item.
High
12.
The service provided shall allow content editors to select items to be added to the news application, and displayed via the public interface.
High
13.
The service provided shall allow content editors to set a sort order for each item.
High
14.
The service provided shall allow the content editor to show all current items in the feeds, regardless of the item’s date.
High
15.
The service provided shall prevent simultaneous editing by two different users.
Low
16.
The service provided shall allow content editors to mark an item as "keep on top."
Low
17.
The service provided shall allow content editors to filter items displayed by selecting a specific language.
Low
18.
The service provided shall allow content editors to edit the item's description or title.
Low
18a.
This function shall require the approval of either a Manager or Administrator.
Low

Nonfunctional Requirement

Number

Requirement Description
Importance
19.
The service provided shall allow users to login remotely via the internet.
High
20.
The system provided shall be a hosted solution that is maintained and served from the provider’s facilities.
High
21.
The system must be available 99.9% of the year, excluding schedule maintenance windows. This must be guaranteed via a Service Level Agreement.
High

Public Display Requirements

Default display Requirement

Number

Requirement Description
Importance
22.
The service provided shall display a page that reveals all selected items in all categories, sorted in the following sort order: “keep on top” items, followed by date, followed by priority.
High
22a.
If a category is clicked, the service provided shall only display items in the selected category with proper pagination.
High
23.
The service provided shall publish selected items by category in a format suitable for syndication or distribution.
High
24.
The service provided shall allow users to sort items by category, date or source.
Low

Individual Item display Requirement

Number

Requirement Description
Importance
25.
The service provided shall display each item’s title.
High
26.
The service provided shall link each item’s title to the item’s URL.
High
27.
The service provided shall display each item’s description.
High
28.
The service provided shall provide pagination features for users to navigate items.
High
29.
The service provided shall display each item’s date.
High
30.
The service provided shall display each item’s source feed title.
Low

Nonfunctional Requirement

Number

Requirement Description
Importance
31.
The service provided shall provide a public interface that meets or exceeds Section 508 requirements, as verified by a completed VPAT
High
32.
The public facing solution must be accessible via a USA.gov subdomain.
High
33.
The system must be available 99.9% of the year, excluding schedule maintenance windows. This must be guaranteed via a Service Level Agreement.
High
34.
The system must support 7 – 15 million views a month, with the capability to accommodate increased traffic if necessary.
High
35.
The public interface must be compatible with the following platforms:

Windows: 98, 2000, NT and XP: Microsoft Internet Explorer, version 5.0 and higher; Netscape, version 7.0 and higher; Firefox, version 1.0; Mozilla, version 1.5 and higher; and Opera, version 7.0 and higher

Macintosh: OS X and Panther: Apple Safari, version 1.2; Netscape, version 7.0 and higher; Microsoft Internet Explorer, version 5.2 and higher; Firefox, version 1.0; Opera, version 6.0 and higher; Mozilla, version 1.6 and higher

Linux: Konqueror High.0.5 and higher; Mozilla 1.6 and higher; Netscape 7.0 High

Appendix A: Use Cases

These use cases are provided to give an example of how the Government envisions the provided services may function. The provided services do not have to function exactly as specified.

Please note that the use cases reflect all desired functionality and do not distinguish between “must have” and “important, but not critical requirements.

Administrative Interface Use Cases

ID/Name:
Log in
Summary:
An editor logs into the administration interface.
Postcondition:
User is logged into the administration interface
Actors:
Editor
Flow of Events:
1. An editor browses to the administrative interface login page.

2. The system displays fields to enter a username and password.

3. The editor enters their username and password and clicks submit.

4. The system verifies the username and password and displays the main administrative interface to the user. It includes a list of news items available to select to show site visitors (downloaded at the time of) and a link to enter the category management function. There is also an option to show English or Spanish news.

Alternatives:
· At step 4, if the editor enters an incorrect username/password pair, the system will return to the login form showing an error message indicating the username/password pair couldn’t be verified.

· At step 4, if the editor is a system manager, he/she should be able to access the feed management function.

· At step 4, if the editor is a system administrator, he/she should be able to access the user management function.

· At step 4, if the editor is a system manager, he/she should also see a list of edited news items waiting for approval prior to be shown to site visitors with “approve edits” and “reject edits” buttons next to each item.

ID/Name:
Maintain users
Summary:
An administrator maintains the list of users that are able to use the administration interface.
Postcondition:
An administrator updated the access control list (the list of users) used for access to the administrative interface.
Actors:
Administrator
Includes:
Log in
Flow of Events:
1. The administrator logs in via the included use case (4.1.1).

2. The administrator selects the “Manage users” function from the functions menu.

3. The system displays a page presenting all of the current users (in ascending-alphabetical order). The page should allow the administrator to add a new user, edit an existing user, and remove an existing user. Additionally there should be a way to return to the main administrative interface.

4. The administrator selects to add a new user.

5. The system displays a page asking for the user’s login name, password, and optional groups.

6. The administrator enters the required information and presses the “save” button.

7. The system saves the new user and returns the administrator to the page that shows all current users (with the new user displayed in the list of users). The new user is able to login to the administration interface.

Alternatives:
· At step 4, if the administrator selects a current user to edit, the flow continues as follows:

5. The system displays a page showing the selected user’s login name, password, and optional groups. All of the fields are editable.

6. The administrator modifies the user’s information as desired and presses the “save” button.

7. The system updates the user’s information and returns the administrator to the page that shows all current users (with the user’s modified information displayed in the list of users). The user whose information was modified is now able to login to the administrative interface with the updated settings.

· At step 4, if the administrator selects a current user to remove, the flow continues as follows:

5. The system displays a confirmation dialog to confirm the deletion.

6. The administrator clicks the “confirm” button.

7. The system removes the user’s information and returns the administrator to the page that shows all current users (with the selected user removed). The removed user is now no longer able to login to the administrative interface.

· At step 6 above, if the administrator clicks the “cancel” button, the system does not remove the user’s information and returns the administrator to the page that shows all current users.

ID/Name:
Maintain categories
Summary:
An editor updates the categories displayed in the administrative interface and the news display interface.
Postcondition:
An editor updated the available categories.
Actors:
Editor
Includes:
Log in
Flow of Events:
1. The editor logs in via the included use case (4.1.1).

2. The editor selects the “Manage categories” function from the functions menu.

3. The system displays a page presenting all of the current categories (in ascending-alphabetical order). The page should allow the editor to add a new category, edit an existing category, and remove an existing category. Additionally there should be a way to return to the main administrative interface.

4. The editor selects to add a new category.

5. The system displays a page asking for the new category’s name and the category display order.

6. The editor enters the category’s information and presses the “save” button.

7. The system saves the new category and returns the editor to the page that shows all current categories (with the new category displayed in the list of categories). Items and feeds are now able to be associated with the new category.

Alternatives:
· At step 4, if the editor selects a current category to edit, the flow continues as follows:

5. The system displays a page showing the selected category’s name and the category’s display order. Both fields are editable.

6. The editor modifies the category’s information as desired and presses the “save” button.

7. The system updates the category’s name and the sort order and returns the editor to the page that shows all current categories (with the modified category name displayed in the list of categories). Any item or feed associated with the old name becomes automatically associated with the new name.

ID/Name:
Maintain feed list
Summary:
A manager controls the list of feeds that populate the news items an editor can select from.
Postcondition:
A manager updated the feeds used to select news items from.
Actors:
Manager
Includes:
Log in
Flow of Events:
1. The manager logs in via the included use case (4.1.1).

2. The manager selects the “Manage feeds” function from the functions menu.

3. The system displays a page presenting all of the current feeds (in ascending-alphabetical order). The page should allow the manager to add a new feed, edit an existing feed, and remove an existing feed. Additionally there should be a way to return to the main administrative interface

4. The manager selects to add a new feed.

5. The system displays a page asking for the feed’s URL, title, language, and default category.

6. The manager enters the required information and presses the “save” button.

7. The system saves the new feed and returns the manager to the page that shows all current feeds (with the new feed displayed in the list of feeds). The next time the list of selectable news items is updated, items from the new feeds will be displayed.

Alternatives:
· At step 4, if the manager selects a current feed to edit, the flow continues as follows:

5. The system displays a page showing the selected feed’s URL, title, language, and default category. All of the fields are editable.

6. The manager modifies the feed’s information as desired and presses the “save” button.

7. The system updates the feed’s information and returns the manager to the page that shows all current feeds (with the feed’s modified information displayed in the list of feeds). The next time the list of selectable news items is updated, items from the updated feed information will be displayed.

ID/Name:
Select items
Summary:
An editor selects the news items to be displayed to site visitors using the news display interface.
Postcondition:
An editor updates the list of news items that site visitors will see when they visit the news site.
Actors:
Editor
Includes:
Log in
Flow of Events:
1. The editor logs in via the included use case (4.1.1).

2. The editor selects items to be included for site visitor’s to view. The editor can also select one or more categories to associate with an item (the default category assigned the source feed is already selected), set a sort order for the item, and decide if the item should stay on top. After the editor is complete, the user presses the “save” button.

3. The system updates the items that a site visitor will see. Checked items are stored and will be shown to site visitors. Unchecked items will be removed. These unchecked items will not be shown to site visitors. The system returns the editor to the administrative interface.

Alternatives:
· At step 2, the editor can press an “edit’ button next to an item. If the editor presses the button, the flow continues as follows:

3. The system opens a screen where the editor can edit the item’s title and description.

4. The user enters their edits, and presses the “save” button.

5. The system returns the editor to the administrative interface with the original, unedited item in the items list. The edited version is in the “items waiting for approval” section of the administrative interface.

· At step 3, if the system detects the editor trying to save an item that has already been saved, it will display an error message and return the editor to the list of items.

ID/Name:
Approve edited items
Summary:
A manger approves a news item edited by an editor so that it can be displayed to site visitors using the news display interface.
Postcondition:
A manager approved a news item that an editor had previously edited.
Actors:
Manager
Includes:
Log in
Flow of Events:
1. The manager logs in via the included use case (4.1.1). The manager see’s at the top of the screen a list of edited items, awaiting approval. Next to each item is an “approve edits,” “modify edits” and “reject edits” button. It also displays the item’s original title and description. The item appears with ‘Original Text” and “Suggested Edits” clearly marked.

2. The manager presses the “approve edits” button for an item that he/she wants to approve for viewing by site visitors.

3. The system updates the items that a site visitor will see. Checked items are stored and will be shown to site visitors. The system returns the manager to the administrative interface with the item removed from the list of edited items waiting for approval.

Alternatives:
· At step 2, if the manager presses the “reject edits” button, the system displays a confirmation dialog.

If the user confirms the rejection, the system removes the item and it will not be shown to site visitors and removed from the system. The system returns the manager to the administrative interface with the item removed from the list of edited items waiting for approval.

· At step 1, if the manager edits the item, and saves the edits, the system will save the edited item to be shown to site visitors.

News Display Interface Use Cases

ID/Name:
View general news
Summary:
A site visitor displays the news of the day.
Postcondition:
A site visitor examines the general news of the day.
Actors:
Site visitor
Flow of Events:
1. A site visitor browses to the English start page of the news display interface on USA.gov.

2. The system shows the latest English items in all categories, with appropriate pagination options provided. It also shows links to the English categories in the system, as well as options to syndicate the newest items to RSS readers and/or widget-based websites (such as iGoogle). The items are displayed in the following order: items marked “keep on top”, followed by the latest date, and finally followed by sort order.

Items should display their title, URL, description, and source feed title.

Alternatives:
· At step 1, the user may browse to the Spanish start page. If so, the interface will be in Spanish, and only Spanish feeds and categories will be presented.
ID/Name:
View news by category
Summary:
A site visitor chooses to see the news of the day from a specific category.
Postcondition:
A site visitor examines the news of a specific category.
Actors:
Site visitor
Flow of Events:
1. A site visitor browses to the English start page of the news display interface on USA.gov.

2. The system shows the latest English items in all categories with appropriate pagination options provided. It also shows links to the English categories in the system, as well as options to syndicate the newest items to RSS readers and/or widget-based websites (such as iGoogle).

3. The site visitor clicks a category that interests them.

4. The system shows the latest items in the selected category. It also shows links to the English categories in the system, as well as options to syndicate the newest items to RSS readers and/or widget-based websites (such as iGoogle). The category currently being viewed is highlighted on the page. The items are displayed in the following order: items marked “keep on top”, followed by the latest date, and finally followed by priority.

Items should display their title, URL, description, and source feed title.

Alternatives:
· At step 1, the user may browse to the Spanish start page. If so, the interface will be in Spanish, and only Spanish feeds and categories will be presented.

� Each requirement has been assigned an importance of either “low” or “high”. Technical proposals must include how the Offeror would support each requirement. However, requirements denoted as being of “low” importance will be evaluated as such by the Government.

PAGE

RFP GS-00V-08-PD-C-0090

File details come from the government source that posted it. Updated .