The communication of functional requirements and specifications is the most difficult, critical, and error-prone task in IT projects. Research has shown that projects that proceed to the construction and coding phase with missing or wrong functional requirements and specifications are almost certain to fail. To avoid missing or misunderstanding the requirements for a solution, and to avoid the development of systems to incorrect specifications, we need a systematic approach to capturing, organizing, and validating the functional requirements and specifications. In this article, Bill Walton offers such an approach.
Researchers first documented the sources of errors in software development almost twenty years ago ("Sources for Errors in Systems Development," Basili & Perricone, Communications of the ACM, January 1984). According to that study, slightly over half of the errors (52%) were generated in coding and construction, were caused by earlier fixes, or were of a miscellaneous origin. The trend in the industry has been to focus efforts here. Development tools and methodologies have been developed and commercialized with great fanfare.
Despite this, project failures have not materially decreased. The problem persists because those are not the errors that cause projects to fail. The vast majority of errors made in coding and construction are simple-easy to find and fix. The root of the problem lies elsewhere, in errors that result in wrong or misunderstood requirements or functional specifications. These are the errors that cause entire designs to be revisited and revised. These are the errors that result in negative impacts to other systems or user groups. These are the errors that cause projects to fail.
The definition of functional requirements and specifications is a difficult and error-prone exercise in communication. The primary difficulty that we, as analysts, encounter is maintaining the right context for information as it is delivered. When we have the right context, the information makes sense and we capture it. When we lose the context, it doesn't make sense to us and we may misunderstand the information being communicated. What we need is a systematic way to capture all the information we're given and to organize it so that missing information is more easily identified, and the full impact of change is more easily understood. We need a systematic approach that better facilitates having our understandings and related recommendations validated or corrected.
The difficulty of our task is driven by complexity. Effective communication consists of information transfers that take place within a context that both parties understand. Our communications take place not within a single context, but along two separate axes of context. The first axis contains the procedural, organizational, and technical aspects of the business that may or may not need to change to arrive at a workable solution. Within each of these, we contend with the second axis. Some users talk about the way the system works today: "I don't like the way X works." Others talk about the way they want it to work when the project is complete: "X should work like this." Still others describe the changes they think we should make: "If you do A, B, and C to X, that will fix it." Some will even present us with the solution as they envision it: "Here's what X should look like. It is not unusual for an interviewee, within a single conversation, to deliver a mix of all of these. Given the complexity of the communication, it's not surprising that requirements get missed or misunderstood.