Determining requirements includes extracting initial requirements from the customer and then refining these with other data that has been collected from the organization.

Extracting Initial Requirements

Initial design requirements are typically extracted from the Request for Proposal (RFP) or Request for Information (RFI) documents that the customer issues. An RFP is a formal request to vendors for proposals that meet the requirements that the document identifies. An RFI is typically a less formal document an organization issues to solicit ideas and information from vendors about a specific project.

The first step in the design process should be predocumenting (sifting, processing, reordering, translating, and so forth) the design requirements and reviewing them with the customer for verification and approval, obtaining direct customer input, in either oral or written form.

Figure: Identifying Customer Requirements

Step 1 Extract the initial customer requirements (from the RFP or RFI).

Step 2 Query the customer for a verbal description of the initial requirements.

Step 3 Produce a draft document that describes the design requirements.

Step 4 Verify the design requirements with the customer, and obtain customer approval.

Step 5 Revise the document as necessary to eliminate errors and omissions.

Gathering Network Requirements

the process of gathering requirements can be broken down into five steps. During these steps (which are sometimes called milestones), the designer discusses the project with the customer’s staff to determine and gather the necessary data, including appropriate documentation which shown in below figure.

Step 1 Identify the planned network applications and network services.

Step 2 Determine the organizational goals.

Step 3 Determine the possible organizational constraints.

Step 4 Determine the technical goals.

Step 5 Determine the technical constraints that must be taken into account.

Planned Applications and Network Services

The designer must determine which applications the customer is planning to use and the importance of each of these applications. Using a table helps organize and categorize the applications and services planned; the table should contain the following information:

■ Planned application types: Include e-mail, groupware (tools that aid group work), voice networking, web browsing, video on demand (VoD), databases, file sharing and transfer, computer-aided manufacturing, and so forth.

■ Applications: Specific applications that will be used, such as Microsoft Internet Explorer, Cisco Unified MeetingPlace, and so forth.

■ Level of importance: The importance of the applications—whether critical or important or not important—is noted.

■ Comments: Additional notes taken during the data-gathering process.

Figure: Gathering Data for Design Requirements

Table 1 shows an example of data gathered about the planned applications for the sample company,

Table 1 Example on company Planned Applications

The planned infrastructure services table is similar to the planned application table. It lists infrastructure services that are planned for the network and additional comments about those services. Recall that infrastructure services include security, QoS, network management, high availability, and IP multicast. Software distribution, backup, directory services, host naming, and user authentication and authorization are examples of other services and solutions that are deployed to support a typical organization’s many applications

Table 2 Company Planned Infrastructure Services

Organizational Goals

Network designers are often eager to start by analyzing the technical goals before considering the organizational goals and constraints. However, detailed attention to organizational goals and constraints is important for a project’s success. In discussions about organizational goals, the designer obtains knowledge about the customer’s expectations of the design’s positive outcomes for the organization. Both short- and long-term goals should be identified. This organizationcentered approach allows the network to become a strategic asset and competitive weapon for the customer. Organizational goals differ from organization to organization. The following are some typical goals that commercial organizations might have:

■ Increase the operation’s generated revenue and profitability. A new design should reduce costs in certain segments and propel growth in others. The network designer should discuss with the customer any expectations about how the new network will influence revenues and profits.

■ Shorten development cycles and enhance productivity by improving internal data availability and interdepartmental communications.

■ Improve customer support and offer additional customer services that can expedite reaction to customer needs and improve customer satisfaction.

■ Open the organization’s information infrastructure to all key stakeholders (prospects, investors, customers, partners, suppliers, and employees), and build relationships and information accessibility to a new level.

Following are examples of the types of data that can be gathered about some common organizational goals:

■ Increase competitiveness: List competitive organizations and their advantages and weaknesses. Note possible improvements that might increase competitiveness or effectiveness.

■ Reduce costs: Reducing operational costs can result in increased profitability (even without a revenue increase) or increased services with the same revenue. List current expenses to help determine where costs could be reduced.

■ Improve customer support: Customer support services help provide a competitive advantage. List current customer support services, with comments about possible and desired improvements.

■ Add new customer services: List current customer services, and note future and desired (requested) services.

Table 3 presents data gathered about the organizational goals of a sample company,

Table 3 Company Organizational Goals

Organizational Constraints

Typical constraints include the following:

■ Budget: Reduced budgets or limited resources often force network designers to implement an affordable solution rather than the best technical solution. This usually entails some compromises in availability, manageability, performance, and scalability. The budget must include all equipment purchases, software licenses, maintenance agreements, staff training, and so forth. Budget is often the final decision point for design elements, selected equipment, and so on. The designer must know how much money is available to invest in a solid design. It also useful to know the areas in which the network can be compromised to meet budget requirements.

■ Personnel: The availability of trained personnel within the organization might be a design consideration. Organizations might not have enough trained personnel, or they might not have enough personnel. Familiarity with both the equipment and technologies speeds deployment and reduces cost, and trained technicians must be available to verify that all network elements are working. Therefore, the designer must know the number and availability of operations personnel, their expertise, and possible training requirements. Additional constraints might beimposed if the organization is outsourcing network management. The designer must consider the network’s implementation and maintenance phases, which require adequately trained staff.

■ Policies: Organizations have different policies about protocols, standards, vendors, and applications; to design the network successfully, the designer must understand these policies. For example, the designer should determine customer policies related to single-vendor or multivendor platforms; an end-to-end single-vendor solution might be a benefit, because compatibility issues do not restrain the network. As another example, many organizations, such as government agencies (for example, defense departments), often have strict policies preventing implementation of proprietary protocols.

■ Schedule: The organization’s executive management must discuss and approve the project schedule to avoid possible disagreements about deadlines. For example, the introduction of new network applications often drives the new network design; the implementation time frames for new applications are often tightly connected and therefore influence the available time for network design.

Table 4 shows organizational constraints and accompanying data that has been collected for a sample company,

Table 4 Sample Company Organizational Constraints

Technical Goals

The following list describes some common technical goals:

■ Improve network performance: An increase in the number of users and the introduction of new applications might degrade network performance, especially responsiveness and throughput. The first goal of network redesign is usually to increase performance—for example, by upgrading the speed of links or by partitioning the network into smaller segments.

■ Improve security and reliability of mission-critical applications and data: Increased threats from both inside and outside the enterprise network require the most up-to-date security rules and technologies to avoid disruptions of network operation.

■ Decrease expected downtime and related expenses: When a network failure occurs, downtime must be minimal, and the network must respond quickly to minimize related costs.

■ Modernize outdated technologies: The emergence of new network technologies and applications demands regular updates to and replacement of outdated equipment and technologies.

■ Improve scalability of the network: Networks must be designed to provide for upgrades and future growth.

■ Simplify network management: Simplify network management functions so that they are easy to use and easily understood.

Table 5 depicts the desired technical goals that were gathered for the sample company, Corporation X, along with their importance rating and additional comments. In this example, the designer sees that the customer places great importance on availability, scalability, and performance;

Table 5 Sample Company Technical Goals

Technical Constraints

Good network design addresses constraints by identifying possible trade-offs, such as the following:

■ Existing equipment: The network design process is usually progressive; legacy equipment must coexist with new equipment.

■ Bandwidth availability: Insufficient bandwidth in parts of the network where the bandwidth cannot be increased because of technical constraints must be resolved by other means.

■ Application compatibility: If the new network is not being introduced at the same time as new applications, the design must provide compatibility with old applications.

■ Lack of qualified personnel: Lack of qualified personnel suggests that the designer must consider the need for additional training; otherwise, certain features might have to be dropped. For example, if the network proposal includes the use of IP telephony but the network administrators are not proficient in IP telephony, it might be necessary to propose an alternative solution.

Table 6 presents sample technical constraints gathered for Company.