Marketing Requirements Document

Market Requirements Document

for

“Resource Sharing Community”

version 1.0

Table of Content

l Project Overview

¡ Project Statement

¡ Project Objectives

¡ Project Definition

l Product Requirements

¡ Brief Statements about Requirements

¡ Backward compatible with FSC

¡ RSC Commands – queryService, searchService, and outsourceJob

¡ The Configuration File

¡ Interactive Mode

¡ Batch Mode (Silent Mode)

Project Overview

Project Statement

Resource sharing community (RSC for brevity) is designed for users who want to share their resources (both information and computation power) with other users on the Internet. In RSC a member shares its resources to the community by providing “services.” For example, a member could share its files by providing a “file sharing” service. Note that RSC must be backward compatible with FSC.

Project Objectives

The resource sharing community is basically a superset of the file sharing community. The main objective of this project is to extend the capability of FSC to fully utilize resources on the Internet. That is, in addition to sharing files to other members, a community member can also contribute its computation power to the community.

Project Definition

Product Name	Resource Sharing Community
Version	1.0
Platforms	l Win32 platforms: Windows 2000 l Unix-like platforms: Linux
Functional Description	l Backward compatible with FSC l Support more resource types l Share resources by providing services

Product Requirements

Brief Statements about Requirements

1. Backward compatibility

Since the resource sharing community is also a file sharing community, all functions/features supported in FSC should also be supported in RSC. To be more precise, FSC is just a special RSC that provides only the “file sharing” service.

2. Commands

In addition to commands supported by FSC, RSC support more commands that enable information and computation power of a community member to be shared. A community member can query some other members for its shared resources (queryService). It can also search the community for a specific resource (searchService). Moreover, it can ask other members to do its jobs (outsourceJob).

3. The Configuration Files

To provide new services to the community, a member must have some ways to declare its services. In RSC shared resources could be declared in configuration files. If a member does not explicitly declare its services in configuration files, it provides the “file sharing” service only.

4. Interactive Mode vs. Batch Mode (Silent Mode)

A user can issues commands from either a user interface (interactive mode) or script files (batch mode).

1.0 Backward Compatibility

The resource sharing community is a superset of the file sharing community. Therefore, all FSC features should remain the same in RSC.

ID#	Feature	Priority	Target Version	Current Status
1.1	Backward Compatible with FSC All features in FSC are also supported in RSC. Commands in FSC should remain the same in RSC. Resources are shared by means of services; file sharing is treated as a default service in RSC.	High	1.0	Incomplete
1.2	Join/Leave the Community The behavior of a member when join/leave the RSC should be compatible with that of FSC.	High	1.0	Incomplete
1.3	Directory Service and Information Exchange In addition to shared file information and membership information maintained by the directory service, there must be a third kind of information: the shared service information.	High	1.0	Incomplete
1.4	FSC Commands Query, search, and fetch commands remain and behave the same in RSC.	High	1.0	Incomplete
1.5	FSC Configuration Files All configurable parameters in FSC remain effective in RSC.	High	1.0	Incomplete
1.6	FSC Batch Mode FSC script files should work in RSC. That is, the RSC interpreter recognizes FSC script files.	High	1.0	Incomplete

2.0 Commands

In addition to commands defined in FSC, users can issue at least the following kinds of commands: query services provided by a community member, search the community for a specific service, and outsource its jobs to community members who provide services for solving those jobs.

ID#	Feature	Priority	Target Version	Current Status
2.1	Query Service A community member could query services provided by some other member.	High	1.0	Incomplete
2.1.1	When a member receives a query service request from another member, it should send information about its services back to the requester.	High	1.0	Incomplete
2.1.2	There should be a default timeout value for the query service commands. This timeout value should be configurable.	High	1.0	Incomplete
2.1.3	There should be a maximum count for the query service result. This maximum count should be configurable.	High	1.0	Incomplete
2.2	Search Service A community member could search the community for a specific service.	High	1.0	Incomplete
2.2.1	The service name to be searched could contain wild card characters ‘’ and ‘?’. (‘’ matches zero or more occurrences of any character while ‘?’ matches zero or 1 occurrence of any character.)	High	1.0	Incomplete
2.2.2	When a member receives a search service request, it should search its cache for the specified service name, return the result back to the source (the host that originally issued the search request), and forward the request to some other community members.	High	1.0	Incomplete
2.2.3	The search results received from different members should be merged. There should be no redundant information in the merged result.	Medium	1.0	Incomplete
2.2.4	There should be a default timeout value for search service commands. This timeout value should be configurable.	High	1.0	Incomplete
2.2.5	There should be a maximum count for the search service result. This maximum count should be configurable.	High	1.0	Incomplete
2.3	Outsource Jobs A community member can ask other members for doing its jobs. Every job could be done by one (or more) service.	High	1.0	Incomplete
2.3.1	There should be a default timeout value for outsource command. This timeout value should be configurable.

3.0 Configuration Files

Each time the RSC daemon starts up, it reads the configuration files and acts as what these files instruct.

ID#	Feature	Priority	Target Version	Current Status
3.1	Configuration files are human readable text files that contain name-value pairs of configurable settings.	High	1.0	Incomplete
3.2	Configuration files are read only when the RSC daemon starts up. Modifying the contents of configuration files while the FSC daemon is running will not affect the behavior of the daemon.	High	1.0	Incomplete
3.3	Configuration files could be generated or modified with general-purpose text editors.	High	1.0	Incomplete
3.4	Configuration files could be generated or modified from UI.	Medium	1.0	Incomplete
3.5	Configuration files are placed in the current working directory of the RSC daemon.	High	1.0	Incomplete
3.6	All configurable parameters defined in FSC remains effective in RSC.	High	1.0	Incomplete
3.7	“File sharing” is a default service provided by RSC. For other services, a community member has to explicitly declare its services in configuration files.	High	1.0	Incomplete

4.0 Batch Mode (Silent Mode)

Users can issue RSC commands from script files. The syntax of the RSC script language should be consistent and backward compatible with that of FSC. It is also noted that the relationship among commands can be categorized into dependent commands and independent commands. Dependent commands should be issued as the order they are written while independent command could be issued in parallel. The RSC script language should support command scheduling.

#ID	Feature	Priority	Target Version	Current Status
4.1	Script Language	High	1.0	OK
4.1.1	Extend the existing FSC scripting language for RSC.	High	1.0	Incomplete
4.1.2	Independent commands can be issued concurrently.	High	1.0	Incomplete
4.1.3	The syntax of RSC script language should be consistent with that of the FSC.	High	1.0	Incomplete
4.1.4	Users can issue shell commands from script files.	High	1.0	Incomplete
4.2	Interpreter	High	1.0	Incomplete
4.2.1	The interpreter should be able to detect syntax errors of script files. (“Batch files” and “script files” are interchangeable terms in the context.)	High	1.0	Incomplete
4.2.3	The interpreter translates a script file into commands and then instructs the RSC daemon to issue those commands.	High	1.0	Incomplete

5.0 Interactive Mode

Since RSC is a superset of FSC, the UI of RSC should be at least as powerful as that of FSC. Moreover, according to the “Resource Sharing Community”, we promote some medium or low priority requirements to high and add some more requirements.

#ID	Feature	Priority	Target Version	Current Status
5.1	Grouping	High	1.0	Incomplete
5.1.1	Users can partition entities (community members, file locations, …etc.) displayed on UI into different groups. A group contains zero or more displayed entities.	High	1.0	Incomplete
5.1.2	Users can issue commands to a group from UI.	High	1.0	Incomplete
5.1.3	Users can add new entities into a group from UI.	High	1.0	Incomplete
5.1.4	Users can remove entities from a group from UI.	High	1.0	Incomplete
5.2	Display Workload	High	1.0	Incomplete

Backward Compatible with FSC

Join/Leave the Community

Directory Service and Information Exchange

FSC Commands

FSC Configuration Files

FSC Batch Mode

Query Service

When a member receives a query service request from another member, it should send information about its services back to the requester.

There should be a default timeout value for the query service commands. This timeout value should be configurable.

There should be a maximum count for the query service result. This maximum count should be configurable.

Search Service

The service name to be searched could contain wild card characters ‘*’ and ‘?’. (‘*’ matches zero or more occurrences of any character while ‘?’ matches zero or 1 occurrence of any character.)

When a member receives a search service request, it should search its cache for the specified service name, return the result back to the source (the host that originally issued the search request), and forward the request to some other community members.

The search results received from different members should be merged. There should be no redundant information in the merged result.

There should be a default timeout value for search service commands. This timeout value should be configurable.

There should be a maximum count for the search service result. This maximum count should be configurable.

Outsource Jobs

A community member can ask other members for doing its jobs. Every job could be done by one (or more) service.

There should be a default timeout value for outsource command. This timeout value should be configurable.

Feature

Script Language

Interpreter

Feature

Display Workload

The service name to be searched could contain wild card characters ‘’ and ‘?’. (‘’ matches zero or more occurrences of any character while ‘?’ matches zero or 1 occurrence of any character.)