|
|
Testing a model doesn't involve "rocket science"; rather, it calls for some commonsense measures designed to identify errors and/or omissions.
First of all, revisit all requirements-related project documentation—the original problem statement and the supporting use cases—to ensure that no requirements were overlooked. We'll do so for our SRS model in a moment.
Conduct a minimum of two separate formal walk-throughs of the model: one with the development team members, and a second with the future users of the system. Prior to each walk-through, make sure to distribute copies of the following documentation to each of the participants far enough in advance to allow them adequate time to review these, if they so desire (but be prepared to discuss significant aspects of these at the meeting in case they haven't reviewed them):
"Executive summary" problem statement, if available
Class diagram
Data dictionary
Use case documentation
Significant scenarios and corresponding message trace diagrams
By this stage in the project, you'll have hopefully already educated your users on how to read UML diagrams, and they'll have informally seen numerous iterations of the evolving models. If any of the participants in the upcoming walk-throughs aren't familiar with any of the notation, however, take time in advance to tutor them in this regard. (The information contained in Chapters 10 and 11 of this book should be more than adequate as the basis for such a tutorial.)
When conducting the walk-through, designate someone to be the narrator and discussion leader, and a different person to be responsible for recording significant discussion content, particularly changes that need to be made. Having one person trying to do both is too distracting, and important notes may be missed as a result. If appropriate, you may even arrange to tape record the discussion.
Remain open-minded throughout the review process. It's human nature to want to defend something that we've worked hard on putting together, but remember that it's far better to find and correct shortcomings now, when the SRS is still a paper skeleton, than after it has been rendered into code.
|
|