2.3 Background


2.3 Background

As you may already have noticed, the network analysis part of this book, consisting of requirements, flow, and risk analyses, introduces many new concepts and guidelines and expands upon several existing concepts. Therefore, requirements analysis and flow analysis are separated into three chapters, covering concepts and procedures, respectively, in order to make this material more readable and useful. The chapters on concepts provide background material for each topic, explaining and defining pertinent concepts. The chapters on procedures expand on these concepts to build a process for you to apply to your architectures and designs.

We begin the network analysis process with requirements analysis, which is gathering and deriving requirements in order to understand system and network behaviors. This consists of identifying, gathering, deriving, and understanding system requirements and their characteristics; developing thresholds and limits for performance to distinguish between low- and high-performance services; and determining where best-effort, predictable, and guaranteed services may apply in the network.

2.3.1 Requirements and Features

Requirements are descriptions of network functions and performance that are needed for the network to successfully support its users, applications, and devices. Using this definition, every requirement for the network must be met for it to be successful. Yet, as we will see, there can be many requirements, from a variety of sources, with varying degrees of achievability. If we consider all requirements from all sources as being necessary to the success of the network, we are likely setting expectations that cannot be met. Thus, as part of the requirements analysis process, we will prioritize requirements, determining which are truly requirements for the network and which may be desirable but are not truly requirements.

Network functions and performance that are desired but not necessary for the network to successfully support its users, applications, and devices are called features. There will be requirements that, as part of the analysis process, are determined to be features for the network. In addition, there will be requirements that may be considered in a later version of the network, those that will be rejected during the analysis process, and those that are more informational than required.

As shown in Figure 2.1, requirements are separated into core or fundamental requirements (those deemed necessary for that network), features that are desirable for that network, those that may be considered in a later version or upgrade of the network, and requirements that have been rejected (e.g., not really necessary or desirable, not realistic, not implementable). Each network should have, as a minimum, a set of core requirements; in addition, each will probably have a set of informational requirements and may have sets of features, future requirements, and rejected requirements.

click to expand
Figure 2.1: Requirements are separated into core/fundamental requirements, features, future requirements, and rejected and informational requirements.

Requirements are categorized during the requirements analysis process, through discussions with users, management, and staff, and are approved (signed off on) by management. In practice, a first attempt at categorization, done by the analysis group, is presented to management to determine whether this categorization is on the right track. If so, it is further developed with input from users, management, and staff.

One method to categorize requirements is based on current practice of the Internet Engineering Task Force (IETF). RFC 2119 identifies key words and phrases that can be used to describe the relative importance of a requirement. These key words and phrases are must/shall/required, must not/shall not, should/recommended, should not/not recommended, and may/optional. Each of these terms is defined here.

  • Must/Shall/Required. These key words indicate an absolute requirement and would be included as core or fundamental requirements for the network.

  • Must Not/Shall Not. These are also absolute requirements indicating a restriction or prohibition of a function or task. These would also be included as core or fundamental requirements for the network.

  • Should/Recommended. These key words indicate that a requirement may be valid but that its implementation is not absolutely necessary for the success of the network. Such requirements would be categorized as features or future requirements for the network.

  • Should Not/Not Recommended. As with should/recommended, these phrases indicate that a requirement may be valid (in this case to prohibit a function or task) but that its implementation is not absolutely necessary for the success of the network. Such requirements would also be categorized as features or future requirements for the network

  • May/Optional. When a requirement is truly optional, it may be categorized as a feature or future requirement, or it may be rejected.

By using these terms, you help ensure that there is no confusion regarding requirements and features. We will discuss the categorization of requirements in greater detail at the end of this chapter, when we develop the requirements specification.

2.3.2 The Need for Requirements Analysis

Why do requirements analysis? Although requirements analysis is fundamental to the network architecture and design, it is often overlooked or ignored. Why is this the case? A major reason that requirements analysis is not given proper consideration is the degree of difficulty involved. Gathering requirements means talking to users, network personnel, and management and interpreting the results. Talking to N users may result in N + 1 different sets of user requirements. Network personnel and management are often distanced from the users and do not have a clear idea of what users want or need. In addition, requirements analysis may appear to offer no immediate payoff. Finally, requirements analysis means putting thought and time into preparing for the architecture and design.

A result of not doing proper requirements analysis is that the network architecture and design end up being based on factors other than what the users, applications, or devices need. For example, the network may be based on a particular technology, typically one that the designer feels most comfortable with. Another example is a network based on a particular vendor's equipment, again often one that the designer feels comfortable with. An obvious example is having a budget constraint or deadline that forces the designer to make do and use familiar, easy-to-apply technologies. Problems with these choices are that they are not objective and that familiar technologies or vendors may not be the right choices for that particular network.

Requirements analysis helps the designer better understand the probable behavior of the network being built. This results in several payoffs:

  • More objective, informed choices of network technologies and services

  • The ability to match interconnection strategies to networks

  • Networks and elements properly sized to users and applications

  • A better understanding of where and how to apply services in the network

In addition, trade-offs in the architecture and design need to be performed with the total picture in mind. Sometimes this does not become clear until all users, management, and staff have been consulted and all requirements identified. Many re-design efforts result from an initially incomplete set of requirements.

As you proceed through the rest of this book, you will see that the requirements analysis process forms the foundation upon which the network architecture and design processes are built.

In the requirements analysis process, we will use requirements to distinguish between low- and high-performance applications for our networks; identify specific services; gather performance requirements for use in flow analysis; and gather other requirements to be used throughout the analysis, architecture, and design processes. We will see that low and high performance are relative to the network we are working on, and we will develop and apply performance thresholds and limits to help us distinguish between them.

As you will see, the results of requirements analysis are the requirements specification and requirements map. A requirements specification is a document that lists and prioritizes the requirements gathered for your architecture and design. The requirements map shows the location dependencies between applications and devices, which will be used for flow analysis.

Throughout this section (and the others in this book), guidelines will be presented regarding how each process may be implemented. These guidelines are from practical experience and should be used as a starting point for you to develop your own set of guidelines. As we proceed, you are encouraged to think about how each guideline could be implemented and how you would add to or modify it.




Network Analysis, Architecture and Design
Network Analysis, Architecture and Design, Second Edition (The Morgan Kaufmann Series in Networking)
ISBN: 1558608877
EAN: 2147483647
Year: 2003
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net