Requirements for Requirements

This text is not exactly mine. It is a very high-level abstract of what a book Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick, 2005 has to say on the subject of requirements for requirements.

So, how can we understand that your requirements are ok, or not ok? If they are another source of quality risks? To answer these questions, I've prepared some sets of criteria that we can use for assessment:
 

Process & project-related criteria

1. Is it possible to find information about workflow this way of the other ?
2. Do you know storage location(s) of requirements? Are they more than one?
3. Are requirements up-to-date?
4. Are requirements available (in the broader sense: existence, easiness to access, language barrier, general readability etc)

Requirements for requirements

State of requirements criteria

• Are requirements coherent (integrity) or contradictory?
• Can requirements be satisfied?
• Are requirements testable?

Criteria for the text of requirements

• Are requirements atomic?
• Is each requirement unique?
• Are requirements defined clearly? Do they allow more than one interpretation?
  
• Is text of requirements accurate?
• Are requirements abstract enough?
• Do requirements contradict any law?

Criteria for the sets of requirements

• Are requirements complete? Or is something missing?
  
• Are requirements consistent withing the given set of requirements?
  
• Are requirements redundant? Are there duplicates?
  
• Are requirements modular withing the set?
  
• Are requirement sets structured?