Webclient Requirements Specification Version 1.7

Review Status: version 1.3 formally reviewed

NOTE: This document specifies the ideal webclient, not the current webclient or even a future webclient. That is, not everything in here will be implemented, but nothing will be implemented that isn't in here. In other words, the actual implementation will be a proper subset of what is specified here.

post feedback to netscape.public.mozilla.java with the subject webclient spec

Sections changed since the previous version of the document are bracketed like this.

Table of Contents

  1. Introduction
    1. How the software fits into the larger system
    2. Overall description
    3. Software Project Constraints
  2. Detailed Problem Description
    1. Information Flow
    2. System Interface Description
  3. Functional Description
    1. Functional Partitioning
      1. webclient API
      2. Event System
  4. Behavioral Description
    1. System States
    2. Events and Actions
  5. Validation Criteria
    1. Performance Bounds
    2. Special Considerations
  6. Appendices
    1. Other Projects Similar to This One
    2. Differences from the Current Implementation
    3. People who have worked on this document


Detailed Problem Description

Functional Description

Behavioral Description

Validation Criteria





Here is a checklist for verifying that your requirements specification
is complete:

The requirements specification should:

describe the flow and content of information

elaborate all software functions

describe all events that affect the system

uncover design constraints

show evidence and conclusions from research on prior projects that
addressed the same problem as is being addressed in the specification.
Specifically, the problems with each prior project should be listed.

specify performance constraints

serve as the basis for a Preliminary User's Manual.

describe the design principles that will be adhered to, for example,
design for maintainability

describe the benefits of a successful implementation

describe the environment in which the software is to run.

be a cognitive model, that is, it must be described in the user domain,
with user terms.

separate functionality from implementation

be useful for validating the correctness of an implementation

be tolerent of incompleteness and be augmentable

be modular and loosely coupled

Ed Burns
Last modified: Thu Aug 24 18:16:44 PDT 2000