This episode relates a story that an ex-student and current colleague of mine related to me over lunch.  I felt it was an extremely revealing and useful example of how requirements are misunderstood, the disasters than can result, and what to do about this.

Scenarios, like requirements, can often be too large to work with effectively.  In this episode we'll examine why this is a problem, and some example of how we can deal with it.

The world has changed, and so has the technology we use to automate it.  But a lot of the traditions that guide our efforts to control automation projects are based on the realities that existed in the past.  Agile is a response to this, and this episode is all about why, and how this is so.

When collaborating with others, sometimes you will encounter reticence to ask or answer important questions.  There are a number of reasons for this, but in this episode I will outline an approach I take to counter this, one which has served me well in multiple occasions.

When creating something new of value, one must always consider the context within which it will operate.  Part of this is determining what, if anything, in the existing business processes will be effected by the new work.  Failing to take this into account can have serious consequences, as this episode will demonstrate.

Analysis is a fundamental part of system's development.  It is also one of the most difficult things to do right, and since everything that follows is based on it we need multiple skills to do it correctly.  Commonality-Variability Analysis, as suggested in the work of James O. Coplien, is a remarkably powerful approach to conducting requirements analysis.

Test-Driven Development (TDD) is not really a testing activity per-se, but an analysis process that drives product design.  That said, although it does not eliminate the need for after-development testing (QA/QC), it does contribute to that process.  This episode will show why this is.

One of the benefits of Test-Driven Development is the way is enhances our ability to collaborate effectively.   This is especially true if you include Acceptance Testing as part of the way of working.  This episode is all about this.

TDD is a process that produces multiple values for the organization.  One of them is a fundamental improvement in the quality of the products they produce.  This is not just because of the testing per se, but also because of the effect of writing them up front.  This episode explains why.

How can we keep track of the behavior of systems as they change over time?  We must do this, or critical enterprise knowledge can be lost, at potentially great cost going forward.  This episode is about how TDD solves this problem.