Lesson 1

In the previous module, you learned how a web design team plans for an effective integration of network components. This module discusses hardware requirements and how a team plans for them. When you are finished with this module, you should be able to:

1. Describe the different hardware types and functions
2. Describe the different types of servers and their functions
3. List the steps for estimating the server's transfer load
4. Give examples of connectivity hardware and the problems associated with it
5. Give examples of security hardware and the problems associated with it
6. Identify strategies for dealing with common hardware risks

Requirements are intended to constrain the solution space to solutions that will encourage small-problem solutions that synergistically work together to satisfy the system solution. System Object Design
Requirements are formed from the words and symbols of the chosen language. They include all of the standard language components arranged in the way that a good course in that language specifies. Those who have difficulty writing requirements experience one of three problems:

1. fundamental problems expressing themselves in the language of choice, which can be corrected by studying the language:
2. technical knowledge deficiency that makes it difficult to understand the technical aspects of the subject about which the requirements are phrased that can be corrected through study of the related technologies, and
3. difficulty in deciding what to write requirements about.

The solution to the latter problem is the possession of a complete toolbox of effective requirements modeling tools.
Providing the toolbox should be the function of the system engineering department, recognizing that some departments outside of the system engineering department will contribute people to programs and these people will apply a department-unique method that should be coordinated with the intended systems approach. This toolbox must encourage the identification of product characteristics that must be controlled. This toolbox must help us to understand what to write requirements about. We must accomplish requirements identification and requirements definition where we determine the values appropriate for those requirements.

Requirements definition through modeling gives us a list of characteristics that we should control to encourage synergism within the evolving system definition. If the analyst had a list of characteristics and a way to value them for specific items, he or she would be in a very good position to write a specification that would match his objective. That is to capture all of the essential characteristics and no additional content. One approach to a solution to this problem on what to write requirements about is boilerplate. In the boilerplate approach, you have a list of paragraph numbers and titles, and you attempt to define how each title relates to the item of interest. This results in a complete requirement statement that becomes the text for the paragraph stating that requirement. The problem with this approach is that there are many kinds of requirements that cannot be specifically identified in such a generic listing.
One could create a "performance requirements" boilerplate that covered every conceivable performance requirement category with some difficulty, only to find that it was more difficult to weed out those categories that did not apply to a specific item than it would have been to have determined the appropriate categories from scratch. This is why one would find no lower level of detail in a specification standard than performance even though there may evolve 43 pages of performance requirements during the analysis for a particular specification.
In the next lesson, you will learn about the hardware categories required for planning a Web site.