This is a continuation of the previous blog:  Why You Should Prioritize Requirements

1. Assign priorities once you have a set of requirements for your system of interest.

2. Assign a relative importance to requirements.
Keep it simple, like 1, 2, & 3 – Have rules for each category or “bucket” The rules must be made known to everyone – customers, contractors, users  — all stakeholders. If you set the rules well, the process works.  If the rules are fuzzy you will have problems.

• Priority 1 – essential need to rethink scope if can’t have these. Use these to identify where to apply resources when problems/change occurs (best bang for the buck).
• Priority 3 – flexible or useful can be added later, expand tolerances – negotiable or deliver in a later phase (if doing incremental development)
• Priority 2 – all other requirements.

Note:  A common argument against assigning priorities is that some people think a priority 3 requirement won’t get done.  Remember, all requirements are binding and will be verified.  Assigning priorities doesn’t change that.  If you need to descope your project, then the formal change process must be used to remove or defer a requirement from the requirement set.

3. Involve multiple stakeholders –remember that all stakeholders are not equal.
Involve the right people (customers, developers, other stakeholders). The order of negotiate, arbitrate and edict are meaningful.  Sometimes you just have to say “that’s the way it is going to be”.

If you don’t assign customer priorities to requirements, designers may make the wrong assumptions and trade the wrong things which could result in your expectations not being met and having a lot of rework.  If you are the customer, assign your priorities.  If you have external customers, interview them to get the emphasis in the right place so that you won’t waste time and money.  Just let them know that you want to put resources on the essential items and you don’t want anyone to trade anything that is a high priority.

4. Use allocation and traceability to help assign priorities. 
During scope definition, it is important to define your Need, goals, and objectives.  This includes communicating what is most important to your project’s success.  This importance is communicated via Key Performance Parameters (KPPs), Measures of Performance (MOP), Measures of Effectiveness (MOE), primary vs secondary objectives, etc. These stakeholder expectations are implemented via derived requirements that will trace directly to these expectations.  Priorities need to be maintained throughout the levels of requirements.  A priority 1 requirement at the system level will be allocated to the next level of the architecture.  The resulting derived children requirements that trace back to their priority 1 parent need to be assigned the same priority as their parent.

Closing thoughts:

• Priorities have to involve multiple stakeholders and all are not equal – Prioritization is not democratic
• Keep your prioritization simple
• Priorities have to be maintained through all levels of requirements