Design Overview

-- Standard program definition documentation (to ensure commonality of the "story" associated with the program)

-- "Quad" chart (which provides a brief synopsis of the program for senior leaders)

-- Program status, including identification of the critical path and assessment of progress using earned value reporting

-- Program operational and engineering requirements definition and tracing

-- Engineering documentation library, which will contain information such as engineering white papers and documentation of studies/critical experiments, results of architectural and design trade studies, and the specifications that will be used to guide development

-- Standard operating policies, such as quality control and configuration management

-- Listing of individuals assigned to the project, showing their location and contact information and identifying the specific skills and experience these people bring to the project

-- Links to information pertaining to our standard development tools (vendor web sites, third-party help providers, and USENET newsgroups)

-- Access to the trouble report management system

-- Email links for communications with web site authors, points of contact, and users

Architectural Model

The conceptual model chosen is the structured design, specifically the top-down design. This is appropriate due to its focus on functional decomposition since each of our web pages performs a separate function. The control flow between our web pages is the links.

Module descriptions

a. Module behavior. Module behavior is described in the Design Overview section.

b. Assumptions. Assumptions include Internet access availability and minimal user web browsing experience.

c. Secrets. The hidden implementation details are each page’s HTML code kept secret from the other web pages.

d. Constraints and Limitations. Conditions that must be satisfied for the pages to work correctly include:

e. Error Handling. There are a couple of possible errors and/or exceptions that may occur during the use of our web site. They include the rejection of an user ID/password and the existence of dead links. When a user submits an incorrect ID/password, the user will be asked to resubmit their ID/password two more times. After a total of three incorrect attempts, the user will be asked to contact the webmaster. Although we will attempt to prevent all dead links as outlined in nonfunctional requirements, it is possible that they may occur especially when linking to sites that we do not control. In the event of a dead link, we will ensure a "user friendly" message is displayed in lieu of a "Error 404" or other such type message for the more novice user. A "user friendly" message that may be used is "This web site is currently not available. It will be operational shortly".

f. Expected Changes. The only changes needed are the updating of information on the web pages.

g. Related Requirements. All requirements stated are satisfied by each web page.

h. Module Packaging. These issues are addressed in the Design Overview section.

i. Internal Structure. The software program, FrontPage, determines the internal structure since it automatically writes the code.

Uses Relationships

Within the web site, the links are the relationships to other web pages. Aside from links to specific web pages, there are the links represented by the "back", "up" and "next" icons, which are used to navigate through the site. If the home page is non-functional, then the links to the other pages are not accessible unless the user knows the exact address of the target page.

Rationale