Hi Prasad,
The first step is to make sure you have a clear scope for your solution - is it strictly workflow management, or do you need document management capabilities as well? The next step is to collect, document, and prioritize your requirements accordingly. Prioritization is important, because that will be essential later on when your organization is evaluating alternative products.
A matrix is a good way to present the requirements for comparison purposes - but you need clear requirements first. There is a lot of variety in workflow solutions, and one of the differentiators is the complexity of workflows that need to be managed. How many different types of workflow do you need to manage? How many workflow steps typically fall into each workflow type or stream? You've mentioned one that is fairly simply - submit, review, approve, fulfill. It will probably help if you identify the processes involved, and model the workflows within each. How many decision points exist? Are there parallel paths within any workflow?
Once you have your workflows modeled, you can define the associated functionality to manage them. Is it just workflow routing that you need? Or do you need to monitor and balance task allocations (to keep workload balanced across resources)? Do you need to build models of new workflows or changes to workflows, and then analyze impacts of those changes on resources and efficiency, before implementing them?
As M. Prasad noted, it's important to consider non-functional requirements for performance, supportability, and cost - as well as the ones you've noted about technology and connectivity to existing systems. The number of users and/or locations can be a big factor in licensing costs - so make sure you have accurate user counts.
Once you have all this information put together, then you can start mapping to available products. A matrix works fine for this purpose. You can conduct your own research (environmental scan) of products that are out there and perhaps contact other universities to see which products are used in similar organizations for similar purposes. A next step might be to use your university's procurement processes to issue a Request For Interest (RFI), where you publish your requirements and vendors can respond with their proposed products. There are different procedures for selection and purchase, but that is probably a different forum post... :)
Sandy