Professional Test-Driven Development with C#: Developing Real World Applications with TDD

DEFINING THE PROJECT

Most developers like to write code. In most cases, this is what led us to become developers in the first place. Most developers try to solve a given problem with code. Many developers communicate in code. Some developers even think in code! Given the option, I believe most developers would attempt to do all communicating and problem solving in code. Unfortunately for them, the rest of the business does not communicate, let alone think, in code.

No application gets written without a set of requirements. Even a small application that you might write to keep track of your DVD collection has some sort of requirements-gathering phase, even if it's very informal. Before you can write an application, you need to know what the application is supposed to do. In addition to knowing what the application will do, you must know how the application is to be built and under what conditions it will have to run. All these decisions should be made before development begins.

The business functionality of the application is defined by the business requirements. The technological foundation of the application is defined by the target environment and the choice of technologies used to build the application. In an ideal situation, while the technological choices made should complement the business, the business would not be made to bend to the whim of the chosen technology. Unfortunately, ideal situations are rare. For that reason, it's important to deal with the business needs early ...