Introduction
Welcome to the capstone project! Over the last seven modules, you've built a solid arsenal of networking skills: VLSM, VLANs, inter-VLAN routing, ACLs, and even VRFs. Now, it's time to integrate all of that knowledge to design a complete enterprise network from the ground up, just as you would in a real-world project.
This first lesson of the project focuses on the most critical starting point: translating a set of business requirements into a formal technical requirements document. This is the blueprint that will guide every decision you make for the rest of the project. Your goal is to move from a high-level business problem ("we need better security") to a concrete, actionable technical plan ("the network must use VRFs to isolate guest traffic").
We'll start by looking at the professional methodology for this process, then dive into a realistic scenario that you will analyze and document.
The 'Why': A Top-Down Approach
In network design, it's tempting to jump straight to thinking about specific hardware or CLI commands. However, the most successful and robust architectures are built using a top-down approach. This means you start with the business's goals and constraints, and let those needs dictate the technology choices—not the other way around. A network that doesn't solve the business's problems is a failure, no matter how elegant its configuration is.
The following document from Cisco Press provides an excellent overview of this philosophy. It explains how business drivers are the true foundation of any network architecture.
Network Design Requirements: Analysis and Design Principles
To understand the professional approach to network design, it's crucial to grasp the 'top-down' methodology. This document explains why we always start with business goals.
Read the introduction to the 'top-down approach' and the section on 'Business Requirements' (pages 3-9). Focus on how high-level needs like Business Continuity, Elasticity, and Innovation drive the entire design process. The goal is to absorb the mindset, not to memorize every detail.
The 'How': From Business Goals to Technical Specs
So, how do you practically translate a vague business goal into a specific technical requirement? The process involves analyzing the business needs, identifying constraints, and then systematically defining the network's required functionality.
This slide provides a perfect visual summary of this translation:
The slide shows a clear path from a single business goal to multiple, specific technical requirements. To explore this process in more detail, let's turn to another resource that uses Cisco's PPDIOO (Prepare, Plan, Design, Implement, Operate, and Optimize) lifecycle model as a framework.
Gathering Network Requirements
This document provides a structured process for this translation. The 'Prepare' and 'Plan' phases of the network lifecycle are dedicated almost entirely to gathering and defining requirements.
Read the sections covering the 'Prepare Phase,' 'Plan Phase,' 'Identifying Business Goals and Priorities,' and 'Identifying Technical Requirements and Constraints' (pages 51-52 and 65-68). Pay close attention to Figure 2-5 and Table 2-1, which give concrete examples of mapping business goals to technical requirements for the StadiumCompany case study.
The Capstone Scenario: Your Mission
Now it's time to apply this process. You've been brought in as the lead network architect for a project at "Aperture Logistics."
Here is the project brief:
Client: Aperture Logistics, a growing company specializing in automated warehouse and supply chain solutions.
Project Overview: Aperture is consolidating its operations into a new, modern campus. The network needs to be designed from scratch to support their current operations and future growth.
Business Goals:
- Seamless Operations: Ensure a smooth transition to the new campus with a highly available network that minimizes downtime.
- Enhanced Security: The company's R&D data is highly sensitive and must be protected.
- Client & Guest Services: Provide reliable, high-speed Wi-Fi for visiting clients in demo areas, but this traffic must be completely isolated from the internal corporate network.
- Modern Collaboration: Fully support real-time communication tools, including VoIP phones and high-definition video conferencing.
- Future-Proof Scalability: The network must easily support a projected 50% growth in employees and devices over the next three years.
- Simplified Management: The network must be manageable by a small IT team.
Site & User Details:
- HQ Building (2 floors): 400 employees (Admin, HR, Sales, Management). All require wired and wireless access.
- R&D Building (1 floor): 150 engineers with high-bandwidth needs. This building also houses the central server farm.
- Warehouse/Showroom Building (1 floor): 50 employees. Contains public-facing showrooms and demo areas. Houses approximately 200 IoT devices for inventory tracking.
- Server Farm (in R&D Building): Approximately 30 physical and virtual servers (Development, Production, File Servers, etc.).
Specific Security Mandates:
- Traffic from the R&D department must be isolated from the general corporate network.
- The guest Wi-Fi network must use a separate, dedicated internet connection and have no path to any internal resources.
- The warehouse IoT devices must be on their own network, with access restricted to a single inventory management server.
Organizational Constraints:
- Timeline: The entire network must be designed, implemented, and tested within 4 months.
- Budget: Cost is a factor. The design should be efficient and justify all hardware expenses. Assume budget is approved for new Cisco L2/L3 switches and a firewall.
- Staffing: The IT staff is comfortable with Cisco CLI but lacks deep design expertise. The final solution must be logical and easy to manage.
Your Task: Create the Technical Requirements Document
Your job is to take the scenario above and create a formal technical requirements document. This document will serve as the foundation for all your subsequent work in this project.
Use the template below. For each category, list the specific technical requirements that your new network design must meet. Think about how a technical feature or design principle (like redundancy, VLSM, or VRFs) directly supports one or more of the business goals.
Copy and paste this template into your notes and fill it out:
### Technical Requirements Document: Aperture Logistics
**1. Business Goals Summary**
*(Briefly summarize the 6 key business goals listed in the scenario.)*
**2. Organizational Constraints Summary**
*(Briefly summarize the key constraints: timeline, budget, and staffing.)*
**3. Technical Requirements**
**3.1. Availability & Reliability**
*(How will you ensure the network stays up? Think redundancy, single points of failure.)*
- Requirement 1: ...
- Requirement 2: ...
**3.2. Scalability**
*(How will you ensure the network can grow? Think IP addressing, modular design.)*
- Requirement 1: ...
- Requirement 2: ...
**3.3. Security**
*(How will you meet the security mandates? Think isolation, segmentation, access control.)*
- Requirement 1: ...
- Requirement 2: ...
- Requirement 3: ...
**3.4. Performance**
*(How will you support demanding applications like voice and video?)*
- Requirement 1: ...
- Requirement 2: ...
**3.5. Manageability**
*(How will you make the network easy to operate and troubleshoot?)*
- Requirement 1: ...
- Requirement 2: ...
Take about 20 minutes to complete this. There are no single "right" answers, but your requirements should be specific and directly traceable to the project brief. When you're ready, check your work against the detailed example below.
Click here for a completed example of the Technical Requirements Document.
Here is a well-defined technical requirements document based on the scenario. Your version may differ slightly, which is perfectly fine as long as your logic is sound.
Technical Requirements Document: Aperture Logistics
1. Business Goals Summary
The network must be highly available, secure, scalable for 50% growth, and simple to manage. It needs to provide isolated guest access and support high-performance collaboration tools like VoIP and video.
2. Organizational Constraints Summary
The project is on a 4-month timeline with a cost-conscious budget. The network must be manageable by a small IT team familiar with Cisco CLI.
3. Technical Requirements
3.1. Availability & Reliability
- Requirement 1: The network topology will use a hierarchical design (Core, Distribution, Access) with redundant L3 switches at the Core/Distribution layers to eliminate single points of failure. (Maps to Goal #1)
- Requirement 2: Redundant physical links will be used between all Core and Distribution switches. First-Hop Redundancy Protocols (like HSRP) will be configured for all VLAN default gateways. (Maps to Goal #1)
3.2. Scalability
- Requirement 1: The network design will be modular, with each building representing a distinct block. This allows for future buildings to be added without redesigning the core. (Maps to Goal #5)
- Requirement 2: The IP addressing plan must use Variable Length Subnet Masking (VLSM) to ensure efficient allocation and reserve a significant portion of the address space for future expansion. (Maps to Goal #5)
3.3. Security
- Requirement 1: The network must be segmented using VLANs to create separate broadcast domains for different user groups (e.g., HQ Staff, R&D), functions (VoIP, IoT), and services (Servers). (Maps to Goals #2, #3)
- Requirement 2: Access Control Lists (ACLs) will be implemented on Switched Virtual Interfaces (SVIs) to enforce security policies and restrict inter-VLAN traffic, specifically isolating the R&D and IoT networks as mandated. (Maps to Goals #2, IoT Mandate)
- Requirement 3: The design will use Virtual Routing and Forwarding (VRF-Lite) to create two completely separate routing tables: one for internal corporate traffic (
CORP_INTERNAL) and one for guest/public traffic (GUEST_INTERNET). (Maps to Goal #3) - Requirement 4: The
GUEST_INTERNETVRF will be tied to the Guest Wi-Fi VLAN and will have a dedicated physical uplink to a separate ISP/firewall, ensuring no traffic path to the corporate network exists. (Maps to Goal #3)
3.4. Performance
- Requirement 1: The network infrastructure will provide Gigabit Ethernet to the desktop and 10-Gigabit uplinks between Access, Distribution, and Core switches to support high-bandwidth applications. (Maps to Goals #1, #4)
- Requirement 2: End-to-end Quality of Service (QoS) must be implemented. Traffic will be classified and marked at the access layer to prioritize real-time voice and video packets across the network. (Maps to Goal #4)
3.5. Manageability
- Requirement 1: A dedicated, out-of-band management VLAN will be created for secure access to all network infrastructure devices (switches, firewalls). (Maps to Goal #6)
- Requirement 2: Access to the management VLAN will be strictly controlled by an ACL, permitting access only from specific IT workstations. (Maps to Goal #6)
- Requirement 3: A standardized and well-documented IP addressing and naming convention will be used for all devices and interfaces. (Maps to Goal #6)
Conclusion
Excellent work. You have now completed the foundational step of a professional network design project. By translating business needs into a structured technical requirements document, you have created the definitive guide for all subsequent design phases.
Key Takeaways:
- Top-Down Design is Key: Always start with business goals and constraints to drive technical decisions.
- Translation is a Process: Business goals are translated into functional needs, which are then defined as specific, measurable technical requirements.
- The Document is the Blueprint: Your technical requirements document is not just a preliminary exercise; it is the primary reference you will use to justify your VLAN plan, your IP addressing scheme, your security policies, and your hardware choices.
Preview of the Next Lesson:
With your technical requirements document in hand, you are ready for the next logical step. In the next lesson, you will produce a complete VLAN plan based on the technical requirements you just created. The requirements for segmentation and isolation will directly inform how you structure your Layer 2 domains.