Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What does a good security requirement for an application look like? I am talking about functional as well as non-functional security requirements here.

For traceability reasons I consider it important that the requirement is fully testable. I also want it to be technology-independent. What else is considered important for a good security requirement?

share|improve this question
up vote 4 down vote accepted

Testability is the key, and certainly helps get the QA teams buy-in if they have something to test to.

I have a slightly twisted viewpoint on requirements, as I like the idea of anti-requirements. Most requirements state what the system shall/can/may do. Anti-requirements specifically state things that the system should not do, and sometimes it is useful to think that way and capture those.

e.g. there tends to be requirements along the lines of The system shall have a mechanism for expiring passwords after a period of time.

Though there is rarely the anti-requirement The system shall not be accessible through the use of an expired password.

but it is implied in the first.

share|improve this answer

This is a very general question so bare with me... I view requirements as "goals" that I want my software/hardware/whatever to meet. Thus I feel that a good requirement follows the same philosophy as a good goal. S.M.A.R.T.E.R is the golden standard.

Of course some things like "Time Based" don't always fit.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.