16 BDD, DDD, TDD, etc.

There are a number of approaches to how to handle the development effort, especially (for this section, at least), in what order to do things, and in what order to be concerned about things. Most often, this sort of thing won’t affect the requirements team, except that in TDD (to be explained below), tests that the various components might have to pass might be considered the most important part of the requirements. These various styles are listed here:

ATDD, Acceptance Test Driven Development, TDD, Test Driven Development: In test-driven development, writing the test is the thing that’s done first. Software is considered valid if it passes the test cases. In poorly- managed projects, the test plan or even worse, the test code, serves as the requirements, and you’ll be held to write tests. In well-managed TDD projects, the tests are written from the specifications, and QA will start their work in the same sprint as the developers, or even before.

BDD, Behavior Driven Development: This is a form of development in which the users’ behavior drives the development plan. Observing the users’ work, or prospective users’ work, is a great way to gather information on the real requirements of the system, and when you do that, you’re in effect using BDD.

DDD, Domain Driven Development, Domain Driven Design: Although this term is not often used, this type of development is the most common one. The development effort focuses on the problems to be solved, which means that your requirements document is driving the work.

FDD, Feature Driven Development: In this type of development, the necessary features are the key to development. Here, what is developed relies on the features you lay out in your user stories and software requirements specification documents.

OADD, Object Oriented Design and Development: In this model, everything is relegated to classes, as the term “class” is used in object oriented programming languages. Normally, the use of this type of development effort should not affect the requirements gathering or documentation, since all of this should normally be behind the black-box line; but, in rare cases, the requirements documentor may be called upon to lay out which classes are to do what.

You may have noticed that there’s a great deal of overlap in these descriptions. Don’t worry about any of that, unless you find yourself working for someone who is a fanatic about one of these schemes. In such a case, just make sure that you phase each explanation of what you’re up to in terms of that development style, and that you don’t violate any of the rules of that style. Absent fanatics, you’ll likely do some of each, as each circumstance warrants.