I've also used a variation of this matrix (inspired by Bill's example at a conference), to storyboard events in new functionality. While I fully agree that prototypes are the best proving ground, being able to document a base flow and set of functions helps development teams get a testable prototype built that meets the minimum needs of the designers...especially useful when the designers and development teams are somewhat spread out in the company.

There's also some indication in this artifact that sufficient research and thought has gone into the design process, if validating a business case is still neccessary.

I think depending on the make up of the design and implementation teams, this type of documentation in the wireframes could be of use. Though, I think in many enterprise scenarios, this information would be captured in a technical or systems spec, leaving the wireframes to focus on and convey the choice of form elements, those items that are required/conditional, and the flow and prioritization of the data captured to allow the user to complete the task as quickly and easily as possible.

In previous positions, where I've filled the role of analyst and UI designer, there has been times I've needed to capture this type of information in a single document. In larger teams, I rely on my data and systems folks to fill that role.