Building Security In

usability, and, of course, security. An earlier contribution to this department stressed the importance of going beyond functional requirements. The authors introduced misuse or abuse cases as counterparts to use cases and explained that although use cases capture functional requirements, abuse cases describe how users can misuse a system 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 assume a fixed budget is assigned to security measures but that budgetary constraints apply to the project as a whole. We believe it’s reasonable, and often necessary, to trade functionality 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.