Capstone 1: Requirements and Design

Capstone 1: Requirements and Design

What you'll learn

• Read a client brief the way a network designer reads it: facts, wishes, constraints, silences
• Turn business statements into testable network requirements, and record the assumptions you had to make
• Choose a topology and a device list you can defend against a stated budget
• Apply the addressing method at /22 scale — including the arithmetic that lives above the third octet
• Write segmentation rules that make "guest is isolated" and "cameras cannot reach the Internet" enforceable rather than hopeful
• Say precisely what a dual-stack IPv6 design would change, and what it would not

This is where Dr. Tahseen Al-Doori's Network Essentials comes together as one piece of work. The whole book has been walking toward this: Chapter 1 gave you topologies and the VLAN thought experiment, Chapter 4 the components and the switch's mind, Chapters 5 and 6 the TCP/IP suite with addressing, subnetting and routing, Chapter 7 the Ethernet ladder, Chapter 8 wireless, Chapter 9 the wide-area edge — and Chapters 10 through 15 the tools, discipline and security thinking you will spend Lesson 3 applying. The course has taken those chapters apart, chapter by chapter, and modernized them to 2026. This module puts them back together in the only way that proves you own them: by designing a network that a real business could run on.

One warning before the brief, and it is the friendliest one in the course. This lesson does not contain the answer. It contains the method, the checkpoints, and a fully worked example on a different client so you can see the technique in motion. The plan for Meridian Architects is yours to produce. That is not a teaching trick — it is the actual job. Nobody will ever hand you a network design with your own client's numbers already filled in.

The brief: Meridian Architects

Read it twice before you read anything else.

The full brief, with the client's own wording, the floor sketch and the questions the account manager already asked, is in Download: Capstone Requirements Brief. Print it. Designers annotate briefs; they do not scroll them.

How a designer reads a brief

A brief contains four kinds of sentence, and the first professional act is sorting them.

Facts are countable: twelve workstations, two cameras, one NAS, five VLANs, one public IP. Facts become rows in your tables.

Wishes are the client's language for an outcome they cannot specify technically. "Design workstations need the fastest available wired path to the NAS" is a wish. It does not say a speed, a standard or a cable category — it says do not make my architects wait. Your job is to convert it into something you can build and measure.

Constraints are the walls of the room you must design inside. One managed switch per floor. One router/firewall. Two access points. One public IP. Constraints are not obstacles to be argued with in the first draft; they are the shape of the problem. A design that ignores the budget is not a bold design, it is an unusable one.

Silences are the most valuable sentences in any brief, because they are not there. This brief never says where the NAS physically sits. It never says whether the design team and the business team should be able to reach each other. It never says how camera footage is stored, or who may print, or what happens to a remote worker's traffic once the tunnel is up, or how many guests to expect on a busy day. Every silence is a question you would ask the client — and, when the client is unavailable, an assumption you write down in the design document, visibly, so that the person reading it later knows exactly which decisions were yours.

An assumptions section is not an admission of ignorance. It is the mark of someone who has designed before. It reads like this:

Notice what that sentence does: it records the number, its reasoning, and the trigger that would invalidate it. Three lines, and the next engineer inherits your thinking instead of guessing at it.

There is one small reconciliation waiting in this brief, and finding it is part of the exercise: the studio has 25 people on payroll, and if you total the staff seats in the device inventory you will not reach 25. Real briefs are never perfectly tidy. Count carefully, decide what you believe about the difference, write it as a numbered assumption, and size accordingly — because sizing against the wrong number is the one error that survives every later check.

The requirements register

The bridge from brief to design is one table, and everything downstream hangs off it. Each row takes a sentence the client said and turns it into something a technician can test.

Two rows, and already the design is being decided by the requirements rather than by taste. Note the discipline in column 5: a requirement you cannot test is a wish that got dressed up. "Guest traffic is isolated" is untestable prose. "A host in the guest segment cannot ping 10.42.x.y" is a test with a pass and a fail.

Your register will be longer — expect twelve to twenty rows once you have mined the silences. Number them (R-1, R-2, …), because Lesson 2's verification checklist and Lesson 3's dossier both refer back to these numbers. Traceability from a client's sentence to a passing test is the difference between a network you built and a network you can defend.

Topology: choosing a shape and defending it

Module 1 gave you the vocabulary — bus, ring, star, mesh, hierarchical — and Module 3 gave you the reason the answer is almost always the same in 2026: the extended star (also called hierarchical star), in which every device connects to a switch and the switches connect to one another and to a routed edge. Two floors, one managed switch each, one router/firewall means the shape is nearly dictated: two stars joined by a single link, with the router at the top.

That does not make the topology section of your document a formality. Three real decisions live inside that shape:

Where the joint goes. The link between the two floor switches carries every conversation that crosses floors. It is a single point of failure and a single point of congestion. Your document should say which switch ports it uses, what speed it runs at, and what happens when it fails — even if the honest answer at this budget is "the floors are isolated from each other and from the Internet until it is repaired; spare cable and a documented port map make that a twenty-minute fix." An honest weakness, written down, is engineering. An unmentioned weakness is a liability.

Where the router attaches. With one router/firewall and two switches, the router hangs off one switch, and traffic from the other floor reaches the Internet by crossing the inter-floor link first. That asymmetry is worth a sentence and a diagram arrow, because it changes which floor suffers most when the joint is congested.

Where the NAS lives. This is the brief's most interesting design question and it is deliberately unanswered. The design team moves large CAD files to the NAS constantly. Every one of those transfers either stays inside one switch — where it competes with nothing but that switch's own backplane — or crosses the inter-floor link, where it competes with every other conversation between floors, including everyone's Internet traffic.

The concept underneath is oversubscription: the ratio between the traffic that could arrive at a link and the capacity the link actually has. Twelve gigabit workstations feeding a single gigabit uplink is a 12

oversubscription, and it is completely normal — until those twelve machines all push multi-gigabyte files at once, at which point the uplink becomes the studio's bottleneck and the architects start complaining that "the network is slow." Every design has oversubscription somewhere. Good design puts it where the traffic is smallest.

You have three levers, all inside the budget: locality (put the heaviest talkers and their destination on the same switch, so the traffic never touches the uplink), link speed (many small-business switches offer one or two multi-gigabit or SFP+ uplink ports precisely for this), and cable category (Module 3's ladder: the drop to the NAS and the inter-floor run should not be the weakest link in the path). Choose, and write your reasoning in the document. There is more than one defensible answer here; there is no defensible silence.

Device selection against a real budget

The constraint is one managed switch per floor, one router/firewall, two access points. That is a bill of materials with four lines and no room for a mistake. Here is what each line has to satisfy — and the questions your document must answer for each.

The switches must be managed. Not a preference: an unmanaged switch cannot create a VLAN, cannot tag a frame, cannot carry a trunk. Five required segments make managed switching a hard requirement, and R-1 and R-2 make it a security requirement. This is the single sentence that justifies the price difference to a small-business owner: an unmanaged switch cannot separate your guests from your project files, at any price.

Port count is arithmetic, not intuition: count the drops on that floor, add the uplink to the other switch, add the router link if it lands there, add ports for the AP, the printer, the cameras, the NAS or server if they live on that floor — and then add headroom. The professional rule is to leave roughly a quarter of the ports free on day one. Growth arrives as devices before it arrives as budget.

Power over Ethernet (PoE) is the line most beginners forget. Access points and IP cameras are usually powered over their data cable, which means either a PoE-capable switch or separate injectors. Both are legitimate; they cost different amounts and fail differently. Your document should state which you chose, count the powered devices, and confirm the switch's PoE budget covers them with room to spare.

The router/firewall must speak 802.1Q. With five VLANs and one router, inter-VLAN routing happens either on router subinterfaces over a single trunk — the arrangement traditionally called router-on-a-stick — or on a layer 3 switch. The brief's budget names a router/firewall, so subinterfaces are the natural reading, and Lesson 2 builds exactly that. Note the consequence in your document: all inter-VLAN traffic crosses that one trunk twice (in and back out). If a segment pair needs high-volume traffic between them, keeping them in the same VLAN — or accepting the trunk cost knowingly — is a design decision, not an accident.

The access points must support multiple SSIDs mapped to VLANs, and WPA3. One physical AP broadcasting a staff network and a guest network, each landing in a different VLAN, is standard 2026 small-business hardware. Two APs for two floors is thin coverage but plausible for a small building; Module 6's site-survey habits tell you how to place them and what to check after installation. If coverage in the far meeting room turns out to be poor, that is a documented finding for the client, not something to hide.

The addressing method at /22 scale

You have designed an addressing plan before: Module 4's four-department office, carved out of a single /24. The method is identical here. Only the block is bigger, and bigger blocks bring one new mechanic.

Extend the sizing ladder upward. You know the /24-and-below rows cold. Add the two above:

Working above the third octet. Everything wider than a /24 borrows bits from the third octet, and the alignment rule from Module 4 applies there exactly as it applied in the fourth. A /23 spans 512 addresses — two consecutive third-octet values — so it may begin only where the third octet is even. A /22 spans 1,024 addresses — four consecutive third-octet values — so it may begin only where the third octet is a multiple of 4. The block-size trick is the same one you already use: subtract the mask octet from 256. For /23 the third mask octet is 254, so the block size is 2. For /22 it is 252, so the block size is 4.

Two consequences you will use in the next hour. First, scoping your own block is step one of the plan: from the prefix alone you can state its first address, its last address, and its total capacity, and everything you allocate must fall inside those walls. Second, when an allocation reaches the end of a third-octet value, the next address is not "the one after .255" — it rolls into the next third octet, and the counting continues without interruption. Addresses are one long number; the dots are punctuation for humans.

A worked example — Riverbend Community Library. Different client, different shape, same method. This is not your answer; it is the technique with the lid off.

Step 1 — scope the block. Third mask octet 252 → block size 4 → the /22 beginning at third octet 8 spans third octets 8, 9, 10 and 11. So the block runs 172.20.8.0 through 172.20.11.255, 1,024 addresses. Nothing may be allocated outside those walls.

Step 2 — size each segment. Add one address for the gateway, then find the floor on the ladder:

Step 3 — allocate largest-first, respecting alignment:

Watch the roll-over: the Public /24 ends at 172.20.8.255, and the next available address is 172.20.9.0 — a new third octet, no gap, no magic. Free space runs from 172.20.9.80 all the way to 172.20.11.255: 688 addresses in one contiguous run (1,024 in the block, less the 336 allocated), exactly as the largest-first rule promises.

Step 4 — verify before anyone configures anything. Alignment: 172.20.8.0 is a valid /24 start; 172.20.9.0 is a multiple of 64 in the fourth octet; 172.20.9.64 is a multiple of 16. Overlap: sorted by network address, each broadcast is below the next network (…8.255 < …9.0 ✓, …9.63 < …9.64 ✓). Containment: every address used is inside 172.20.8.0–172.20.11.255 ✓.

Step 5 — decide address policy, not just ranges. A plan that stops at "here are the subnets" is half a plan. For each segment, state which addresses are static (gateways, servers, printers, cameras — anything other devices must find by address), which are handed out by DHCP and between which two addresses the pool runs, and which are reservations (DHCP, but always the same address for a given device). At Riverbend the catalog servers are static, staff and public PCs are DHCP, and the two staff printers are reservations. Then write the excluded ranges explicitly: every static address must sit outside the DHCP pool, or you have designed a duplicate-address incident for some future Tuesday.

That is the entire method. Now run it on 10.42.0.0/22, with five segments, growth, and a device inventory you have to build yourself.

One genuine judgment call is waiting for you, and it has no single right answer — which means your document must argue. A /22 holds 1,024 addresses; the studio has fewer than fifty devices even after growth. You can size every segment tightly and leave a vast contiguous reserve, or you can allocate generously — clean, memorable, octet-aligned boundaries that a technician can read at a glance — and still finish with room left. The first optimizes for space you will never need; the second optimizes for the humans who will operate this network at 2 a.m. Say which you chose and why. That paragraph is worth more than the tables around it.

Segmentation: five VLANs and two hard rules

The brief names the segments; it does not explain them. Explaining them is your work, because a VLAN without a stated purpose becomes a VLAN nobody dares change.

• VLAN 10 Design. Twelve heavy users today, twenty after growth, plus their path to the NAS. This is the segment that drives the bandwidth conversation and the growth arithmetic.
• VLAN 20 Business. Six laptops handling contracts, invoices and correspondence — smaller, quieter, and holding the studio's most sensitive non-design data.
• VLAN 30 Servers. The DHCP/DNS/file server and the NAS: the two devices every other segment depends on. Static addressing, tightest change control, and the segment whose failure is everybody's failure.
• VLAN 40 Guest. Visiting clients. Untrusted by definition — not because visitors are hostile, but because you cannot patch, inspect or vouch for their laptops.
• VLAN 50 Cameras. Two entrance cameras. Small, silent, and — as Module 7 taught — exactly the class of device that ships with weak default credentials and firmware nobody updates.

Hard rule 1 — guest reaches nothing internal. A separate VLAN alone does not deliver this. A VLAN is a layer 2 boundary; the moment your router performs inter-VLAN routing, it will happily route guest packets to the Design segment unless you tell it not to. Isolation therefore takes three cooperating measures, and your document should name all three: an explicit deny rule at the routed edge covering guest-to-any-internal traffic, positioned before any permit; client isolation on the guest SSID so guests cannot even reach one another; and separate DHCP and DNS service for the guest range so it never needs to consult an internal server. Module 7's rule applies: default deny, then permit only what the requirement names — here, the Internet and nothing else.

Hard rule 2 — cameras never reach the Internet. Two mechanisms, and the difference between them matters. Excluding the camera range from address translation means camera packets have no valid public source address, so replies could never come back — real, but it is a side effect of NAT rather than a control, and it evaporates the day someone adds a translation rule or the network gains IPv6. The control is an explicit outbound deny rule for the camera range at the routed edge. Configure both; rely on the rule. And write the corollary into your document: if the cameras must record to something, that something lives on the Servers segment and appears as a single narrow permit — one source range, one destination address, one service — not as a general opening.

The rest of the reachability question is genuinely yours to decide, and this is the document's most consequential table. Does Business reach Design? Does anyone reach the cameras to view footage, and from where? Does the Servers segment need outbound Internet access for updates? For each ordered pair of segments, write permit or deny and one line of justification. That table becomes Lesson 2's ping matrix directly: every cell you wrote is a test somebody will run against your build.

Remote workers are the last piece and the easiest to forget. Three people, two days a week, and one public IP. The public IP means you will not be exposing the NAS to the Internet — Module 7 was blunt about what happens to file services published directly to the world. The remote-access answer is a VPN terminating on the router/firewall, and the design question it raises is an addressing question: which addresses do tunnelled clients receive? A small dedicated range, kept outside every DHCP pool, is the conventional answer, and it has a security benefit — remote clients are identifiable by address, so the reachability table can treat them as their own row instead of pretending they are on the office LAN.

IPv6: what would change, and what would not

The brief specifies a private IPv4 range, so your plan is IPv4. But no 2026 design document is complete without a paragraph on the other protocol, and the exercise of writing it will teach you more about your own IPv4 assumptions than another subnetting table would. Module 4's IPv6 lesson is your reference; here is the shape of that paragraph.

Addressing arithmetic disappears. An ISP delegates a prefix — commonly a /56 or /48 — and every ordinary segment gets a /64, always. There is no sizing ladder, no host-count-to-prefix calculation, no "will 62 addresses be enough." The design work moves from how big to which subnet ID, and the convention that saves lives is to make the subnet ID echo the VLAN number, so that VLAN 30 lives in subnet 30. Your addressing table becomes shorter and more readable, not longer.

NAT disappears — and takes an accidental safety net with it. With IPv4 and one public address, every internal device is unreachable from outside simply because it has no public identity. Under IPv6, devices can hold globally routable addresses, so the firewall becomes the entire boundary. Read hard rule 2 again in that light: the camera segment's protection can no longer lean on a NAT exclusion, because there is no translation to exclude it from. The explicit deny rule must exist in the IPv6 policy too, or the rule you thought you had enforced silently stops being enforced on the day the ISP turns on IPv6. This is the single most important sentence in your IPv6 section, and it is the mistake real networks make.

A defensible IPv6 choice for cameras is to give that segment unique local addresses only — the fd00::/8 space from Module 4 — and no global prefix at all. A device without a globally routable address is not reachable from the Internet and cannot reach it, by construction rather than by rule. Design by structure beats design by policy wherever structure is available.

What does not change: VLANs, because segmentation is a layer 2 mechanism and layer 3 has no opinion about it; the reachability table, which is policy and survives any addressing scheme; DNS, which gains AAAA records beside its A records; and every physical decision in your topology.

What is new to watch: hosts may configure themselves by SLAAC from router advertisements rather than waiting for a server, so the guest segment needs router-advertisement protection (rogue RA guard) the way an IPv4 network needs rogue-DHCP protection; and running dual stack means every policy exists twice, so every firewall rule you write has a twin, and a rule tested only on IPv4 is a rule half tested.

Two paragraphs and a decision — that is all your document owes IPv6 at this level. What it must not do is omit it.

Project: the Meridian design document

This is the deliverable. Lesson 2 builds from it; Lesson 3 audits it. Work on paper or in a document editor — no simulator yet, and resist the urge to open one. Designing while configuring is how networks acquire their permanent strangeness.

Objective. Produce a complete, defensible design document for Meridian Architects that satisfies every stated requirement, records every assumption, and can be handed to a competent stranger who could build it without asking you a question.

Setup. The brief above (or Download: Capstone Requirements Brief). Download: Capstone Design Template, which contains every table below pre-formatted. Your Module 4 sizing ladder and Module 8 documentation templates. A pencil and an eraser: the first allocation is never the last.

Steps.

1. Sort the brief. Mark every sentence as fact, wish, constraint or silence. Facts and constraints go into your tables immediately. Wishes go into the requirements register as translations. Silences go into the assumptions list — number them A-1, A-2, and give each a reason and an invalidating trigger.
2. Build the requirements register. One row per requirement, with the five columns shown earlier, numbered R-1 onward. Do not stop until every wish and every silence has produced at least one testable row. Expect twelve to twenty rows.
3. Inventory every address consumer. Not people — addresses. Workstations, laptops, wireless displays, printer, NAS, server, cameras, access points, switch management addresses, router interfaces, the estimated guest population, the VPN client range. This inventory is the input to every sizing decision, and Module 4's warning applies at full force: the count that omits infrastructure is the count that overflows.
4. Scope the block. From 10.42.0.0/22 alone, state the first address, the last address and the total capacity, and show the block-size arithmetic that proves it. Every later table must fit inside those walls.
5. Size the five segments. One row per VLAN: devices today, infrastructure, growth allowance, total, chosen prefix, usable count, spare capacity. Apply the growth requirement where it belongs — and think about whether growth belongs only where the brief mentions it.
6. Allocate largest-first. Produce the addressing table: VLAN, name, network address, prefix and mask, first and last usable host, broadcast, gateway. One gateway convention, applied without exception.
7. Write the address policy. Per segment: static addresses (which devices, and why they must be static), DHCP pool start and end, excluded ranges, reservations, and lease duration with a reason. Guest leases and Design leases should probably not be the same length; say why.
8. Draw the three documents. Module 8's set, at studio scale: a physical topology (floors, closet, rack, device placement, cable runs, the WAN handoff), a logical topology (VLANs, subnets, gateways, where DHCP and DNS live, the routed edge and its Internet path), and a wiring schematic for at least one floor (jack, room, patch panel port, switch port, VLAN, cable type).
9. Write the bill of materials. Every device you are buying, with the requirement number that justifies it, and a note on port count, PoE and uplink speed. Confirm in one sentence that the list obeys the budget constraint.
10. Build the reachability table. Every ordered pair of segments, plus the Internet and the VPN client range, marked permit or deny, each with a one-line justification. R-1 and R-2 must appear in it verbatim.
11. Write the IPv6 section. Two paragraphs: what changes, what does not, and the explicit statement of how hard rule 2 would be enforced without NAT.
12. Write the risks and growth section. Where is the oversubscription? What is the single point of failure? What is the first thing that breaks when the studio hires eight designers — and does your plan already survive it? What did you assume, and what would change if the assumption were wrong?

Deliverable. One document containing: brief summary and scope · assumptions · requirements register · device and address inventory · block scoping · segment sizing · addressing table · address policy · physical topology · logical topology · wiring schematic · bill of materials · reachability table · IPv6 section · risks and growth. Ten to fifteen pages. It should be readable by the studio's owner and buildable by a technician who has never met you.

Verify. Run these checks before you call it finished. Each one catches a class of error that is expensive to find later:

• Alignment. Every network address is a multiple of its own block size, in whichever octet the boundary falls.
• Overlap. Sorted by network address, every subnet's broadcast is strictly below the next subnet's network address.
• Containment. No address anywhere in your plan falls outside 10.42.0.0/22's first and last address.
• Completeness. Every device from step 3 appears in exactly one segment, and every VLAN in the brief appears in your tables.
• Capacity honesty. For every segment, state the spare capacity after growth. Any segment below roughly 30% spare needs a written justification or a bigger prefix.
• Policy coverage. The reachability table has a cell for every ordered pair — no blanks. Guest-to-internal reads deny in every row. Cameras-to-Internet reads deny.
• Static/DHCP disjointness. No static address falls inside any DHCP pool. Check this twice; it is the most common self-inflicted wound in small networks.
• Testability. Every row of the requirements register has something in the "verified by" column that a person could actually run.
• Buildability. Hand it to a classmate. If they can ask you a question you have to answer verbally, the answer belongs in the document.

If it goes wrong.

• Your segments do not fit. They will fit — a /22 is generous for 25 people. If they do not, you have almost certainly sized against total addresses instead of usable hosts, or allocated smallest-first and fragmented the block. Re-sort largest-first and re-allocate from the block's first address.
• You cannot decide how big the Design segment should be. That is the right feeling; the brief made it a judgment call. Write both candidate sizes, the argument for each, and pick one in writing. A recorded decision with a reason is a professional artifact; an unrecorded one is a mystery for the next engineer.
• The reachability table takes longer than the addressing. Correct. Addressing is arithmetic; policy is judgment. The table is the part a client will actually read.
• You find yourself designing around a device you have not counted. Go back to step 3 and add it. Then check whether your sizing still holds. This is precisely why the inventory is a numbered step rather than an assumption.
• You want to configure something. Save the impulse for Lesson 2 — and notice it. The urge to skip design is the reason most small networks are the way they are.

Check yourself

1. A colleague reviewing your draft says: "Cameras and the printer are both boring devices with no user sitting at them — put them in the same VLAN and save yourself a subnet." Give two distinct technical arguments against, drawn from this lesson's segmentation rules.
2. A different client's segment must hold 400 devices plus a gateway, inside a /22 that begins at 10.90.16.0. What is the smallest prefix that fits, and at which third-octet values inside that block may such a subnet legally begin?
3. The studio's owner asks why the quote lists managed switches when "a switch is a switch and the cheap ones are a third of the price." Answer in three sentences, at least one of which cites a requirement from the brief.
4. Your first draft puts the NAS on the opposite floor from the design team. Explain, using the word oversubscription, what the architects will experience on a busy Thursday — and name the two levers available to you within the stated budget.
5. Six months after go-live, the studio's ISP enables IPv6 and the router acquires a delegated prefix. Which of the brief's two hard rules is in danger, why exactly, and what single design decision would have made it safe by construction?
6. A junior colleague's addressing plan places a static NAS address inside the Servers DHCP pool. The network works perfectly for three weeks. Explain what changed in week four, and which verification check would have caught it in thirty seconds.
7. Your assumptions list estimates 15 concurrent guests. The studio then announces a monthly open evening for 40 visiting clients. Which parts of your document must change, and which parts do not?

Answers

1. First, blast radius: the cameras are the network's least trustworthy devices — weak default credentials, rarely patched firmware — and putting them in a VLAN with a device that internal users must reach means a compromised camera can reach whatever the printer's VLAN can reach. Second, policy collision: hard rule 2 requires an outbound deny for the camera range, but the printer's VLAN may legitimately need outbound access for firmware or cloud print services; one VLAN cannot hold two contradictory policies, so you would have to weaken one of them. A shared VLAN also means shared broadcast domain, so the cameras' traffic and any misbehavior reach the printer's segment directly.
2. 401 addresses needed → /23 (510 usable; a /24's 254 is short). A /23 spans 512 addresses, so its block size in the third octet is 2 and it may begin only at even third octets. Inside the /22 starting at 10.90.16.0 — which spans third octets 16 through 19 — the legal /23 starts are 10.90.16.0 and 10.90.18.0.
3. An unmanaged switch cannot create VLANs or carry tagged traffic, so it physically cannot keep the guest network separate from your project files — the brief's own requirement that guest traffic must not reach any internal segment. It also cannot be monitored, cannot report a failing port, and cannot carry the trunk that lets both floors share the same five networks. The price difference buys the one feature this design cannot be built without.
4. Every CAD transfer crosses the inter-floor link, so twelve workstations' worth of large-file traffic contends for a single uplink alongside all cross-floor and Internet traffic — heavy oversubscription concentrated on the busiest path, experienced by users as "the network is slow" during exactly the hours it matters. The two budget-compatible levers are locality (relocate the NAS to the design team's switch so the transfers never touch the uplink) and uplink speed (use the switches' multi-gigabit or SFP+ uplink ports, with cabling to match, so the joint is wider than the traffic).
5. Hard rule 2 — cameras must not reach the Internet. If that rule was enforced mainly by excluding the camera range from IPv4 translation, IPv6 has no translation to exclude it from: cameras acquiring global addresses become both reachable and capable of reaching out, and nothing in the configuration says otherwise. The design decision that makes it safe by construction is giving the camera segment unique local addresses only, with no global prefix — a device with no globally routable address cannot use the Internet regardless of what any rule says. (Writing the explicit IPv6 deny rule is the policy answer; the ULA choice is the structural one.)
6. In week four the DHCP server's pool allocation finally reached that address and handed it to a laptop, producing a duplicate-address conflict: the NAS and the laptop both claim it, and the NAS becomes intermittently unreachable in a way that looks random. The static/DHCP disjointness check catches it — compare every static address against every pool's start and end, and confirm each static address is in an excluded range.
7. Change: the guest segment's sizing row (40 plus headroom exceeds a 15-device estimate), its prefix if the new size no longer fits, the DHCP pool boundaries and probably the lease duration, and the assumption A-3 entry itself with its new reasoning. Do not change: the VLAN numbering, the reachability table (guest still reaches nothing internal — the policy is size-independent), the topology, the bill of materials, or the IPv6 section. That asymmetry is the point of separating structure from sizing.

Key terms

• Requirements register — the numbered table translating each business statement into a testable network requirement with a verification method.
• Assumption (recorded) — a decision made in the absence of client input, written down with its reasoning and the condition that would invalidate it.
• Constraint — a stated limit (budget, hardware count, one public IP) that defines the shape of an acceptable design.
• Oversubscription — the ratio of potential offered traffic to the capacity of the link carrying it; every design has it, good design places it where traffic is light.
• Locality — placing heavy talkers and their destination on the same switch so their traffic never crosses an uplink.
• Bill of materials — the device list, each line justified by a requirement number.
• PoE budget — the total power a switch can supply across its ports, checked against the number of powered devices.
• Router-on-a-stick — inter-VLAN routing on router subinterfaces over a single 802.1Q trunk.
• Block scoping — deriving a block's first address, last address and capacity from its prefix before allocating anything.
• Address policy — the per-segment statement of what is static, what is DHCP, what is reserved, what is excluded, and how long leases last.
• Reachability (policy) table — permit/deny for every ordered pair of segments; the source of the build's ping matrix.
• Client isolation — an access-point feature preventing wireless clients on the same SSID from reaching one another.
• VPN client pool — the address range issued to tunnelled remote users, kept outside every DHCP scope so policy can name it.
• Prefix delegation — the ISP handing an IPv6 prefix (commonly /56 or /48) to a customer router for internal subnetting.
• Subnet ID — the field within a delegated IPv6 prefix that identifies a segment; conventionally set to echo the VLAN number.
• Unique local address (ULA) — IPv6 private space (fd00::/8); a segment with only ULA addressing has no Internet reachability by construction.
• Dual stack — running IPv4 and IPv6 simultaneously; every policy exists twice and must be tested twice.

Summary

• A brief contains facts, wishes, constraints and silences; the silences become numbered assumptions, each with a reason and an invalidating trigger.
• The requirements register turns the client's sentences into testable requirements, and its numbers travel forward into the build's verification and the final dossier.
• Two floors, two managed switches and one router/firewall dictate an extended-star topology — but leave three real decisions: where the inter-floor joint runs, where the router attaches, and where the NAS lives.
• Oversubscription is unavoidable; locality, uplink speed and cable category are the budget-compatible levers for putting it somewhere harmless.
• The addressing method is Module 4's, extended above the third octet: block size 2 for a /23, 4 for a /22; scope the block first, size with the gateway counted, allocate largest-first, then verify alignment, overlap and containment.
• A plan is not finished at subnet boundaries: address policy — static, DHCP pool, exclusions, reservations, lease length — is half the document, and static addresses inside DHCP pools are the classic self-inflicted outage.
• Guest isolation needs three cooperating measures (edge deny rule, client isolation, separate DHCP/DNS); the camera rule needs an explicit deny, with NAT exclusion as reinforcement rather than as the control.
• Under IPv6 the sizing arithmetic vanishes and every segment is a /64 — but NAT's accidental protection vanishes with it, so the camera rule must be written explicitly or built structurally with ULA-only addressing.

Next lesson

Design done, hands next: Lesson 2 takes your document into Packet Tracer and builds it stage by stage — devices, cabling, VLANs on both switches, the trunk between floors, inter-VLAN routing, DHCP per segment, translation to the single public address, and two wireless networks including the isolated guest SSID — with a verification gate at the end of every stage, because a build verified only at the end is a build you will be debugging all night.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 1, 4, 5, 6, 7, 8 and 9 — topologies and the VLAN thought experiment, network components, the TCP/IP suite, addressing and subnetting, the Ethernet ladder, wireless, and the wide-area edge; the capstone's design half synthesizes all of them.
• RFC 1918, "Address Allocation for Private Internets" — https://www.rfc-editor.org/info/rfc1918/ — why 10.42.0.0/22 is yours to design with.
• RFC 4632, "Classless Inter-domain Routing (CIDR)" — https://www.rfc-editor.org/rfc/rfc4632 — the prefix arithmetic behind every table in this lesson.
• RFC 4291, "IP Version 6 Addressing Architecture" — https://www.rfc-editor.org/rfc/rfc4291 — the /64 convention and the unique-local range behind the IPv6 section.
• IEEE 802.1Q, "Bridges and Bridged Networks" — https://1.ieee802.org/tsn/802-1q/ — the tagging standard that makes five VLANs on two switches possible.
• Download: Capstone Requirements Brief (the client brief in full, with floor sketch and account-manager notes).
• Download: Capstone Design Template (every table in this lesson, pre-formatted, plus the assumptions and risks sections).