Home > Articles > Mobile Application Development & Programming

  • Print
  • + Share This
This chapter is from the book

Out-of-Date Requirements Documentation

Yet another way projects go wrong is when the requirements documentation exists but is not kept up to date as things change. This often happens in projects that involve multiple organizations and many simultaneous conversations. Decisions get made, and the two people on the phone know what was discussed, but nothing gets written down, and the rest of the folks on the project are left in the dark. Alternatively, sometimes the requirements document does get updated, but the change doesn’t get announced, and other parties execute the instructions from an old copy of the document.

Requirements documents often start out as multipage documents that are basically tables of contents. Someone (usually a single person) starts the project with every intention of documenting all the requirements and begins by writing a three-page list of stuff that needs to be documented. Then as the project goes on, less and less gets written on the requirements document each day, until finally it ends up a derelict Word file on some shared drive somewhere and serves only to confuse the unwary.

Another common setup is that someone sets up a project wiki server with the expectation that people will use it to document the project, but the wiki never ends up being integrated into the project’s workflow. The content on it grows stale over time, and the wiki ends up being worse than useless because no one knows whether it can be trusted.

The way to solve this problem is to force the documentation to be part of the workflow for the project—either documentation that the quality assurance (QA) team uses to do testing (so the team opens bug reports when the documentation doesn’t match the reality) or in the form of a suite of automated acceptance tests that are run on a frequent (or at least periodic) basis. The automated acceptance test idea works especially well for documenting the requirements between the server development team and the mobile development team.

Without some way to bring to light discrepancies between the documented requirements and reality, documentation usually becomes out of date to some degree during a project, and this can cause headaches for everyone involved.

  • + Share This
  • 🔖 Save To Your Account