Using Defects to Define Requirements


I recently reviewed a new defect that described the current behavior of a product. It continues with a description of desired behavior based on learning (not on an existing requirement) about the current behavior. It seemed to suggest that since the desired behavior does not occur, there is a defect.

In my opinion, someone reviewed the current behavior, thought about it, and decided a new behavior is desired.

This would appear to be a classic application of an agile approach to building products. However, I would not prefer to see requirements defined in defect descriptions and would recommend using a story card instead. The story card, in our work environment, has more scrutiny on the definition, a broader audience for awareness and approval, and is usually the central place for researching product requirements.

What are your thoughts on using defect to define requirements?


In most roles I’ve been in, a defect which actually describes expected behaviour but then is informally agreed to require an enhancement to the app has to go through the “new feature”/“enhancement” business process. That is, a business case needs to be prepared (cross-referenced to the defect report), submitted to whoever has the responsibility for approving new features, and it is then subjected to the process of determining the business case, cost benefit analysis, and likely benefit to customers and company of the time, effort and expense of developing the enhancement.

If the behaviour that the “defect” report seeks to correct is radical enough, or the end effect of the enhancement sufficiently obvious, the business should be able to decide in its favour. But if the improvement is only marginal, or only fits one particular user, then the business is justified in saying “nice to have, but…”, or even “won’t develop”. If a single client has identified this as an “enhancement”, then perhaps the two businesses need to talk about a dedicated development effort - but the client will probably have to pay for an enhancement that only they are looking to use.

1 Like

As described, the change request is for requirements. So, as Robert says, it would go through your process for requirements changes, whether that’s a story card or some other documentation. It’s important to make sure that the change is technically consistent with other requirements, and that it is appropriately communicated to those who need to know. There is a business/management component here too: Nice to have “creeping features” have complicated and slowed projects sometimes.

1 Like

In agreement with the posts so far. Requirements management through defect entry is a dangerous road no matter what methodology is being used. Many times it’s being employed to work around the system in place to define and prioritize new work by marketing the enhancement as “correction” to existing work. It may not even be conscious on the part of whoever is asking for the change and hopefully a quick conversation regard the difference is sufficient.

Thank you all for your thoughtful answers! This was resolved and a story card was created. I feel that by pursuing this solution I helped maintain some level of quality in our work. In my role of Test Lead, I can be a Quality Advocate. What troubles me is the analyst who usually writes story cards would be satisfied with the defect or the story card. I believe influencing others around how processes impact quality still has some distance to travel.


In my world a defect recorded by a tester is usually assessed by someone managing (tracking) the defect log and it is often discovered that what has been reported as a defect may not be a defect.

Most if not all defects tracked are assessed by someone of authority that has the business/IT knowledge of the requirements and/or specifications. In many cases reviewing defects is a collaborative effort between the business user (customer) and an IT member. Ultimately the end-result should be addressing the customer needs. It’s determining what is in and out of scope for the assignment at hand.

The outcome of the review assigns defects into 3 categories: 1) an actual defect; 2) Issue; or 3) change request. Such that, a defect is: a) an actual defect, the requirements have not been met/something is broken; b) the software/product functions as designed and the requirements have been met but there is a need for an additional change (change request/future enhancement); c) the defect is actually an issue that can be managed by training or a change in the business process or workflow rather than changing the software/product.

1 Like

I personally like to think of a bug report as a start to a conversation, not the end of it - at least in all the agile projects I have part in. That’s why I get irritated if someone would me rather not log issues in formal system but instead “talk it over”. My current team for example had this tendency to talk about things very informally and skipping documentation altogether - now the team is facing losing a third of the developers, senior qa and both PO and assistant PO within 2 weeks total amd I noticed a bit of panic creeping in about not having enough in backlog to work over period of new PO getting up to speed, not having enough in backlog to get new programmers gently introduced to code base via fixing relatively easy yet low priority issues, and most critically of all - the problem discovery will probably take place all over again, because old decisions and motivations got discussed outside of any tool.

Well, but I am the senior qa leaving, and there’s only so many times I can say “I don’t agree” until I too loose patience…


I think there’s a case for a middle way here. If I find a bug in an app that’s still in development, I will talk to the dev first of all, but my last question is always “Do you want me to formally raise that as a bug?”

That way, the bug doesn’t come as a surprise to the dev, and they’ve had some thinking time about it, even if they can’t address it immediately. And as a result of the discussion, I can make the bug report better and more focussed; not being a techie person myself, all my bug reports are written from the point of view of a knowledgeable user, so the conversation with the dev tells me what technical details are essential to the report. Then again, that’s probably down to the sort of devs we have in our place.