Marketing Requirements Document

Market Requirements Document

for

“File Sharing Community”

version 1.0

Table of Content

l Project Overview

¡ Project Statement

¡ Project Objectives

¡ Project Definition

l Product Requirements

¡ Brief Statements about Requirements

¡ Join/Leave the Community

¡ Directory Services and Information Exchange

¡ Commands – Query, Search, and Fetch

¡ The Configuration File

¡ Interactive Mode

¡ Batch Mode (Silent Mode)

Project Overview

Project Statement

File sharing community is designed for users who want to share their files with other users on the Internet.

Project Objectives

The main objective of file sharing community is to provide facilities for users to easily exchange their files on the Internet. Whenever a user joins the file sharing community, he/she can advertise files he/she wants to share with other members, query other members’ shared files, search for specific files, fetch files from specified locations, and so on.

Project Definition

Product Name	File Sharing Community
Version	1.0
Platforms	l Win32 platforms: Windows 98 and Windows 2000, and l Unix-like platforms: Linux
Functional Description	l Community Member Exploring l File Sharing l Directory Service and Information Cache l Batch and Interactive Mode

Product Requirements

Brief Statements about Requirements

1. Join/Leave the Community

We assume that there is only one file sharing community in the world. A user who wants to join/leave the community only needs to start/stop a process (we call this process “FSC daemon” hereafter). Need no authentication when joining the community. After joining the community, the new community member must be able to explore other members in the community.

2. Directory Services and Information Exchange

In order to provide shared file and membership information to other members, there must be a storage (also called “cache”, or “database” in this document) accommodating file information with each community member. The entity that maintains the storage is called the directory service (or DS for brevity). Different directory services could exchange their information so that query/search time might be reduced.

3. Commands

Any member in the community could issue at least three commands: query, search, and fetch. He/she could ask other members to provide shared file information (query), find out the locations of specific files (search), or get other members’ shared files (fetch).

4. The Configuration File

FSC daemons are controlled by configuration files. For example, the files to be shared, the timeout value of each command, … etc. might be defined in configuration files.

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

Users should be able to join/leave the community, issue commands, etc. in both batch and interactive modes. In batch mode, commands are written in a batch file in advance. The FSC daemon will then silently issue commands specified in the batch file. In interactive mode, users could issue commands from a user interface. Results of issued commands should be displayed on the UI after they are completed.

1.0 Join/Leave the Community

The File Sharing Community is composed of hosts spread all over the Internet and there is only one File Sharing Community in the world. When a user wants to join/leave the community, he/she only needs to start/stop the FSC daemon.

ID#	Feature	Priority	Target Version	Current Status
1.1	Join the community A host joins the community after the FSC daemon starts up. Once the FSC daemon starts up, the host becomes a member of the File sharing community.	High	1.0	Incomplete
1.2	Explore other community members After joining the community, community members should be able to automatically explore other members in the community.	High	1.0	Incomplete
1.2.1	A Master Query Site is the member that is first contacted when a host joins the community. Each member has a unique master query site.	High	1.0	Incomplete
1.2.2	Every member could be other members’ (including itself) Master Query Site.	High	1.0	Incomplete
1.2.3	A Master Query Site could provide membership information to other community members.	High	1.0	Incomplete
1.3	Leave the Community A host leaves the community after its FSC daemon terminates.	High	1.0	Incomplete

2.0 Directory Service and Information Exchange

Each host in the community should provide a directory service for other members to inquire. The directory service maintains at least two kinds of information: shared file information and membership information. However, a community member could be configured not to provide such information due to performance concerns.

ID#	Feature	Priority	Target Version	Current Status
2.1	Shared File Information	High	1.0	Incomplete
2.1.1	The directory service maintains information about local and remote shared files.	High	1.0	Incomplete
2.1.2	Local shared file information should be 100% accurate while remote shared file information could be inaccurate.	High	1.0	Incomplete
2.1.3	Storage for inaccurate information about remote files is called the File Information Cache. The cache size is limited and should be configurable. Obsolete information will be replaced when the cache is full and there is information to be updated.	High	1.0	Incomplete
2.1.4	Information about remote shared files could be the result of query, search, or fetch commands. After a command is executed and finished successfully, the results of the command will be stored for later uses.	High	1.0	Incomplete
2.2	Membership Information	High	1.0	Incomplete
2.2.1	The directory service should maintain information about members currently involved in the community. However, this information might be inaccurate.	High	1.0	Incomplete
2.2.2	A member could provide or refuse to provide membership information to other members. This should be configurable.	High	1.0	Incomplete
2.2.3	Storage for membership information is called the Membership Information Cache. The cache size is limited and should be configurable.	High	1.0	Incomplete
2.3	Information Exchange Directory services on different hosts could actively/passively exchange information.	High	1.0	Incomplete
2.3.1	Passive mode: The directory service updates its information according to results of successful commands. This mode is always on.	High	1.0	Incomplete
2.3.2	Active mode: In addition to passive mode, directory services could exchange their information periodically. This mode could be on/off.	High	1.0	Incomplete
2.3.2.1	When active mode is on, the time period that the directory service actively multicasts should be configurable.	High	1.0	Incomplete
2.3.2.2	Community members could ignore/accept information actively sent by other directory services. This should be configurable.	Medium	1.0	Incomplete

3.0 Commands

A user can issue at least three kinds of commands: query shared files of a community member, search files whose filenames fit the specified pattern, and fetch a file. All shared files of a community member are placed under a directory, called the FSC root directory. There might be subdirectories under this root directory. Files are visible to other members if and only if they are placed under the FSC root directory.

ID#	Feature	Priority	Target Version	Current Status
3.1	Query A community member could query shared files of another member.	High	1.0	Incomplete
3.1.1	When a member receives query requests from other members, it should send information about its local shared files back.	High	1.0	Incomplete
3.1.2	There should be a default timeout value for query commands. This timeout value should be configurable.	High	1.0	Incomplete
3.1.3	There should be a maximum count for the query results. This maximum count should be configurable.	High	1.0	Incomplete
3.2	Search A community member could search the community for specific file patterns.	High	1.0	Incomplete
3.2.1	The filename or file pattern 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
3.2.2	When a member receives a search request, it should search its cache for the specified file pattern, return the search result back to the source (the host that originally issued the search request), and forward the search request to some other community members.	High	1.0	Incomplete
3.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
3.2.4	There should be a default timeout value for search commands. This timeout value should be configurable.	High	1.0	Incomplete
3.2.5	There should be a maximum count for the search result. This maximum count should be configurable.	High	1.0	Incomplete
3.3	Fetch A community member could fetch a file from other member given the location of the file is known, the file still exists, and the member who owns the file is alive.	High	1.0	Incomplete
3.3.1	If not specified, the fetched files are stored in a predefined directory. This directory should be configurable.	High	1.0	Incomplete
3.3.2	If one fails to fetch a file, the reason why the file cannot be fetched should be recognized. (For example, the file does not exist, destination unreachable, etc.)	Medium	1.0	Incomplete
3.3.3	There should be a default timeout value for fetch commands. This timeout value should be configurable.	High	1.0	Incomplete

4.0 Configuration Files

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

ID#	Feature	Priority	Target Version	Current Status
4.1	Configuration files are human readable text files that contain name-value pairs of configurable settings.	High	1.0	Incomplete
4.2	Configuration files are read only when the FSC 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
4.3	Configuration files could be generated or modified with general-purpose text editors.	High	1.0	Incomplete
4.4	Configuration files could be generated or modified from UI.	Medium	1.0	Incomplete
4.5	Configuration files are placed in the current working directory of the FSC daemon.	High	1.0	Incomplete

5.0 Interactive mode

There should be a UI for users to join/leave the file sharing community, to issue commands, to change configuration, etc. The results of finished commands, community member exploration, etc., should also be displayed on the UI.

ID#

Join the community

Explore other community members

Leave the Community

Shared File Information

Membership Information

The directory service should maintain information about members currently involved in the community. However, this information might be inaccurate.

A member could provide or refuse to provide membership information to other members. This should be configurable.

Storage for membership information is called the Membership Information Cache. The cache size is limited and should be configurable.

Information Exchange

Passive mode: The directory service updates its information according to results of successful commands. This mode is always on.

Active mode: In addition to passive mode, directory services could exchange their information periodically. This mode could be on/off.

When active mode is on, the time period that the directory service actively multicasts should be configurable.

Community members could ignore/accept information actively sent by other directory services. This should be configurable.

Query

When a member receives query requests from other members, it should send information about its local shared files back.

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

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

Search

The filename or file pattern 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 request, it should search its cache for the specified file pattern, return the search result back to the source (the host that originally issued the search request), and forward the search 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 commands. This timeout value should be configurable.

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

Fetch

A community member could fetch a file from other member given the location of the file is known, the file still exists, and the member who owns the file is alive.

If not specified, the fetched files are stored in a predefined directory. This directory should be configurable.

If one fails to fetch a file, the reason why the file cannot be fetched should be recognized. (For example, the file does not exist, destination unreachable, etc.)

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

The filename or file pattern 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.)