3

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?

  • 4
    Someone 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..... – mattnz Oct 13 '13 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 Patterson Oct 13 '13 at 18:05
20

"A bug in requirements" could refer to one or more of the following (more may exists though...):

  1. 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.

  2. 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.

  3. The user passes a wrong business fact to the business analyst. Example: A wrong formula to calculate profit.

  4. The analyst captures wrong information or makes false assumptions and considers those as true requirements that need to be implemented.

  5. 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).

  6. 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.

11

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" ;)

-1

Well there might be two large cases:

  1. The requirements do not represent what exactly the business owner wants; they do not model the business flow.

  2. The requirements are not consistent; this can, or cannot be a consequence of 1.

  • 1
    I think 1 is a case of bad requirements, not a bug in the requirements. – Yosi Dahari Oct 13 '13 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? – m3th0dman Jun 15 '15 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.