How did I miss that?
A few weeks ago, I was participating in a design review session for my current project. The visual designer was walking the project team through his UI mockups for a particular feature of the system. He asked us a question to clarify the functionality of one of the UI "widgets," which the business SME/sponsor answered, "It should [do X]."
Her answer didn't quite match up with the requirements she had recently approved, so I spoke up. "Well, that's not quite how you said it should work," I interjected. The group looked in my direction. "The requirements you just approved said that the system would allow the user to [do Y], but not [do X]. Is that not correct?" I asked.
Her reaction was a loud "How did I miss that?!?". My reaction was "How did I miss that?!?". We each couldn't believe that we hadn't seen the error (her miss) or seen the possible contradiction and asked a clarifying question (my miss). Our shared reaction got me thinking ... how can we make sure that we don't miss things in the requirements process?
And then I realized that that was the wrong question. We'll always miss something the first time around. Project schedules are short, the work is intense, and we're human. Something almost always slips through the crack, in spite of our efforts to the contrary. So the important question isn't how to prevent missed requirements (although we should structure our work to prevent those misses when possible), but how to catch them as part of the overall requirements process.
Requirements review and approval cycles are a great way to catch missed requirements, particularly if you have reviewers who haven't been deeply involved in the elicitation of the requirements. A fresh set of eyes always help spot the missing details. Peer reviews work well, too, since fellow Requirements Engineers know what to look for in a good set of requirements. Design sessions and walkthroughs can also be helpful, as was the case in my example above. Essentially, find a way to see the requirements in a new light, or from a different perspective, and the problems start to jump out at you.
The key is, no matter how you go about it, plan time to review the requirements in order to catch what's missed. Hopefully you'll find that nothing was missed! But if you do come across a missed requirement, remember that it's finding, not missing, the requirements that really matters!
Her answer didn't quite match up with the requirements she had recently approved, so I spoke up. "Well, that's not quite how you said it should work," I interjected. The group looked in my direction. "The requirements you just approved said that the system would allow the user to [do Y], but not [do X]. Is that not correct?" I asked.
Her reaction was a loud "How did I miss that?!?". My reaction was "How did I miss that?!?". We each couldn't believe that we hadn't seen the error (her miss) or seen the possible contradiction and asked a clarifying question (my miss). Our shared reaction got me thinking ... how can we make sure that we don't miss things in the requirements process?
And then I realized that that was the wrong question. We'll always miss something the first time around. Project schedules are short, the work is intense, and we're human. Something almost always slips through the crack, in spite of our efforts to the contrary. So the important question isn't how to prevent missed requirements (although we should structure our work to prevent those misses when possible), but how to catch them as part of the overall requirements process.
Requirements review and approval cycles are a great way to catch missed requirements, particularly if you have reviewers who haven't been deeply involved in the elicitation of the requirements. A fresh set of eyes always help spot the missing details. Peer reviews work well, too, since fellow Requirements Engineers know what to look for in a good set of requirements. Design sessions and walkthroughs can also be helpful, as was the case in my example above. Essentially, find a way to see the requirements in a new light, or from a different perspective, and the problems start to jump out at you.
The key is, no matter how you go about it, plan time to review the requirements in order to catch what's missed. Hopefully you'll find that nothing was missed! But if you do come across a missed requirement, remember that it's finding, not missing, the requirements that really matters!
posted by Mike Alexander at 8/27/2007 08:57:00 AM
0 Comments:
Post a Comment
<< Home