When working with large, distributed teams, requirements can often get lost in translation (sometimes literally). There is no way to prevent this completely, but there is a technique you can use to help reduce your risk in this area – perspective.
If the development team was directly plugged in to the product manager’s brain, you would end up with the ideal solution every time. Unfortunately (or fortunately!), developers aren’t plugged in to the product manager’s brain. There are often large barriers, both physical and mental, that can prevent the team from understanding exactly what to build. This is especially true if the product manager uses a single method to communicate the solution. In this case, the team can interpret the requirements in several different ways. This doesn’t happen due to a problem with the information in the requirements, it’s simply due to the lack of alternate perspectives.
Think about the image to the right. Nothing in the photo is faked. All of the information it contains is accurate. The issue is that you only have one view of the situation. If you looked at this image from another perspective, you would have a much better understanding of what is actually being portrayed.
Let’s think about how this applies to software requirements. To get the most accurate picture possible, you need to present several different views of the solution that are different enough to provide alternate perspectives. This will drastically reduce the probability that something will be misinterpreted. You can do this by creating more than one model of each problem. The more the better.
Of course, some of the models will contain redundant information. There is also a risk that the models will not overlap enough to provide an alternate view of the same context. Time is also a factor, so you can’t make an infinite number of models. Generally speaking, 2-4 different views is sufficient.
One example of using this technique would be to create use cases, wireframes, and click-action-response tables for the same user interface. Each one of the models is useful by itself, but may leave the solution up to misinterpretation. When all three are used in concert, a much clearer picture of the requirements emerges.
