Definition of a Requirement

IEEE给出的需求定义
First of all, what is meant by a requirement? Here is a typical definition drawn from IEEE-STD-1220-1998 (IEEE 1998):
Requirement: a statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines). 
This definition draws out a number of facets of a requirement that are briefly discussed here, and in greater detail later: 
• Statement. That a requirement should be a statement is perhaps biased towards textual expression, whereas they can also be captured in tabular form, such as in Tom Gilb’s Planguage (Gilb 2005), in diagrammatic form in notations such as UML (OMG 2003), in formal notations, such as Z (Spivey 1989), VDM (Jones 1986), LOTOS (Bjorner 1987) and the B-Method (Abrial 1996), or in domain-specific notations, e.g. (Chaochen et al. 1991). The important concept, though, is to have a set of traceable, manageable elements identified as requirements.
• Product or process. Complete solutions contain varying mixtures of product (things that are built in response to requirements) and process (procedures for using the things that are built). Requirements may therefore define process as well as product. In addition to this, there may be requirements that stipulate how the product should be developed, usually for quality control purposes.
• Operational, functional, or design characteristic or constraint. There are many different kinds of requirement, giving rise to different kinds of language, analysis, modelling, process and solution. Note that this definition has carefully avoided the term “non-functional,” since there is heated debate about what this actually means. Design characteristics cover performance, usability, safety, maintainability and a host of other qualities. 
• Unambiguous. A statement of requirement has desirable qualities that will be addressed in detail later. In brief, a requirement should lend itself to a clear,single understanding, common to all parties involved.
• Testable or measurable. Requirements are used to test that the design or solution is acceptable. For this to be possible, the requirement should be quantified, thus providing a means of “measuring” the solution against it. 
• Necessary for product or process acceptability. This highlights the multidimensional role that  requirements play: they serve to define what should be designed and developed, and also define how the solution should be tested and accepted. They have an influence in the earliest stages of the development process as well as in the latest stages during acceptance. 
• By consumers or internal quality assurance guidelines. Requirements come from many sources, including but not limited to customers, regulatory bodies, users and internal quality procedures