The knee-jerk response to priority prioritization is to mark everything as a must-have. “I need everything before the product becomes generally available. I want it ALL!” Give me a break.
Granted, if a claim is written in the SRS, it must be because you want it. But the reality is that some features are more important than others and a good product manager can set them apart.
If everything is a high priority, there are no priorities. Let me repeat this statement again. If everything is a high priority, there are no priorities.
Unless this is your very first software project, you know that time is always a limitation. Combine an overly optimistic project plan with a list of non-prioritized requirements, and what do you get? A team of developers who implement what they want, when they want.
You have a choice. You can (a) leave it to the development team to pick and choose their preferred features to implement, or (b) give them a clear sense of direction by prioritizing the requirements. Let them start with must-haves, followed by nice-to-haves. When the project deadline comes up, you may decide to extend the project schedule to add a few more good things, but you won’t be forced to because your product will already contain all the must-have requirements that will set or break your sales. In other words, you manage the plan instead of letting the plan guide you.
Wondering how best to prioritize requirements? Check things out first [http://www.projectmangler.com/content/regular/art20041208.htm] in The Project Mangler’s archives.