Because the test code focuses mainly on the external interface of the class, it will highlight required public methods and internal calculations. Delivering code without internal and external test facilities simply defers the creation of unit tests to the test process, which is ill equipped to plan or manage this work. Furthermore, it practically guarantees unplanned reworking, because in the absence of verification it is virtually certain that either a programmer or a tester will fail to fulfill or understand a requirement. Producing code that must prove that it fulfills its design objectives ensures that development occurs when it's supposed to and that testing is not an adjunct to development, but a true verification of correctness and fulfillment of requirements. In fact, you should consider making requirements gathering and validation a perpetual activity.
Requirements change over time - now more quickly than ever.
Businesses are buying and building systems intended to support relationship-building between them and their suppliers, customers, partners, and internal relationship managers. Companies continually analyze their markets and can deploy marketing and business analysis resources in conjunction with one another to manage the evolving understanding of what services their customers, partners, and internal teams need to increase the value of their interactions. Internet time means frequently extending the breadth and depth of the interactive services in which your organization participates. Whether you develop applications internally or you develop applications for others to use, the trick is to focus each release on a coherent package of services. To provide such focus and provide an effective bridge between requirements analysis, design, development, and validation, try building a catalog of use cases to describe the requirements universe and selecting the set of use cases to fulfill in each release.