I have been reading "The Art of Agile Development" by James Shore and Shane Warden, and I just finished the first section (chapters 1-4). It is a very lucid and pragmatic guide to practicing XP, and I am anxious to put some of these ideas into action. I must admit that prior to reading this book, I thought that XP teams iteratively encapsulated requirements in stories, and I didn't really grasp the note card concept. In actuality, each story is merely a brief representation of a bite-sized unit of functionality (used for release planning and tracking), and the detailed requirements are relayed in real time by the on-site customer, and are not written down. This is an intriguing concept, but I have a lot of questions about how to apply this on the types of projects I tend to work on. I am hoping the rest of the book will resolve some of these questions. In this post I'll compare the advantages and disadvantages of an on-site customer versus a requirements document (iteratively developed or written up front).
There are a few really significant advantages of using an on-site customer (or two or three) on your project. The first is that the requirements are never out of date. In a world where businesses are growing and adapting constantly, it is critical that development teams understand and act on the changing requirements of their business with as little lag time as possible. In short, technical agility enables business agility, and business agility is a big competitive advantage in a dynamic market place. Furthermore, technical staff (eg. developers) don't waste time writing requirements documents, which are essentially depreciating assets because they become increasingly out-dated over time. Arguably roughly the same amount of time is spent analyzing requirements over-all, but the time is spent by business stake-holders whose time may be less expensive (because they are employed directly by the client and/or because they are lower-level domain experts with less years of experience than developers in the case of teams large enough to warrant on-site clients in addition to the Product Manager), and whose investment of time analyzing requirements in-depth can be more easily capitalized on by the client organization outside the scope of the current project. (In-house domain experts are in a good position to recommend process improvements and propose future projects.) Finally, customers can manage the relative priority of specific features within a story in real-time (like whether or not it's more important to validate a particular piece of data or add a new field, for example), which further enables business agility.
There are some disadvantages of using on-site customers in liu of writing a requirements document, however. One disadvantage of particular interest to projects on a tight budget is that offshoring is much less feasible. Sending an on-site customer half-way around the world for an extended period of time is going to prove too difficult and costly for many organizations to consider. Attempting to provide a virtual on-site customer over the internet is problematic as well due to the drastic time differences usually present between western clients and eastern development teams. The situation would seem to prove even more complex for mixed project teams that have some developers on-shore and some developers off-shore. This would seem to require two on-site customers (one for each site) who would probably spend as much time synchronizing with each other as relaying requirements to the development team. Another disadvantage is that this method of analyzing requirements would seem to be incompatible with fixed bid projects. Although I tend not to prefer working on fixed bid projects, they are often a fact of life because they reduce the monetary risk to the client, and they offer a "price tag" that is easy for clients to base a purchasing decision on. When you do a fixed bid project, it is necessary to precisely define the functionality that will be developed for the price offered. Fixed bid projects put clients and development teams at competing interests; it is in the client's best interest to squeeze every bit of valuable functionality that they can out of the fixed bid project, so in the common case that there is judgement call about what requirements are in-scope and what are not, clients will always strongly air on the side of in-scope. As such, the more amguity there is in the scope definition, the more work the client will lump into the project they're paying a fixed amount for. Therefore, a development team must define the scope very precisely in order to stand any chance of having a fixed bid project be profitable (in most situations). A comprehensive requirements document, while it still may not define scope completely, serves that purpose much better than an on-site client from my perspective. Finally, in my experience with requirements analysis, when asking business stakeholders about how a particular process should take place, they often realize their process is not as clearly defined as it ought to be, and they must circle the wagons internally in order to clarify the process. Since that takes time, doing so in the middle of a development effort could cause unexpected delays and thus cause deadlines to be missed (or long hours to be put in at the end of an iteration since clients always seem to think they can provide the answers in the eleventh hour and you ought to be able to automate their process within minutes of their defining that process for you).
In addition to those disadvantages of on-site customers, there are some advantages to writing requirements documents. First, it allows problem areas to be exposed up-front, so that related functionality can be implemented first and scheduling risks can be mitigated early on, which is benificial in managing client expectations and forecasting project cost/ROI accurately. This is true of both iteratively developed requirements documents (developed at the beginning of each iteration) as well as requirements documents written entirely up front (but is more true of the latter). Another related advantage for requirements documents written entirely up-front is that they enable more precise long-term resource allocation for the development of a strategic project by an important deadline like a trade show (because estimates can be made more accurately for a specific set of critical functionality). Lastly, up-front requirements documents enable system architects to assess appropriate high-level technology choices prior to project inception. Although emergent design is a great way to establish a flexible and clean architecture for code-based solutions, it seems less effective for leveraging pre-existing tools or frameworks within the application. For example, if you define requirements iteratively (or even more so if they're defined continuously as with an on-site customer), you may decide to hand-code certain business logic in an early iteration, and then realize in a future iteration that utilizing BizTalk makes sense to enable the functionality in that iteration, so business logic relating to that functionality should be defined within BizTalk. At that point, you must either have business logic scattered in multiple sources (some in BizTalk, some in "code"), or you need to spend time re-creating the existing business logic in BizTalk and removing it from code. Similarly, you may send out some simple email notifications manually in an early iteration, and then realize in a later iteration that it makes sense to use the (.NET 3.0) Workflow Framework to conditionally send all notifications in the application, at which point you would need to retro-fit your existing notification functionality, which results in a greater total amount of time needed to implement the notification functionality in this fictional project (because requirements were defined iteratively).
Although I think a lot of projects can benefit from having an on-site customer, there are other project circumstances which demand a traditional requirements document. Those projects include fixed bid projects, fixed deadline projects, projects utilizing offshore developers and solutions heavily leveraging pre-existing frameworks/middleware/etc. On-site customers seem to work best in environments meeting the fairly extensive list of pre-requisites to practicing XP on a project: Management Support, Team Agreement, A Colocated Team, (On-Site Customers), The Right Team Size and Use All Practices (Shore: pages 44-49). Although this list seems prohibitive, the Shore book offers advise about how to change your environment into one that meets the pre-requisites. Additionally, "advanced XP" can still be applied to environments where one or two pre-requisitves may not be satisfied. For many projects with a less compatible and flexible environment, writing a requirements document (sometimes even up-front) still makes sense. I may post about this topic again if the rest of the book impacts my opinions on this topic significantly.