This may seem obvious but bear with me for a bit on this. As

we were discussing the benefits of using a tool to capture and manage

requirements the classic benefit, of course, was the idea that the earlier a

defect (in a requirement) is caught the less expensive the overall cost. I specify

"in a requirement" because there was this tendency, in our discussion, to just

say "defects" which could mean code defects or requirement defects. I mentioned

brought this up and everyone acknowledged this to be true.

But it got me to think about defects in requirements. A code

defect is fairly straight forward. Something in the code fails some test,

simple. The area becomes grayer when the developer logs it as "works per the Requirement"

or something to that effect. Question is, how did we get here? How can it work

per the Requirement but fail per QA. There could be several reasons. One being QA's test

case is not in line with the Requirement or that the requirement the developer

was working off changed and somehow QA caught wind of the change.

This problem is even worse and is more likely to be caught

not by QA but rather by the end user. This gets into the importance of showing

the end user the product in short iterations, but that's a different

discussion. Even with quick iterations the customer finding an issue is still

considered a defect in the requirement. Something we should accept as natural

and unavoidable. Regardless, analysis has been done, development has been done

and QA has tested all based on a defect in the requirement. Maybe defect is too

harsh a word. What we are truly capturing here are miscommunications or

misunderstandings.

Let's take a step further back for a moment from this moment

in time. Could we have caught this earlier?  The second scenario with the end user finding

the issue is more complicated. The issue with QA finding a bug is much easier

to fix. This is of course where a tool can help. (You saw it coming) Basically

this occurs when there is a breakdown in timely communications. If the

requirements changed the correct parties need to be made aware, simple as that.

I'd even argue that even if there is an inkling of a thought that it might

change all parties should be notified so they can brace themselves.

The more complex scenario of user found defects can be

reduced through constant communications, reviews, and discussions. Take for

example a requirement the customer has reviewed and "signed off". That should not

be the end of the story. It should be reviewed by QA and development, who can

then add comments and suggestions (openly without fear of retribution) such

that the customer can review and agree or disagree. Even as development is

developing they should feel free to add new revelations, screen shots demonstrating

ongoing progress etc. The term "signed off" should be stricken from our

vocabulary. Rather it should be "I'm happy with what I see today".

During a typical day an individual could be monitoring or

working with multiple meetings, requirements, task at any one point in time. So

for true collaboration between all these individuals you would either need a

single person with super human power to multitask, multi respond sitting in a

single room of computers, phones and postIt's, tracking and coordination every

discussion and every event for one project. Alternatively you could use a tool

that can handle thousands of notifications, discussions and events daily all

the while keeping a history of these events.

That's our vision.