Capstone Design Template
Fill this in before you build. A design document is not paperwork written afterwards to describe what you happened to do — it is what you argue with while changing your mind is still cheap. Every decision needs a reason traceable to the Requirements Brief; "that is how I have seen it done" is not one.
0. Cover
| Field | Your entry |
|---|---|
| Client / site | |
| Prepared by | |
| Date · version | |
| Brief version answered |
1. Requirements interpretation
One row per requirement in the brief, including the constraints and the two hard security rules. A row with no verification test means the test is missing.
| # | Business requirement (from the brief) | Network requirement (technical meaning) | How the design meets it | Verification test |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| … |
2. Topology choice
Chosen topology: Where routing between segments happens, and on which device: Why this over the alternatives (name one you rejected and what it would have cost or bought): The known weak point of this choice (every topology has one — where is the bottleneck or single point of failure?):
3. Device selection
Model class, not a shopping link — "8-port managed switch with 802.1Q and PoE", not a part number you cannot justify.
| Device role | Model class / features | Why this class | Where it sits |
|---|---|---|---|
4. Addressing plan
Sizing worksheet — show the arithmetic for every segment: hosts today, hosts after the growth in the brief, smallest h where 2^h - 2 covers that, prefix = 32 - h. Round up for headroom deliberately and say by how much. (The -2 is the network ID and broadcast of an ordinary LAN subnet. If your design includes a point-to-point router link, note that RFC 3021 /31 uses both addresses and needs no -2.)
| Segment | Hosts today | Hosts after growth | h | Prefix | Why this prefix |
|---|---|---|---|---|---|
Now the plan, one row per required segment. The first row is a worked example from a different network — format only. Its addresses sit outside the space you were given, so copying it fails every test.
| VLAN | Name | Network / CIDR | Usable range | Gateway | DHCP scope | Hosts needed | Headroom |
|---|---|---|---|---|---|---|---|
| 99 | Example-Only (other site) | 172.31.9.0/26 | 172.31.9.1-172.31.9.62 | 172.31.9.1 | 172.31.9.20-172.31.9.60 | 24 | 62-24 = 38 spare |
Static assignments — anything that must not move: gateways, servers, storage, printers, cameras, management. Keep them out of the DHCP scopes.
| Device | Segment | Address | Why static |
|---|---|---|---|
Self-check before you build: every subnet inside the allocated block · no overlaps · each subnet starting on a multiple of its own size · each gateway inside its own subnet · no DHCP scope containing a static · spare space written as CIDR blocks, not "whatever is left".
5. IPv6 considerations
If this site were dual-stacked tomorrow, what changes and what does not? Cover the prefix you would ask the provider for, how hosts would get addresses, whether your segmentation still holds, and what NAT is (and is not) doing for you in IPv6.
6. Growth plan
Absorbing the growth in the brief: which segment grows, by how much, does it still fit, and what physically changes (ports, cabling, wireless capacity)? Then: what runs out first if the studio doubles?
7. Risk and assumption log
Everything you assumed because the brief did not say, and everything you know is weak but chose to live with. A written assumption is professional; one left in your head is a defect.
| # | Assumption or risk | Impact if wrong | What you would do about it |
|---|---|---|---|
Network Essentials · Capstone · Turning Point Academy — backbone: Al-Doori, Network Essentials, Ch. 1-15.