Abstract
hen collecting requirements for software, designers may learn of needs for specific forms of protection to be present. These needs may be translated into requirements for encryption or authentication, but what about the non-obvious aspects of security - including privacy, auditability and assurance - that are usually overlooked in the requirements capture process? When we overlook these issues, we get software that doesn't deserve our trust. In this paper, I discuss some of the aspects of security that are regularly overlooked by designers and suggest some standard questions that should be addressed in every design
