2.4 User Requirements

2.4 User Requirements

From the model of system components in our generic system, the user component is at the highest layer. The term user represents primarily the end users of the system, but it can be expanded to include everyone involved in the system, such as network and system administrators and management. User requirements is the set of requirements gathered or derived from user input and is what is needed by users to successfully accomplish their tasks on the system. Typically, when gathering requirements, everyone involved with that network is considered a potential user. Figure 2.2 shows some example user requirements.

Figure 2.2: Types of user requirements.

We begin describing requirements at this layer, which will lead to the development of more specific requirements as we work through each of the components.

From the user perspective, we can ask, "What does it take to get the job done?" This will usually result in a set of qualitative, not quantitative, requirements. Part of our job in gathering and deriving user requirements is to make them quantitative whenever possible.

In general, the system should adapt to users and their environments, provide quick and reliable information access and transfer, and offer quality service to the user. This indicates the following general requirements:

• Timeliness

• Interactivity

• Reliability

• Presentation quality

• Adaptability

• Security

• Affordability

• Functionality

• Supportability

• Future growth

User requirements are the least technical and are also the most subjective. As shown in Figure 2.3, requirements become more technical as they move from users to the network. All of these requirements will be developed in more detail as we proceed through the application, device, and network components.

Figure 2.3: Requirements become more technical as we move closer to network devices.

The intent is to use them as a start toward developing more objective and technical requirements in the other components. These example requirements are presented as a guide for you to use in developing requirements for your network, and they may change depending on the user's environment.

Timeliness is a requirement that the user is able to access, transfer, or modify information within a tolerable time frame. What a "tolerable" time frame is, of course, depends on the user's perception of delay in the system. It is this perception that we want to quantify. For example, a user may want to download files from a server and complete each transfer within 10 minutes. Or the user may need to receive video frames every 30 ms. Each one of these times indicates a delay that the network will need to provide. For timeliness, end-to-end or round-trip delay can be a useful measurement.

Interactivity is similar to timeliness but focuses on a response time from the system (as well as the network) that is on the order of the response times of users. In the preceding example, we could consider the 10 minutes needed to download a file as the response time for the system. We further say that the file transfer is interacting with the user (which it is), but the degree of interactivity in this example is very low and not of much interest from an architectural or design perspective. What is interesting is when the system and network response times are close to the response times of users, for then changes that are made in the network architecture and design to optimize response times can have a direct impact on users' perception of interactivity. Therefore, interactivity is a measure of the response times of the system and network when they are required to actively interact with users. Delay, here the round-trip delay, is a measure of interactivity. Using these descriptions of timeliness and interactivity, timeliness is more likely to be associated with bulk file or image transfer, whereas interactivity is likely to be associated with remote device access (e.g., telnet), Web use, or visualization.

Reliability, that is, availability from the user's perspective, is a requirement for consistently available service. Not only must the user be able to have access to system resources a very high percentage of the time, but the level of service to the user (in terms of application usage or information delivery) must be consistent. Thus, reliability is closely related to the performance characteristic reliability (discussed in Chapter 1 as part of RMA), but delay and capacity are also important. It is likely that a combination of all performance characteristics would be used to describe reliability.

Presentation quality refers to the quality of the presentation to the user. This may be the user's perception of audio, video, and/or data displays. As examples, consider the current Internet capabilities of video conferencing, video feeds (live or delayed), and telephony. Although it is possible to do all of these on the Internet, there are other mechanisms that currently provide much better presentation quality. It is often not sufficient to provide a capability over a network—that capability must be as good or better than other mechanisms, or the user will be disappointed. Network architects and designers often miss this concept. Measures of quality include all of the performance characteristics.

Adaptability is the ability of the system to adapt to users' changing needs. Some examples of this are in distance-independence and mobility. As users rely more and more on the network, they are becoming coupled to logical services and decoupled from physical servers. This decoupling means that users do not have to care where servers are located, as long as they can get the services they need. A result of this is distance-independent computing, where the user loses all knowledge of where jobs are being executed, or where data are sourced, stored, or migrated through the network. Mobility refers to mobile or nomadic computing, where the user can access services and resources from any location, using portable devices and wireless access to the network. Adaptability to such user needs forces requirements on the system architecture and design.

Security from the user perspective is a requirement to guarantee the confidentiality, integrity, and authenticity of a user's information and physical resources, as well as access to user and system resources. Security is probably closest to the performance characteristic reliability, but it will affect capacity and delay as well.

Affordability is the requirement that purchases fit within a budget. Although this requirement is not technical, it will affect the architecture and design. Our goal in this requirement is to determine what users or management can afford to purchase for the network so that our architecture and design do not cost too much to implement. As a user requirement, we are looking for how costs and funding are tied to users, groups of users, and management. We will also discuss funding as a system-wide requirement, from an overall budget perspective.

Functionality encompasses any functional requirement that the user will have for the system. Functions that the system will perform are often tied to applications that are used on the system. Understanding functionality is important in that it will lead into application requirements (covered in the next section). Part of understanding functionality is determining which applications users actually want or apply in their daily work. We do not want to analyze applications that no one is planning to use.

Supportability is a set of characteristics that describe how well the customer can keep the network operating at designed performance through the full range of mission scenarios described by the customer during the requirements analysis process. This includes how users want or need to be supported by their network operations staff and any interfaces they will have with a network operations center (NOC). For example, will the network need to be reconfigured to meet different or changing user needs? What applications will the network operations staff and/or NOC need to provide support to users and to identify and troubleshoot problems on the network? Information such as this will be used later as input to the network management architecture.

Future growth is determining if/when users are planning to deploy and use new applications and devices on the network.

In addition to these requirements, we will want to know how many users will be expected on the network and their locations. If possible, estimate what the growth in users will be over the first 1 to 3 years after the network is planned to be operational, or for what you expect the life cycle of the network to be.