While this is a simple approach, you are not quite done. If you believe software development is a profession, you can't just take the stakeholders' input as the way things will be. If you do, you have become an "order taker" instead of a professional offering thoughtful technical input to your stakeholders. You and your team need to assess these use cases and determine your ability to actually deliver the use case functionality. It's your turn to prioritize. This time you prioritize by how difficult/risky the implementation of these use cases will be. Use the same scale as your stakeholders did regarding value/importance. In this discussion, 1 means very easy / no risk and 10 would be very difficult / very risky.
How do you resolve these two viewpoints? You now have two characteristics that you can plot against each other. Create a diagram where the y axis is the stakeholders' importance ranking and the x axis is your technical difficulty ranking. Then "plot" the individual use cases on this grid. See Figure 1.
Figure 1: Use Case Plot.
Next partition the plot into four quadrants. Moving counter-clockwise, the upper right quadrant contains the high risk use cases (high importance and high difficulty). The upper left quadrant contains the high importance, less difficult use cases. The lower left contains use cases that are not that important and are less difficult. The lower right use cases are not important, but are high difficulty. See Figure 2.
Figure 2: Prioritized Use Case Plot.
This plot can give you the coarse plan for your use cases. Again moving counter-clockwise, the upper right, high risk use cases should be done first. Being high risk you need to mitigate the risk these use cases have before completing other work. If these can't be done, your entire project may need to be canceled or redefined. The upper left (Do It) are the mainstay of your development. They are important and less difficult. Do these next. The lower left (Maybe) quadrant contains those use cases that you may want to do if you have additional time or resources (chuckle, chuckle) because they are easier and not that important. The last quadrant, lower right are the use cases you may want to descope. Why would you want to develop functionality that is very difficult to create and the stakeholders don't really want?
Now you have the basic sequence of how to proceed through your use cases. They will mature at varying rates during the development lifecycle. See Figure 3.
Figure 3: Use Case Progression.
Caveats. Realize that this simple method is not to indicate that you should be approaching your development in a serial, waterfall manner. This technique can be used for incremental or iterative or agile development approaches. It merely gives you a way to easily prioritize your use cases (or functional blocks, user stories, or whatever units of work you are using). Also, you should consider adjusting your prioritization based on any interdependencies that may exist between your use cases. (Hopefully there are not many. If there are, that may indicate a problem with your use case definitions.)
The UML is not just a great tool for requirements elicitation, analysis, and design, it also can help the project manager to effectively plan and direct the development cycle.