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?
4Someone closed their requirements folder and a small fly got caught between pages. The programmer reading the requirement mistook the fly as a decimal point..... More often than not, its not a fly between the pages to blame.....– mattnzOct 13, 2013 at 7:43
@mattnz And when you find one, you're supposed to tape it down for posterity: en.wikipedia.org/wiki/File:H96566k.jpg– Ross PattersonOct 13, 2013 at 18:05
"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.
1I think 1 is a case of bad requirements, not a bug in the requirements. Oct 13, 2013 at 8:02
@Yosi In case a software system does not behave as intended you have a bad software system or bug(s) in it?– Random42Jun 15, 2015 at 8:49