Verifiability is necessary for a requirement but there are other important issues. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized.
==== Requirements analysis or Requirements engineering====
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous [[software inspection|inspection]] have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues.
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they
#take a long time to produce
#limit the implementation options available
#are costly to produce
=== Documenting requirements ===
Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system shall do. Example: 'The contractor shall deliver the product no later than xyz date.' Other ways include [[use cases]] and [[user stories]].