lve a real or perceived problem that was ill-defined, and the real problem didn't go away. In severe cases, real problems can kill an organiza- tion before the learning curve catches up and a fix is found and put in place. Partial fixes can be deadly as well. Buying a DS-3 network interface card without an attendant upgrade of a T-1 to a DS-3 access facility doesn't relieve any of the pain of congestion for Inter- net users. If problem-solving enables successful computer programming, successful network and systems design relies on a well-defined state- ment of requirements. When real business needs drive communi- cations requirements, most problems are anticipated and avoided. The problem of having paid money for an ill-defined or undefined solution is avoided. Successful computer software and communi- cations network planning, design, and building start with definitions that ultimately enable predictable outcomes. Define what you want up front. If you have been asked to do something and given a requirement, you must read, understand, and think through how you would define the requirement. If you can see ways to improve the requirement, suggest or incorporate them into the requirement. If you are asked to undertake a task or implement a project, and a requirements document was not provided, document your under- standing of the requirement, hand it back to the requestor, and make sure that's what they want before setting forth to build or acquire. Lastly, it's not productive to extend this process. Sooner or later a point is reached where this step is complete and ready for the real work. Highly summarized, all organizations require communications cap- abilities beyond simple face-to-face and written communications. In modern communications network terms, that's phone service, com- puter communications, and, in the broadcast industry, capability to transport content during content creation, distribution, and delivery operations. PRACTICAL IP AND TELECOM FOR BROADCAST ENGINEERING AND OPERATIONS BUSINESS REQUIREMENT