AbstractSome basic lessons learned, some “heresies,” and some causes of requirement denial are presented with the goal of providing information and food for thought for persons interested in designing requirement management systems. These are based upon practical experience of the author and others.One of the major lessons learned is the advantage of the use of a limited number of analysis documents to control derived, implied, or budgeted requirements. A layered schema made up of alternating specification (hardware/software/process/test) layers and analysis layers has proved ideal for handling all types of requirements.The heresies are some challenges to current strongly held beliefs. Sample heresy is “Just because we can't test it doesn't mean it's not a requirement.”Requirement denial is something like, “That's not a requirement that's just an algorithm we're going to use to meet a requirement.” (The other side of the argument is “If you gotta do it, it's a