A lot has changed since I published my last post on this matter.  I took some family leave for the birth of my son, wrapped up a really exciting project helping a bank launch a credit card, and began a new chapter in my career at ArgonDigital.  Additionally, ArgonDigital recently completed its requirements management tool study, which got me thinking a lot more about requirements, tools, and documentation.  Agile (specifically Scrum) is really blowing up in a big way at large organizations.  I still am of the opinion that requirements documents, in and of themselves, contain no value, are outdated the moment they are created, and are generally disposable.  I received a lot of great comments and questions in response–I am just sorry that it took me two whole years to collect my thoughts on this and commit some time to writing on it.  I would blame it on spending more time with my son after he was born, but that would just be an excuse.  I wouldn’t even feel right blaming the few extra pounds I gained since then on that.   But, enough about my personal life.

When I first wrote “Why we should all stop creating requirements documents”  I promised to give people who were in the business of creating, managing, and consuming requirements documents an alternative.  There is no simple answer for every project and every organization.  Let me first begin with the thesis that the closer the artifact that is produced is to the actual solution, the more relevant it is, and the more it will resonate with stakeholders responsible for accepting a solution.  Actual working code is more relevant than a clickable prototype, which is more relevant than a set of wireframes with requirements (e.g., DAR models), which is more relevant than a spec that describes the functionality, and so on.  This is why requirements documents are disposable–once something is built which has been verified that it accurately represents the requirements, but is closer to actual working code, there is very little value in referring back to the original requirements document.  So, what are some alternatives?

1. Use Queries/Reports Out of a Requirements Management Tool to convey relevant information:  QA teams have been doing this for years.  Since I began in product management some ten years ago, I have never seen a QA department send me a Word File with all of the test cases that would be run in a given release/sprint.   This is because good QA teams know that there is rarely a good reason to read through every single test case.  Instead they build reports out of their ALM tool, which highlight which test cases are relevant to a particular fundamental good practice anyway.  Managing requirements in a tool–especially if you can trace those requirements to working prototypes or functioning code, beats a document anyway.  If you happen to need a document to get through a stage-gate, most requirements management tools allow you to export requirements as a report anyway.
2. Conversations:  This really (and I would argue only) works well for very small (less than 10) teams which are co-located and have direct access to each other.  Ideally they sit in the same room.   The smaller the team, the less likely you need to rely on documentation, and the more you can work out conversationally.  The documentation which becomes critical in these situations are not necessarily requirements documents, but release notes and end-user documentation.  The user stories and related models are created only such that they are sufficient to keep development and test working.  Details can be filled in with conversations.  If you like, the user stories can live on in a document, but in most cases this is unnecessary.
3. Working prototypes:  Works especially well if you can create working prototypes more quickly than write requirements, and if the person creating them can sufficiently act as the voice of the user.  Of course, this really can only be used in cases where there is a user interface, and not really best-suited for projects which mostly rely upon the manipulation and transfer of data between sources.

There are still very real challenges with large, complex projects with interdependencies that some of the above suggestions do not solve for (with the exception of reports out of a RM repository).  In those cases, I would still argue that it isn’t the documents themselves that are critical, but the management of information across different work efforts.  If any type of project is screaming for the use of a tool as opposed to a document, it’s the largest, most complex project.  One final note:  Being disposable isn’t necessarily a bad thing.  Project teams should just recognize that information about a project is generally disposable, especially the further removed it is from the actual end product.  That recognition of information as a means to jump to the next step in the project will decrease a lot of heartburn over the veracity and permanency of the information.