Software Best Practices

They both represent value gaps. A requirement describes a gap between the value our current system generates and the value we expect a new or updated system to generate. A defect report documents a gap in value when the system we implemented delivered less value than we intended it to.

But does the "to-be" nature of requirements make them fundamentally different than the "should-have" nature of a defect?

In common, though, is the demand for team time. That is, both the defect and the requirement are a request to have the team spend time modifying the work to behave/present itself in a different way. As a demand for time, they should go through the same resource scheduling process.

On a side note, doesn't every piece of work deliver less value than we desire? The fact that we generally have unlimited desire and limited resources suggests that reality will always suck a bit when placed against our imaginations. To say that a defect is a gap in value from intentions may suggest that any system, by definition of its existence, is defective.

I was just commenting on an interesting characteristic they have in common. I wasn't arguing that they are identical. That being said, I think the "value perspective" that they share is more fundamental than the "to-be"/"should-have" distinction. After all, once you select a defect to fix, it becomes a "to-be" activitiy.

Your comment about demand for team time is another interesting characteristic that requirements and defects share. Not only can we recognize their Value, but we can also recognize their Cost.

The question was really a way to initiate a discussion of what might be called Value Based Development. In short, activities that add no value to your business represent a true business loss. Every requirement should have a value based motivation. And every defect represents a negative economic impact.

Side note comments:

Sure, in an idealistic sense every piece of work fails to be perfect. So, you could certainly argue that they are all defective. But you can apply the same logic to requirements. An ideal requirement is unattainable. If you have an example of an attainable requirement, then you've already made the necessary compromises with reality. Apply that same attitude toward defects, and I don't see a problem.