2.8 Other Requirements


2.8 Other Requirements

There are other requirements that apply across all of the components of the system, such as financial and enterprise requirements. There are likely to be other such requirements for your network, and they would be included here.

2.8.1 Supplemental Performance Requirements

In an ideal world, components perform according to specification all the time for the life of the system. Reality is often much less tidy. Couple that with the fact that human beings operate and maintain the systems we build and that their skills, quality, and morale are not always at maximum means that there are many things that can affect the performance of the network once it is installed. The real world intrudes on the network engineer when he or she looks beyond the point where the network is designed and implemented to the Initial Operational Capability (IOC), when the first segments are brought online in a production mode. They must consider that phase when finally the network implementation is complete and the system is in completely in the hands of the operators instead of the engineers to satisfy the customers and end users of this creation. Three characteristics of performance that reflect the customer's reality on our network design are operational suitability, supportability, and confidence. Operational suitability is a measure of how well our network design can be configured, monitored, and adjusted by the customer's operators. Supportability is a measure of how well the customer can keep the system performing, as designed, over the entire life of the system. Confidence is a measure of the ability of the network to deliver data without error or loss at the required throughput.

By identifying, documenting, and validating these constraints with the customer during the requirements analysis phase, the network engineer will ensure that the customer is prepared to understand the trade-offs between cost and performance and the time phasing of the total ownership costs and that the customer has a chance to influence these decisions. It also reduces the surprise factor when the owner has to actually operate the network. This also permits the customer to be prepared to identify when the network has exceeded the design capacity and commission an upgrade or service life extension or replacement. Customers who commission a network design to support 1000 connections should be aware that, when their need becomes 20,000 connections, they need an entirely different network; likewise, the need for higher reliability or substantially faster restoration of service during a fault may also warrant a new look at the architecture, components, and operating procedures that comprise the architecture/design.

These three factors must be taken into account when contracting for external services, such as MAN, WAN, or ISP connections; hardware; or maintenance services. The rate at which failures occur and the speed at which service is restored must be included in the specification and must be factors in the selection and award of third-party connectivity services.

These factors are often discounted or misunderstood by network engineers and by the customer themselves. Invariably, when customers are asked for their requirements, these factors are so fundamental in their way of thinking that they won't mention them unless asked. The network engineer, as part of the requirements process, must ensure that appropriate questions are asked and that the answers documented so that the design effort will properly factor them into the decisions about architecture, component selection, incorporation of third-party services (e.g., ISP), implementation planning, testing, and IOC.

Operational suitability, supportability, and confidence will be described in detail in Chapter 3.

2.8.2 Financial Requirements

An example of a system-wide requirement is to constrain expenditures to the level of funding that is available to implement the network, as funding for the network will be coupled to funding for other parts of the system, particularly devices. Funding is often associated with an overall cost limit, with one-time and recurring components. One-time costs are based on the actual planning and construction of the network and consist of network architecture, design, procurement, deployment, integration, testing, and all hardware/software components, as well as the initial installation or establishment of any services from service providers. Recurring costs are for tasks and items that are expected to occur or be replaced/upgraded on a periodic basis. This includes network OAM&P, costs from service providers, and provisions for modifications to the network. Time frames for recurring costs vary, driven by customer/end user, administrative, and management financial cycles and technology life cycles.

The level of funding is usually a constraint to the architecture and design; therefore, it is important to know what this level is as early in the analysis process as possible to avoid creating an architecture and design that are not economically feasible. In knowing funding constraints and the requirements for the network, we should be able to determine when an architecture/design that will meet its requirements will exceed available funding. In determining this early in the process, we can develop arguments for changing the level of funding, the requirements for the network, or both.

The financial requirements gathered during the analysis process will be combined with the users' affordability requirements to form a complete financial picture of the network. Later in this book we will consider funding constraints to the architecture and design and how these processes work to optimize the architecture and design to minimize costs. We will see that it is often beneficial to provide the customer with multiple prototype architectures and designs and well-defined functional and financial differences so that customers can help make clear choices about how they want to spend their money.

2.8.3 Enterprise Requirements

There may be times when you will have to consider requirements for the network that are commonly considered enterprise requirements, such as phone, fax, voice, and video. The integration of these types of requirements over the same transmission infrastructure as data is becoming common, and such enterprise requirements need to be considered as part of the overall requirements for the network.




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