rements statement will be complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable. If a requirement is necessary and verifiable, then we can define which set of users or interested parties requires or will benefit from that attribute. The technical requirements specification should have these qualities and also should be consistent, modifiable, and traceable. Modifiability and traceability allow the document to be changed and the sources of those changes to be traced to re- solve any future difficulties such as inconsistency or incompleteness. The process of gathering requirements from users and technical sources and creat- ing a requirements document is a huge topic in itself, beyond the scope of this book. The essential points are, first, only the customer knows what the customer wants, and sec- ond, a design cannot be improved if it is not clear and well defined in the first place. These points may seem obvious, but real-world experience of failed projects and exten- sive studies of why telecommunications and information technology (IT) projects fail in- dicate that we often do not take care of these basics. Based on the requirements, we design a new system or modifications to an existing system. As we make decisions during the design process and later in development or deployment, we must make tradeoffs. Before we look at quantitative models and the mathematics of tradeoff, a few practical rules of thumb might be useful. There are many cases where we cannot model a problem in a quantitative way, and we still need to make good decisions in those situations. Project managers have a saying: "You can have it quick, you can have it good, or you can have it cheap: Pick any two of the three." By this we mean that there is always a tradeoff among time, quality, and cost. Our options are limited by the constraints that reality imposes. One approach to such decisions is to look at each attribute and decide if it is a driver, a constraint, or a factor with a degree of freedom. When we have sever