In grammar school, most of us learned how to solve mathematical story problems. The hardest part in solving a story problem is learning to isolate the key information needed to create a mathematical expression and ignore the extraneous information. A similar process holds true for defining business requirements. In grammar school, you understood the story problem properly if your answer matched the teacher’s answer. Unfortunately, when dealing with business requirements’ story problems, most technical teams forget to validate their understanding of the problem before they begin creating a solution. Appropriately enough, the process used to make sure the technical stakeholder’s translation of the business stakeholder’s story problem is known as requirements validation.

Business stakeholders generally deal with complex issues involving people, market drivers, regulatory agencies, financial tradeoffs, and other realities of daily business. Although these problems can be modeled and tracked using mathematical methods, the business stakeholders generally describe problems using analogies. This isn’t a failing; it is as necessary to the language of business as procedural logic is to technical design.

The technology stakeholders talk a different language—that of specific tools, syntax, languages, system design, methodologies, and other minutiae of software and hardware. To the business stakeholder’s bewilderment, a technical discussion can quickly spiral into a vigorous argument over seemingly irrelevant fine points that each party defends with fanatic ferocity. Although the technology stakeholders generally view their discussion as being one of fact, at the end of the day, it is just as subjective as the business analogies they dislike and misunderstand.

The requirements definition process helps the business stakeholders and technology stakeholders understand each other, validate that understanding, and use the resulting requirements information to build and test a solution that satisfies both parties.

When the business and technology stakeholders agree on a high-level requirements document, it becomes the foundation of the project charter, which serves as a contract governing the project and its participants (Figure 4-3). Any change to the requirements or the charter represents a change to this contractual agreement and must be validated with cost and schedule impacts. In other words, once the charter has been written and approved by the business and technology stakeholders, it becomes the governing authority for the project.

Figure 4-3. Illustration of the project charter development process

Although it is critical, a requirements definition doesn’t need to be complicated or lengthy. Simply stated, it is a dialogue in which the business stakeholders articulate a measurable need and the technology stakeholders negotiate a reasonable strategy for meeting that need. At the beginning of the process, the technology stakeholders usually find the business requirements to be very imprecise because businesspeople integrate their understanding of new technologies through analogy, as was mentioned earlier. This is one of the great challenges in establishing business requirements. It is the task of both the business stakeholders and technology stakeholders, working together as a project team, to resolve the business analogy into measurable and executable technical requirements.