Requirement Defect

Despite the delivered software has no bug, it is not uncommon for clients to ask for changes. This for me is a Requirement Defect. This corresponds to Validation activity of the V-model to ensure that software would be working and acceptable in its intended environment. Software Validation is implemented in Agile through product manager review.

The empowerment of the product manager in Agile/Lean world, please see this post here, demands that she takes responsibility on the hand-offs. Hand-off is a term used in Lean and means when moving an item from one stage to the next of the Value Stream, we should implement certain policies. Normally the stages of the Value Stream incorporate different skills, mind-sets and expectations. The hand-offs which can produce Requirement Defects are:

  • Client to business analyst
  • Business analyst to development team (including Testing)
  • Development team to business analyst
  • Business analyst to client for acceptance

The term bug is commonly used to indicate some technical failure (e..g. program abort, error in calculation…). A bug usually has a localized impact and it can be fixed by developer or support staffs. However, the impact of Requirement Defect can be pervasive and can mean re-design, or probably re-do the analysis.

I found that the term Requirement Defect in most cases is replaced by other terms, example enhancement or may be new feature. In Agile/Lean development model we target incremental delivery to clients, but the increment should be meeting client requirements though it’s incomplete.

The situation becomes more complex in maintenance which is driven by a ticketing system and the ticket is closed when the client accepted the software. Afterwards, we receive multiple tickets to address changes while not showing the link to the original ticket. For me this invalidates the measurement system and therefore provides misleading figures, for example:
– 3 new features, 5 defects could have been reported as 4 new features and 4 enhancements. Total is 8 for both reporting but the conclusion drawn is very different. The first reporting indicates 62.5% defects while second reporting is 0% defects! How we expect we can have meaningful improvement with this noise in the accuracy of measuring system?

Finally, I would argue that many enhancements and new features are in fact Requirement Defects. Requirement Defect has high impact and is caused from inadequate hand-offs. The situation is exacerbated in maintenance and hot fix setups which the client can’t tolerate incomplete delivery. In some Agile projects this is overly tolerated as it is being considered part of the incremental delivery rather than failure.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s