I've just looked for a formal definition and haven't found one. The term - "bug in the requirements" was always confusing for me, what does mean exactly?
"A bug in requirements" could refer to one or more of the following (more may exists though...):
A requirement provided by the end-user that conflicts with another requirement or constraint. Example: The user wants to email all customers but does not want the system to collect customer emails.
A requirement provided by the user and not flagged by the business analyst as not feasible for a given project. Example, I want the system to automatically fix addresses of my million customers when the user pushes a button.
The user passes a wrong business fact to the business analyst. Example: A wrong formula to calculate profit.
The analyst captures wrong information or makes false assumptions and considers those as true requirements that need to be implemented.
An incomplete requirement provided to the business analyst that led to a bug in implementation. Example: The user says to the analyst "We only record a customer when a sale is made". A developer getting this requirement may end-up creating a DDL rule that makes the relationship of customer and invoice mandatory such that when an invoice is deleted the corresponding customer information is also deleted. Unless the developer and business analyst confirm with the user that this required, this searing may be considered as a bug in requirements (and development).
A bug in requirement could occur also when the user and the business analyst miss an entire business function. Example, when the user does not specify security requirement and the business analyst does not ask about this requirement. When such a system is completed, it may not be usable because it is not secure enough.
It means the requirements were wrong, somehow.
- missing something critical
- conflicting requirements
- incorrectly stated requirements
In non-technical language, this is also known as a "mistake" ;)
Well there might be two large cases:
The requirements do not represent what exactly the business owner wants; they do not model the business flow.
The requirements are not consistent; this can, or cannot be a consequence of 1.