specially assumptions). Here's an example requirements document: Requirement: The network must support 300 users. Assumptions: Each user will have one workstation. Each workstation will have only one Ethernet interface. All interfaces will be cabled for 1 Gpbs Ethernet. The network does not need to support 1 Gbps for all users at the same time. Each user will have one phone supporting one phone line. Chapter 33: Designing Networks All phones will be non-IP phones. VoIP will not be run on the network for the foreseeable future. Each user will equal one cube or office. Each cube or office will have two data jacks and one phone jack. All cabling runs will terminate into the computer room (home runs). When a VP says, "We need a network to support 300 users," he doesn't always understand the implications of this simple statement. Your job is partially to make sure that the other people involved have all the information they need to understand what's happening, and partially to cover your own butt should someone fail to understand what you're doing. If you publish all your assumptions, the VP should be able to read your document and pose any questions he may have. Perhaps there's a plan in the works to move the phone system to VoIP in the next year, and you need to be advised to order equipment that will support that vision. I've seen many projects fail because no requirements document was written. I've also witnessed (and been party to) many heated arguments about what was said months ago, but not put into writing. Just because people say they understand something, don't assume they do-espe- cially if they are not "technical" people. I once designed an elaborate Internet failover mechanism for a company. When the DS3s were being delivered (after a 60-day lead time), the VP who had signed the order for them started screaming at me because he didn't understand why we needed them. I'd never realized that he didn't understand the design. I had assumed we were all on the same page, but because I had not writ- ten a require