3.3 Gathering and Listing Requirements

3.3 Gathering and Listing Requirements

Service requirements are gathered and developed with initial conditions on the architecture and design, with input from users, administration, and management and then refined by applying our experience and knowledge about the analysis process. Some guidelines for quantifying requirements and developing thresholds and limits are given in this chapter, but first you must communicate with the users to gather their requirements, so we begin with a discussion of the initial conditions on the network.

3.3.1 Determining Initial Conditions

Initial conditions are the basis for the start of the analysis process. They help determine what you are designing toward, as well as the reasons for the architecture and design. Initial conditions consist of the type of network project, the scope of the architecture and design, initial architecture/design goals, and any outside forces acting on the network. Understanding these initial conditions is important because they will influence the network architecture and design and will often act as constraints on the architecture/design. The initial conditions could also be considered the current state of the existing network's architecture and design.

Before starting the process of gathering and analyzing requirements, you will likely have some notion of the initial conditions for the network project you are undertaking. For example, you will probably know the type of network project and the scope of the project. Some examples of these are as follows:

Type of Network Project	Scope of Network Project
New network Modification of an existing network Analysis of network problems Outsourcing Consolidation Upgrade	Network size Number of sites Distance between sites

You may get your initial architecture/design goals from your customer, and part of this process is to validate those goals, possibly adding to, subtracting from, or modifying them during the process. Examples of such goals are as follows:

Initial Architecture/Design Goals

• Upgrade technology/vendor

• Improve performance to part or all of network

• Support new users, applications, or devices

• Solve perceived problems within system

• Increase security

• Support a new capability in system

Initially, you may not even be aware of outside forces, such as political, administrative, and financial, acting on the network unless you are part of the organization that is requesting the work. Thus, you are likely to have some, but not all, of the initial conditions for the network architecture/design.

Knowing the type and scope of the network project will help you focus your efforts. For example, replacing an old network with an entirely new one minimizes the number of constraints placed on the architecture/design by the existing network (except for possibly any existing external networks with which the new network will have to interface). This allows you to focus on achieving architectural/design goals for the new network. When the project is a modification or an upgrade of an existing network, you have more constraints from the existing network. The existing network will provide information about the current behavior of the network and what can be expected from the changes to the network. The existing network will constrain the architecture and design from the perspective of how to connect and interoperate with part or all of the entire existing network. Thus, the performance and functions of the existing network, along with the reasons for making changes to the network, are important initial conditions.

These conditions also apply when you are doing just the analysis of a network. In this case the network may not be functioning as planned, and you are trying to determine where the problems lie—in the architecture or in the design—or where the implementation varies from the architecture/design. If you are building a network to allow for outsourcing of resource operations, administration, maintenance, and provisioning (OAM&P) functions, then the initial conditions should include where the outsourcing will occur and the methods used by the outsourcing agent to provide OAM&P functions.

There are likely to be several constraints on the network architecture and design. By examining the initial conditions at the start of the analysis process, you stand a much better chance of understanding, removing, or working with these constraints. Common constraints on a network project include funding limitations; the need to work with various organizations or groups within an organization; organizational rules and regulations; time and schedule limitations; and technical constraints from existing users, applications, devices, networks, and management.

Funding limitations are critical to the network project. As we will see in the discussion of architecture and design processes, architecture/design choices are coupled to available funding. Disregarding funding in the analysis process will lead to architecture/design choices that will not be implemented, whereas considering this limitation up-front will help you make the most intelligent use of funding for the network. In this sense, funding limitations can be viewed as positive in that it forces the network architect to develop creative solutions to fit these funding limitations. It is also important to get as good a forecast for future funding as possible.

Organizational constraints, such as with whom you will be working or how groups interact, can become problems during the project. Knowing this in advance will allow you to prepare for this problem, usually by buffering yourself and the project from problem groups or individuals. Sometimes management can help with this type of problem.

There are often political constraints to the network project. Sometimes the technical solution to a network problem is constrained by the political desires of users, management, or staff. Such constraints, which are often illogical, can be the most daunting to work with. However troublesome they may seem, political constraints must be considered part of the network project. Depending on your position in the project, you may have options on how to deal with this type of constraint. As a consultant, you may be able to defer to management in dealing with politics or even refuse the project. As an employee, however, you are more likely to be an integral part of the organization, not easily separated from political issues.

Existing components in the system will often act as constraints. Users suffer from inertia, not wanting to change the ways in which they do their work. Applications written to be used locally on a device or for a particular network technology or protocol may have to be modified to function on the new network. Device interfaces and drivers may have to be changed or upgraded. Existing networks will bring their performance and functional limitations to the project. By knowing early in the process which parts of the existing system will be incorporated into or supported in the new network, you can determine which architectural/design choices will work and, just as important, which will not work.

Part of the initial conditions for your network project may be determining its performance target: multitier performance or single-tier performance (Figure 3.2). Multitier performance networks typically have one or a few applications, users/groups, and/or devices whose performance requirements are significantly greater than those of other components on that network. As a result there is a threshold between low-and high-performance requirements for this type of network. Typically, this set of high-performance requirements drives how and where performance is architected into the network.

Figure 3.2: Determining performance targets— single or multitier performance.

On the other hand, single-tier performance networks do not have a distinctive set of applications, users, or hosts that have significantly greater performance requirements for that network, so there is no threshold between low and high performance for this type of network. This is significant, for without a set of high-performance requirements to drive how and where performance is architected into the network, performance is architected to support everyone equally.

The performance target for the network as single tier or multitier is one of the fundamental concepts in this book, which we discuss in greater detail in the section on architecture and design processes. For many networks, you may need to consider both types in your architecture and design.

Determining the initial conditions for the network will lead you into the requirements analysis process. You will know some of the initial conditions, and you will have to learn others. As you start digging for answers, you will be gathering information for the analysis process.

3.3.2 Setting Customer Expectations

At this point in the analysis process it is important to begin to set customer expectations. This consists of:

• A rapid, initial evaluation of the problem

• Estimation of the resources and schedule

This is not intended to be an in-depth estimate but rather a quick evaluation to catch obvious problems. How quick the evaluation is depends, in part, on your role in the project. If you are a consultant or advisor, you may have to be very quick, on the order of hours or days. If you are the network architect/designer for the organization's network, you may have weeks to do the evaluation. In general, this evaluation can be done on the order of a few days. The intent is to inform customers, early in the process, when their expectations are unrealistic. This helps to realign the customer if necessary and avoids back loading of the project.

At times, you may find that customers' definition of the problem and their expectations are quite correct. Usually, however, these expectations need to be adjusted somewhat. In addition, there may be times when you find that customers' expectations and your expectations are so far apart that it is better not to continue on that project. It is better to find this out early in the project.

3.3.3 Working with Users

In working with users, your first inclination may be to think, "This takes too much time," "They are not cooperative," "They don't know what they want," and so on, but it is a vital—sometimes painful—part of the process. By initially spending time with users, you will gain a better understanding of their behavioral patterns and environment. For the end users, discussing your network plans with them will help them understand what you are trying to accomplish, building lines of personal communication that will be useful when you are installing, debugging, and operating the network later.

Although it can be challenging to communicate with users (including administration and management), there are some successful techniques that you can use:

• Develop a survey to email, fax, or mail to users.

• Follow up on the survey with one-on-one telephone calls or conference calls.

• Follow up calls with face-to-face meetings with selected individuals or groups.

• Conduct whiteboard sessions to elicit ideas from users.

• Spend time with users while they work to better understand what they do and how they do it.

A key trade-off is the amount of time spent versus the quality of information gathered. Working with your users, administration, and management will pay off in another way: getting them to see that you are taking an active, systems approach in the network project, not just developing a network "in the dark." For the system to meet the needs of its users, users must be able to communicate these needs to you, the applications need to be designed to work across the network, and devices need to be chosen with the system in mind. The network is central to the system, so your role in bringing the systems approach to the users is important. In a sense, you are fostering support for the network, its architecture and design, and its role in the system.

Therefore, it is important not to take a hit-and-run approach, talking to the users only to get their requirements and not following up with them. By building relationships with the users, administration, and management, through discussing their requirements, advising them of results and anticipated actions, and informing them of progress with the network project, you are developing advocates for your network. This may be vital when you need to upgrade the network in the future or if you have to defend your architectural and design decisions.

While you gather requirements, look for warning signals, also known as "red flags." For example, warning signals occur when there is a lack of precision or clarity in requirements, such as the following:

• Misuse of "real-time"

• Availability as solely a percentage (99.99%)

• "High performance" without verification

• Highly variable, inconsistent requirements

• Unrealistic expectations from the customer

When you encounter such warning signals, you should attempt, when possible, to clarify the meaning of the statement. Later in this chapter, we will discuss ways to clarify several red flags.

When you are gathering requirements and interacting with users, it is a good time to assess the opinion that users have of the current network, as well as that of the networking and operations staff.

3.3.4 Taking Performance Measurements

When possible, it is useful to measure performance levels of applications and devices that will be used in the planned network. This is often done either by testing applications and devices on a separate, controlled network (e.g., testbed network) or by measuring their performance levels on the existing network.

Building a small testbed network to measure application and device performance can serve multiple purposes. Since a testbed network is controlled, you can ensure that there is sufficient capacity available for your applications and devices. Thus, the network does not limit the performance of the applications and devices under testing. You will be able to measure peak performance, from which you can derive performance requirements for those applications and devices.

Measurements of peak application and device performance can be used to determine how much degradation in performance is experienced on the existing network. Such measurements become a validation of performance problems on the existing network.

Along with performance measurements, you can often capture all of the traffic from an application session through promiscuous monitoring of the network. This information is useful in characterizing and modeling application and user behaviors, discussed in Section 3.5. Tools that can help capture traffic include Sniffer, Ethereal, and Etherpeak.

If a testbed network cannot be built to measure performance, measurements can be made on the existing network (if permitted by management). You will be able to get performance data using this technique, but the existing network will limit application and device performance. This technique is still quite useful to capture traffic to characterize and model application and user behaviors. These two techniques are shown in Figure 3.3.

Figure 3.3: Measuring performance using a testbed and the existing network.

3.3.5 Tracking and Managing Requirements

Requirements also need to be tracked and managed. A list of requirements should be kept up-to-date in a location where everyone involved in the process has access to them. The Web is a great tool for posting, tracking, and managing requirements. You can use a number of methods to track and manage requirements; two of these are shown here. First is paragraph form, where a requirement is changed within its original paragraph. Example 3.1 shows a requirement managed in this form.

Example 3.1: A requirement for upgrades to network equipment is shown.

• NR -1.0-102. All (technology A 3/7/2000) network equipment shall be capable of software (or firmware 4/1/2000) (deleted 4/17/2000) based upgardes to allow it to support changes to high speed (any 5/20/2000) data service features and functions.

This requirement has been changed as part of the analysis process. As you can see, changes were made at various times, reflecting the evolution of requirements as you talk with users, management, and staff. In this example, one requirement (for software-based upgrades) was changed on 4/1/2000 to include firmware-based upgrades, which was then deleted on 4/17/2000, restoring it to its original form. It is important to note that while a requirement evolves, the description of that requirement keeps all changes visible. In this example, you can tell what the original requirement was and how it has changed. Thus, if someone wants to make a change that was already attempted, he or she will know that beforehand.

Another method to track and manage requirements is in tabular form. In this method, the requirement is kept in its original form and any changes to it are added to a table. Figure 3.4 shows how this is done, using the requirement from Example 3.1.

ID/Name	Date	Type	Description
NR -1.0-102	01Jan2000	Original	All network equipment shall be capable of software-based upgrades to allow it to support changes to high-speed data service features and functions.
	07Mar2000	Change	"All network equipment" changed to "Technology A."
	01Apr2000	Change	"software based upgrades" changed to "software-or firmware-based upgrades."
	17Apr2000	Deletion	Change of 01Apr2000 deleted.
	20May2000	Change	"high-speed" changed to "any."

Figure 3.4: Requirements tracking and management in tabular form.

Other software tools, such as databases and spreadsheets, can be used for this process. The key point here is that requirements documents should be living documents, updated regularly to reflect the changing nature of the network and system.

As a list of what the system needs from the network architecture and design, these requirements will be used as the foundation for the rest of this book.

Initial conditions, constraints, and any assumptions about the environment of the network project should be included with the list of requirements. This helps determine the system components for which you need to get more information.

3.3.6 Mapping Location Information

As part of the analysis process, the locations of applications and devices will be mapped to show their relative physical locations. In Chapter 2, we introduced the concept of mapping applications and devices. While gathering requirements, note (when possible) the locations of servers and specialized devices and where specific applications are being used.

For example, Figure 3.5 shows an example of a metropolitan-area environment with devices and applications.

Figure 3.5: Example of a metropolitan-area map.