Prioritization

The hardest single part of building a software system is deciding precisely what to build […] No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” – Frederick P. Brooks

Introduction

Requirements prioritization has been recognized as one of the most important decision activities in the requirements engineering activities.[10]  But in my experience, it’s an area that seems to generate very little discussion among business analysts.

In Business Analysis and Requirements Engineering, the primary prioritization focus is on requirements.  But what do we mean by requirements?  Are we talking about detailed requirements, user stories, features, use cases, or something else that has been categorized as a set of “requirements”?

One of things that I find interesting is that when you go and look at the development of many prioritization techniques, most of what is being prioritized in “requirements” prioritization are requirements at a more abstract level than “detailed” requirements.  The focus is usually at the feature, function, user story, or equivalent level of abstraction rather than at the “detailed” level of knowledge.

This page attempts to provide a fairly comprehensive overview of prioritization in the realm of business analysis.  As such, it will go beyond requirements prioritization as a specific activity and look at questions such as:

  • What exactly is prioritization?
  • What are the contexts of prioritization?
  • What are the things I should consider when undertaking prioritization?
  • What are some prioritization techniques? (where appropriate, this will link to other pages in this wiki)
  • What should be prioritized?

 

What is Prioritization?

Prioritization is a seemingly simple concept that I think is among the core concerns of business analysis.  But despite its seeming simplicity, I don’t think it’s that simple at all. The definitions for “prioritization” seem relatively straight forward though.  You can take your pick from definitions such as:

  • To arrange or deal with in order of importance. [1]
  • To organize (things) so that the most important thing is done or dealt with first.[2]

But both of those definitions rely on the concept of “importance”.  So what does importance mean?

  • The quality or state of being “important; consequence; significance. [3]
  • The state or fact of being of great significance or value. [4]

Which leads one to wonder what exactly is meant by significance, since that is a common way of defining importance?

  • The quality of being important: the quality of having notable worth or influence.[5]
  • The quality of being worthy of attention; importance. [6]

So importance = significant and significant = important.  So what does important mean?

  • Of great significance or value; likely to have a profound effect on success, survival, or well-being. [7]
  • Having serious meaning or worth: deserving or requiring serious attention. [8]

We are still seeing a bit of circular logic here.  But we are also seeing the concept of value, or worth, showing up again.  So what does “value” mean?

  • The regard that something is held to deserve; the importance, worth, or usefulness of something. [9]
  • Relative worth, utility, or importance [10]
  • The amount of money that something is worth : the price or cost of something[10]

So maybe in the end, a workable definition of prioritization is “to arrange or deal with in order of relative worth, utility, or importance”. At least as it applies to Business Analysis.

Now, some of you are probably rolling your eyes and wondering why I went through that whole exercise with the definitions above? The point is that even though we think of concepts like prioritization as self-evident and simple, they really aren’t. They are often vaguely defined and are based around concepts that are just as vaguely defined (like importance). The key thing to understand is that the concept of prioritization you have in your head may not be the exact same one your stakeholders have, and sometimes those differences are important.

 

Why Prioritize?

At its core, prioritization is about enabling good decision-making. On a project stakeholders might say, “Why should I prioritize anything? I’ve told you what is needed, and none of it is negotiable!” But environments change. Goals change. Management changes. Change is almost always inevitable. Even if you have defined the requirements and all stakeholders have signed off; a solution has been designed; a level of effort (LOE) provided; and a budget approved and provided. Change can still happen. The question is how you deal with it.

Prioritization is about having the knowledge and being prepared to make intelligent, rational, and well-informed decisions when things change. When decisions need to made, it is often not obvious which choice is better, because often several aspects need to be taken into consideration.[12] For example, when the choice is between Feature 1 and Feature 2, stakeholders might choose Feature 1 as the best option. But when you factor in the cost to development the features, the impact on development time, and the ongoing support costs, that decision becomes may be much less clear.

Prioritization is about doing the analytical work ahead of time (as much as possible) so that when decisions have to be made, you already have the information you need to make the best decision. You may have even already made the decision, if the change was foreseeable. And if it wasn’t, by prioritizing ahead of time you will have usually significantly reduced the work and time needed to enable the best decision to be made.

Among the many activities prioritization supports, the following is just a sample: [12]

  • Enables the trade-off of desired scope against project constraints
  • Enables stakeholders to decide on a core set of functions / requirements for a system
  • Enables the estimation of expected customer satisfaction
  • Enables the balancing of requirements and system architecture and future system evolution
  • Enables the balancing of the business benefit of a potential option against its cost
  • Enables the discovery of requirements defects since requirements are analyzed from a different perspective than elicitation
  • Enables plan stability by minimizing re-work and schedule slippage
  • Helps to resolve disagreements among stakeholders and build consensus [12, 13]
  • Enables the definition of a minimally viable product so that “gold-plating” is more easily identified and reduced
  • Forces stakeholders to consider the needs of other stakeholders, not just their own [13]

The key point is that prioritization is a strategic process and should be treated as such. It should never be treated as an after-thought.

However, please note that if you are going to undertake a prioritization exercise the priority levels have to actually mean more than “only the highest priority is going to happen in the next 10 years”.  No matter what prioritization method you use, be sure that you actually implement more than just the highest level of priority items.  If stakeholders consistently see that only the highest priority items are implemented, then soon they will stop believing that prioritization efforts mean anything other than “implemented” or “never going to happen”.  And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process.  Why should they bother to participate in the process (both the prioritization process and the processes of problem identification and solution definition) when they know they are going to only get the bare minimum of what they prioritize?  The only logical course on their part is to prioritize EVERYTHING as the highest level and at that point your process is broken, probably for as long as those stakeholders remain with the organization.

 

The Prioritization Process

The following is a high-level process for prioritization. The main goal is to call out important things you should consideration in your prioritization effort and to put them into a logical order. This does not describe a specific Prioritization technique, but rather covers the overall process that includes selecting a prioritization technique.

Step 1 – What is the goal of your prioritization effort?

The first question you need to answer is what is the goal of any prioritization effort? Are you building an analysis plan? Analyzing stakeholders? Providing information for a development plan? Evaluating solution options?

Knowing the goal of your prioritization effort will drive such factors as:

  • What you prioritize (it could be several things)
  • What context(s) you use for your prioritization effort
  • Who is involved in the prioritization effort
  • What prioritization technique(s) you use
  • Whether prioritization is revisited, when, and how often; or whether it is done as a single-instance exercise

 

Step 2 – What are you going to Prioritize?

So what are you prioritizing? The items you prioritize should be directly related to achieving your prioritization goal. If it is requirements, what types of requirements? Functional, non-functional, constraints? How are the requirements documented? UML models, user stories, detailed requirements? Different requirements may be better suited to different goals and different prioritization techniques may be more suited to different artifact types.

When you ask Business Analyst’s about prioritization, the discussion rarely seems to move beyond requirements prioritization. And while that is a critical part of the requirements engineering discipline of business analysis, it’s hardly the only situation in which prioritization is important to business analysts.

So what can a Business Analyst prioritize?

Projects

Most BA’s I know work on more than one project at a time. Therefore, it is a good idea to prioritize your projects and to get agreement from you project managers and your direct supervisor / manager on that prioritization. Prioritizing your projects helps in managing your communications with the project teams and stakeholders you are working with, and ensures that when potential conflicts come up that there is already agreement on which project may need to accept less of your time or effort. But don’t get stuck thinking of this a simple ranking of priority from 1 to whatever. Prioritization of projects can change by the phase a project is in, the level of involvement you as a BA need to have for that phase, the amount of time you need to complete deliverables for those projects, and a number of other factors. So your discussion with your project managers and team manager might be “when I am in the requirements phase, project X has a higher priority than project Y, but as soon as we move out of the requirements phase, project Y has a higher priority because of a need for greater interaction with the design team”.

Project Goals, Objectives, and Stakeholders

One you are working on a project, potential project, business problem, or other analysis effort; it’s a very good practice to start by prioritizing the projects goals, objectives, and stakeholders involved in the effort.

Prioritizing these items in the project Context phase (or the Enterprise Analysis or similar phase) can help the business analyst(s) in devising the business analysis plan by considering each of the following:

Goals and Objectives

What is the priority of each of the project goals (if there is more than one)? If that goal is broken into sub-goals, what is the priority of each of those? Knowing which goals are most important helps you as a business analyst allocate more time for analysis work. That time can be spent on elicitation, analysis, documentation, verification, and validation of the requirements that ensure those goals are met.

Stakeholders

This can be somewhat controversial, but it is also a good idea to prioritize stakeholders. Both overall for project success (however that is going to be measured), and for individual goals and objectives. If you know which stakeholders are they highest priority for different aspects of the effort, then you can develop your analysis plan accordingly. You can also prioritize your response to feedback during requirements work. And lastly, it can help with your actual requirements plan, so that you can ensure that specific requirements activities are scheduled at such a time (and done in such a way) that gets the most value from the highest priority stakeholders.

Requirements

Requirements Prioritization is what most BA’s think of when they hear the term prioritization. Be sure to consider that requirements can be prioritized at many levels, not just the detailed level. You can prioritize user stories, use cases, features, functions, and every level of abstraction there is for requirements. And starting early at the highest level of abstraction (whether you call that level business requirements, stakeholder requirements, goals, or whatever) helps you focus your analytical work on the most important areas.

Your Time and Work

Prioritization and time-management skills are critical to actually being able to do your job effectively. Yet few BA’s think to consciously prioritize their work. They may say something like, “I work on what the project manager / my supervisor tells me to work on”.

But what if stakeholders you need for a certain activity aren’t available when the PM wants you to focus on something? What if you have a (higher priority) task for one of your other projects that you need to work on when you are asked to work on something for another project?

Unless you prioritize your work products around multiple contexts (when something is due in the project plan, availability of resources, your other project obligations, your other work obligations, the amount of time available versus the amount of time required to do something, etc.) it is much easier to miss a delivery date, have a project manager schedule something that depends on your output when it won’t be available, or cause multiple other problems to arise.

Additionally, it is also a good idea to prioritize your time for knowledge acquisition when starting on a new project or endeavor. Should you for example focus more on understanding the current process, the current technology, or the current stakeholders? If a conceptual solution framework is already in place (such as when replacing a BA on a project), should you focus on understanding the new solution concept? You still need to learn about other aspects of the business and project work, but prioritizing your knowledge acquisition helps you be as effective as possible, as soon as possible, given the situation you are working in.

Theoretically, all of this should be part of your analysis plan. But it’s rarely spelled out and most of us are guilty of doing this “on-the-fly” or sub-consciously. I know I still rarely do this (even though I know I should).

 

Step 3 – What Context(s) are you going to Prioritize by?

In looking at the definitions in “What is Prioritization” above, mote that all of the definitions above fail to address context. Important to whom? For what purpose? In what time period? Deriving value or worth from what? These are sometimes known as prioritization criteria or aspects, but I prefer the term context.

These are not unimportant questions. The problem is that most of us tend to think of prioritization as only having a single context. Usually that context is “importance to project success” or “importance to achieving sponsor happiness”. But something can be of the highest importance to project success (and thus high priority) without having to be done immediately. Or even in the next year. Or maybe it’s of highest priority to the sponsor’s definition of success, but not nearly so high a priority for the user’s definition or project success. Or the Legal departments.

So the key takeaway for me is that Business Analyst’s need to learn to think of prioritization within multiple contexts. The same thing can have different priorities in different contexts. And you as a BA need to know what those different contexts are, what the priority is within each context, and how priorities might change if the context changes. Or at a minimum, you need to know what contexts you have not considered when you prioritize something so that you know where you might have to do additional prioritization work if something changes.

The following are some of the more common prioritization contexts, although not a complete list.

Purpose

You can’t really say how important something is if you don’t know the “important for what” part, or what I call the purpose. This is the one everyone thinks about when considering priority, but they don’t always do it consciously. Is it “for project success”? Well, you can often meet the project success criteria while making no one happy. Is it “for sponsor happiness with the results”? That prioritizes based on some persons (usually one) success criteria. Is it “to achieve the highest value”? Value by what measure? Value in whose consideration? A firm, a regulator, and a client may all see the “value” delivered by an analysis effort in different ways. So be sure when you are prioritizing that you explicitly define the purpose for which you are prioritizing. And it’s often a good idea to do multiple prioritizations for multiple contexts to give you a better idea of the real priority of any given item.

Time/Schedule

The time and schedule aspect of prioritization is most commonly seen in iterative development processes. The items slotted into the next release are the highest priority for further analysis (the “just enough” requirements detail idea).

This is also the way most of us prioritize our work. Whatever is due the soonest, based on whatever schedule you are considering, is whatever the highest priority is. As Business Analysts, unfortunately we often aren’t consulted when project schedules are defined. We often aren’t even consulted when analysis and requirements schedules are defined. We are simply told, you have X amount of time to get Y done. The fact that this leads to lower quality results often isn’t considered by stakeholders or project managers. And sometimes trying to argue for more time gets you labeled as “lazy” or “not a team player”. It sucks, but it’s the reality in some circumstances. And in those circumstances, your analysis work needs to be prioritized by due dates, even if that isn’t the best way to do something.

This same logic can apply for prioritization when certain features of your project solution have deadlines that vary. If Feature D needs Feature B in order to function, and Feature B is low priority from a purpose perspective, you will still need to focus work on Feature B in order to ensure Feature D can be deployed by its deadline.

Resources

Prioritization based on the resources context is prioritizing based on the availability of resources (people, systems, or other resources).  If you know SME’s or high-priority stakeholders are only going to be available during a certain time period, you probably want to prioritize all activities that require those SME’s for that time frame. This may not be optimal for other prioritization contexts (value, quality, purpose, etc.), but it often trumps other contexts because having some involvement of those resources trumps having no involvement.

And don’t just limit this to human resources.  Consider availability of resources such as testing environments, applications, and conference or meeting rooms (especially if you want to have workshops or similar activities).

Quality

The quality aspect of prioritization is the one that I think is among the most overlooked. It is explicitly recognized in the “iron triangle” of project management (time, budget, quality) but rarely do I hear of prioritization by quality of expected results.  Yet this should something every BA considers.  Usually (not always), the more time you have to do something, the higher the quality of the results.  But it’s also frequently true that the later in the analysis effort something is done, the higher the quality of the result (because you know more about the project, stakeholders, and context).  So in cases where the quality of results are of higher importance, you may want to prioritize the amount of time or resources committed to that effort.

Value

Value is the prioritization context that seems to be explicitly used most often by “Agile” methodologies.  This is the idea of prioritizing work by the highest value of the output.  Of course, first you have to decide “value by what calculation” and “value to whom”. It’s those aspects of the value context that frequently get overlooked.  And given that “value” (however you choose to calculate it) can vary by stakeholder, prioritization by value is often among the more complex prioritization efforts to undertake.

Risk

Risk is another prioritization context that is common in “Agile” methodologies.  But it also has a central role in non-Agile processes like the Spiral development methodology.  Generally, the idea is to prioritize the highest risk items first (or as most important) because they may drive important architectural decisions, or because the way they are addressed may impact the way you address other, more well understood, items.

Or you might focus on risk as a prioritization measure for specifying which items have the largest negative impact if they are not addressed.  For example, the technology team may have a good idea of what solution is appropriate for a new regulatory requirement, how much it will likely cost, and how long it will take to develop.  In some prioritization processes, this would push addressing this need further down the priority queue.  But if the impact of NOT having a well-working technology solution in place for this regulatory requirement is to cease operations, it might be better to make this the top priority for development.

Or you can take the opposite approach and prioritize the lowest-risk activities the as the highest priority.  This is especially true if you are not looking for significant or transformative results, but rather more predictable outputs.  An example might be an investor is close to retirement and thus begins to prioritize their investments into lower-risk assets like money-market accounts and inflation-protected bonds.  Or some continuous improvement processes where the goal is to predictably improve the current processes by eliminating waste or variability might prioritize on changes that have the lowest risk of NOT delivering the expected improvement.

Cost

This is prioritizing items simply by the cost in money or other resources to implement or achieve those items.  Usually, the lower the cost, the higher the priority.  But sometimes you take the reverse approach (highest costs = highest priority) because even small differences in estimated cost versus actual cost can have significant impacts on a development budget.  Of course, it’s rarely that simple and cost prioritization is usually considered along with a value focus that prioritization is done based on cost per value achieved basis.

The contexts listed above are not an all-inclusive list.  The important thing for you as a BA is to be aware of the different contexts, and to realize that when you prioritize you will often have to do so across multiple contexts.  Simple prioritization leads to simple analysis which can lead to too simple results.

 

Step 4 – Who are your Stakeholders?

When you prioritize, there should always be a goal or target audience of some sort in mind. If you are prioritizing business development opportunities, your target audience is likely senior management.  If you are prioritizing requirements, your target audience is probably the project and development teams. But how well do you understand the user’s needs and wants?  And what if you have more than one customer who have different, or conflicting, needs?

If you are doing bespoke development and can talk directly to users, you often have a very good idea of what users want and the specific problem(s) that is being addressed.  Prioritization in this case is usually much easier because you have actual users to interact with, managers to work with to make key decisions, and it’s often possible to use deeply analytical prioritization techniques to ensure you are prioritizing the solution aspects (whatever they are) to best meet the target audiences goals and problems.  The prioritization goal is usually management and/or user happiness with the solution.

But if you are prioritizing requirements for a market-focused solution, the situation is different. You rarely have direct users to talk to or a well-defined solution to solve. You may not even have a specific market you are targeting. In this case, prioritization becomes harder and the goals change. Instead of focusing on solution happiness, the prioritization goal is driven by factors such as time-to-market, sales amounts, feature parity with competing products, and similar factors. Rather than prioritizing for the needs of specific users, you are prioritizing for the needs and desires of as many potential users as possible. This in turn may drive not just the context that you prioritize within, but the techniques you choose to prioritize with.

Additionally, there is the question of knowing which stakeholders will need to be involved in the prioritization effort itself. Knowing the goal and context of the prioritization effort, and what is being prioritized, will largely drive who is involved.  And knowing the stakeholders involved will influence what prioritization techniques you are likely to consider due to the type of output you need to meet to the prioritization goal, stakeholder availability (some prioritization techniques take more time than stakeholders may have availability), and stakeholder familiarity with various prioritization techniques.

Berender and Andrews included the table below in their book chapter [12] on the differences between the stakeholders involved in a bespoke development effort and a market-focused development effort, and I thought it was so useful I wanted to include it here:

 

Facet Bespoke Development Market-Focused Development
Main Stakeholder Customer organization Developing organization
Users Known or identifiable Unknown, may not exist until product is on the market
Distance to users Usually small Usually large
Requirements Conception Elicited, analyzed, validated Invented (by market pull or technology push)
Lifecycle One release, then maintenance Several releases as long as there is market demand
Specific RE issues Elicitation, modeling, validation, conflict resolution Steady stream of requirements, prioritization, cost estimating, release planning
Primary goal Compliance to specification Time-to-market or market share capture
Measure of success Satisfaction, acceptance Sales, market share

*Reproduced from Berender and Andrews [12], Table 4.2

 

Step 5 – What Prioritization Technique will you use?

Selecting the actual prioritization technique that are going to use is influenced by a number of factors. They include: [10]

What type of prioritization result do you need?

In general, prioritization can result in one of three different types of results. They are:

  1. Nominal Scale Results:  Prioritization techniques that generate nominal scale results are those that produce lists of categories into which items can be classified.[11]  Each group has its own importance level and all items in a single category have equal importance. No one item in a category is more important than any other items in that category.
  2. Ordinal Scale Results:  Prioritization techniques that generate ordinal scale results produce ranked lists of items which convey only that one item is more important than the other items below it in the ranked list, but not exactly how much more important the item is.[11]  So you would know that item #3 in the ranked list is more important than item #4, but you would have no idea of how much more important #3 is than #4.
  3. Ratio Scale Results:  Prioritization techniques that generate ratio scale results are those that produce not just a ranked lists of items, but also the relative difference between each item being prioritized.[11]  So unlike Ordinal Scale results, Ratio Scale techniques tell you not just that item #3 is more important than Item #4, but also how much more important #3 is than #4.

How many things are being prioritized?

Depending on the number of things to be prioritized, different techniques may be more or less appropriate.  For some techniques, the amount of work required to prioritize a certain number of items scales up rapidly.  For example, with the Analytical Hierarchy Process (AHP) you need to do about 45 comparative prioritization activities to prioritize 10 requirements.  But if you have 50 requirements, you have to do over 1200 comparative prioritization activities.

What is the abstraction level of what you are prioritizing?

In addition to what is being prioritized, an important factor is what is the abstraction level of the items you are prioritizing and their related information?  At higher levels of abstraction there are fewer dependencies that you may have to figure into your prioritization analysis.

Another question is whether you are prioritizing at a single-level of abstraction (only detailed requirements for example), or at multiple levels of abstraction.  Most techniques are only geared to prioritizing one level of abstraction.

How many individuals will be doing the prioritization?

The number of stakeholders who will be taking part in the prioritization exercise is a critical factor.  The more people involved, the more complex the process tends to be and more appropriate some techniques may become.

How often do you expect to re-prioritize?

The question of how often you expect to re-prioritize becomes important because some prioritization techniques, especially those that produce ratio-scale outputs, require extensive work to prioritize newly introduced items.  In the case of most ratio-scale techniques, it can mean running the entire prioritization process again.  And with techniques such as cumulative voting, re-running the prioritization process would introduce a substantial risk of “gaming” the process by stakeholders.

Depending on the answers to the questions above, you might use different prioritization techniques.  The table below gives a recommendation for which technique may be the best choice depending on the number of items you need to prioritize and the type of result you need. Items with (*) after them support multiple levels of abstraction.  Those without should only be used when all items being prioritized are at the same level of abstraction.

 

Small(1-20 Items) Medium(21-50 Items) Large(51-99 Items) Extra Large(100+ Items)
Nominal Scale Category Assignment PrioritizationMoSCoW Prioritization

Kano Model

Category Assignment PrioritizationMoSCoW Prioritization

Hierachical MoSCoW Prioritization (*)

Kano Model

Category Assignment PrioritizationMoSCoW Prioritization

Hierachical MoSCoW Prioritization (*)

Kano Model

Category Assignment PrioritizationMoSCoW Prioritization

Hierachical MoSCoW Prioritization (*)

Kano Model

Ordinal Scale RankingBinary Priority List

Bubble Sorting

Bubble SortingRanking Ranking
Ratio Scale Analytic Hierarchy Process (AHP)Cumulative Voting

Matrix Prioritization

Hierarchical AHP (*)Cumulative Voting

Matrix Prioritization

Matrix PrioritizationHierarchical Cumulative Voting (*) Hierarchical Cumulative Voting (*)

*** This table is based on a combination of research I have read, my own experience, and some educated “guesses” on my part.  Do not take it as gospel, it’s just something to help you make a decision.  Much of the info on the research side came from. [11]

 

The following are common prioritization techniques. Those that are links have separate pages in the wiki that describe them in detail.

 

Step 6 – When are you going to Prioritize?

I include this step last because it’s a good idea to know why, what, and how you are going to prioritize something before you decide when.  This is because depending on the technique involved and the stakeholders involved in the prioritization process you may need varying amounts of time and involvement.  And you can’t schedule that time well if you don’t know those things before-hand.

Part of the question of when is how many times, or how often?  Do you do a prioritization as a one off when requirements are finalized? Do you schedule several sessions?  The following are all possible times you could schedule prioritization sessions during a project, and what for:

  • When project stakeholders are initially identified (to prioritize stakeholders)
  • When project goals and objectives are approved (to prioritize the goals and objectives)
  • When high-level requirements are finalized (to prioritize high-level requirements)
  • When detailed requirements are finalized (to prioritize detailed requirements)
  • When the first iterative release is being planned (to prioritize features for that release)

In general, the best practice is for prioritization to be an ongoing, iterative process.  Whether prioritizing project work, your personal work tasks, or anything else.  The problem with that is that formal prioritization work can be time consuming and ongoing prioritization work is usually only possible with the lightest of prioritization techniques.

 

Step 7 – Present the results

The effort involved in a prioritization effort is often of little value unless the results of the effort are communicated and shared with all stakeholders who should be informed.  This not only educates them on the results and prepares them for future decision-making, but it also enables a validation of the prioritization process if stakeholders have questions about the results.  Those questions can often point to errors, false assumptions, or incorrect evaluations of various factors that went into the prioritization process.  And this in turn allows for the prioritization work to be better explained or fixed before it is used for decision-making.

 

 

Tips

  • The effort and detail that goes into a prioritization process is often overlooked or downplayed by members of the project team and project stakeholders. I recommend that you plan you prioritization sessions in as much detail as possible early in any analysis effort you are undertaking, and ensure that you have both communicated your plans and achieved stakeholder buy-in as early as possible.
  • None of the prioritization techniques I have researched (including all of the ones on this web site) deal explicitly with dependencies among the items being prioritized. This means that the business analyst, prioritization team, and project team must often deal with interdependencies in an ad-hoc fashion once they are known either during or after the prioritization process.
  • Just as it is usually a good idea not to prioritize items at different levels of abstraction at the same time (unless using a technique that specifically supports it), it is usually not a good idea to prioritize functional and non-functional requirements at the same time. This is because non-functional requirements often impact several functions at once, or possibly the whole system. Also, non-functional requirements often have a sliding-scale of success where functional requirements usually work or don’t work.  This makes non-functional requirements difficult to evaluate. [12]

 

References

  1. The Free Dictionary – Prioritization
  2. Merriam-Webster.com – Prioritize
  3. Dictionary.com – Importance
  4. Oxford Dictionaries – Importance
  5. Merriam-Webster.com – Significance
  6. Oxford Dictionaries – Significance
  7. Oxford Dictionaries – Important
  8. Merriam-Webster.com – Important
  9. Oxford Dictionaries – Value
  10. Research Paper: Towards a Research Framework on Requirements Prioritization. By Patrik Berander, Kashif Ahmed Khan, and Laura Lehtola. Sixth Conference on Software Engineering Research and Practice in Sweden.  2006.
  11. Research Paper: A Comparison of Nine Basic Techniques for Requirements Prioritization. By Mikko Vestola. Helsinki University of Technology.
  12. Book Chapter: Requirements Prioritization. By Patrik Berander and Anneliese Andrews. In Engineering and Managing Software Requirements. Edited by A. Aurum and C. Wohlin. Springer Verlag. 2005.
  13.  Article: Prioritizing Requirements. By Donald Firesmith. In the Journal of Object Technology. Vol 3, Num 8. 2004.

 

 

Resources



© 2014 by David Olson

Leave a Reply

Your email address will not be published. Required fields are marked *