To be successful, application software needs compelling functionality, availability within the right timeframe, and a reasonable price. But equally critical, teams must get nonfunctional characteristics right - performance, scalability, manageability, maintainability, usability, and, of course, security. The authors introduced misuse or abuse cases as counterparts to use cases and explained that although use cases capture functional requirements, abuse cases describes how users can misuse a svstem with malicious intent, thereby identifying additional security requirements. Another prior installment discussed how to fit misuse and abuse cases into the development process by defining who should write them, when to do so, and how to proceed. In this article, we discuss what abuse cases bring to software development in terms of planning. We don't assumes fixed budget is assigned to security measure's but that budgetary constraints apply to the project as a whole. We believe it's reasonable, and often accessary, to trade funtionality against security, so the question isn't how to prioritize security requirements but how to prioritize the development effort across both functional and security requirements.