The expectation gap describes the difference between what a consumer of a work product expected and what they received. You can normally anticipate a larger expectation gap in situations where there was insufficient collaboration on requirement design between BA and stakeholders. If you look at the classic requirements decomposition model, you can clearly see where the expectation gap can be controlled.
Business Requirements(not that relevant)
Stakeholder Requirements (highly relevant)
Functional Requirements (not that relevant)
Nonfunctional Requirements (can be very relevant)
Transition Requirements (normally not that relevant)
Although you would think business requirements would be highly relevant because they are the top of the model, they really are not. These requirements are so high level, the expectation gap discussion rarely occurs. On the other end of the spectrum, functional requirements are so "in the weeds", they also rarely become part of the expectation gap discussion directly.
Nonfunctional requirements are never an issue unless they become "THE ISSUE". Usually there is no gray area here and related manifested issues can be exceptionally difficult to overcome. If you document and communicate nonfunctional requirements correctly, you have covered your back. You can get extra points if you have communicated this to your testing teams as something you want to have tested.
Issues centered around transition requirements can normally be fixed. This may delay full implementation and raise costs but normally not a deal breaker. In some cases, the expectation gap for transition requirements comes from a mistake in believing they are not needed (training needs for example).
If you adequately document, communicate and get sign off approval regarding stakeholder requirements, you can assume you a fairly well protected from expectation gap damage. If you don't perform these fundamental steps in your requirements package, you can expect some expectation gap issues to arise shortly before, during or shortly after deployment.
In my experience, the best protection from stakeholder expectation gaps can be obtained by ...
• structured walkthroughs of requirements
• prototyping with monitored feedback
• diagrams, models, wireframes and storyboards
• stakeholder engagement in the testing process
©2015 Dwayne Wright