requirements

Creating requirements involves tracking and documenting all of the criteria for a system's success. A requirements management tool, such as IBM Rational's RequisitePro, can support this effort. While the tool won't verify that the requirements are consistent, correct, complete, relevant, coherent, and testable, it can help manage the task more efficiently by allowing you to document, track, and maintain the requirements in an automated fashion.

Use cases have experienced a long and sometimes rocky history. Look back on the evolution of use cases to better understand how to use them today.

Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.

In testing utopia, all software products submitted for testing have thorough and comprehensive documentation describing how every program function should work. On planet Earth, however, test engineers usually have to make do under less-than-ideal circumstances. It's not uncommon for test engineers to be asked to verify the functionality of a critical legacy system which has no documented requirements whatsoever. While there are many reasons this can happen, the result is the same: You assume the role of an archeologist sifting through the layers of clues to reconstruct the specifications. Patricia Ensworth gives you instructions and tools so you'll be ready to roll up your sleeves and dig.