r1 - 08 Sep 2008 - 16:06:49 - IngeVanDeWeerd

The Features Prioritization Matrix

Introduction
Process description
Example
Further reading

Introduction

Any professional software development project should reserve resources, time and money for collecting, prioritizing and maintaining the status of the requirements or features that eventually make up the system. When such product software management efforts aren't made, a project will likely fail because the resulting software doesn't fulfill the needs of the end-user. Unfortunately, precisely deciding on what to build is one of the hardest parts of building a software system (Berry & Lawrence, 1998) .

Collecting all stakeholders' requirements and specifying them is a well-defined phase in quite a number of methods. However, deciding on the prioritization of requirements in a structured and quantitative manner is relatively new. The Features Prioritization Matrix (FPM)described by (Wiegers, 1999) is one of the first methods that explicitly address this need. Most important activity within the method is the calculation of priority numbers based on estimated benefits, penalties, costs and risks. The method itself can therefore be seen as mainly quantitative, although acquiring the relevant numbers to perform the calculation is a more qualitative process because the numbers need to be negotiated about with related stakeholders.

To clarify the FPM's context, the method is positioned within the Software Product Management Framework (SPMF) (Weerd, Brinkkemper, Nieuwenhuis, Versendaal, & Bijlsma, 2006) in the second section of this paper. The SPMF provides a good overview of the activities related to features prioritization and is therefore well-suited for gaining an insight into the context of the method.

This paper aims to explain Wiegers' method by means of a Process-Deliverable Diagram (PDD) and a corresponding description in the third section. By notating the method in the unified way as described by (Van de Weerd & Brinkkemper, 2007) , the PDD and the description are suited for inclusion as a method fragment into a method base. Such a fragment can be assembled together with other relevant method fragments from the method base to create a so-called situational method; a method that is constructed and adapted to the situation at hand (Weerd, Versendaal, & Brinkkemper, 2006) .

In the fourth sections of this paper, the situational factors of the method and the applicable maturity levels are discussed. A concise example of the application of FPM is presented in the fifth section in order to offer more clarification on the method. Finally a slightly advanced version of the method is shown, aimed at taking into account stakeholder importance.

Background

Activities in the area of requirements engineering have a long history. For example, in the late 1980's, Herb Krasner identified five sub phases within a general software requirements phase: 1) 'need' identification and problem analysis, 2) requirements determination, 3) requirements specification, 4) requirements fulfillment and 5) requirements change management (Krasner, 1989) . Another example is the work of Heninger concerning techniques for making requirements specifications precise, concise, unambiguous and easy to check for completeness and consistency (Heninger, 1980) . More recent work is that of (Ramesh & Jarke, 2001) , in which they propose an empirical approach to the process of ensuring continued alignment between stakeholder requirements and various outputs of the system development process. Somewhat related is the work of (Maiden & Ncube, 1998) , who developed a model for matching commercial-off-the-shelf (COTS) software product features to user requirements.

A lot of publications in the field of requirements engineering, including the above mentioned contributions, emphasize that prioritizing the requirements of a software product is a very important activity within software product management. A structured method for deciding on this prioritization, offered by the FPM, can therefore be of great value.

Process description

Wiegers' process of prioritizing features consists of several steps. The process-deliverable diagram in figure 2, based upon the technique described by (Van de Weerd & Brinkkemper, 2007) , displays a high-level overview of the process itself and its deliverables.

Please note that it was chosen not to assign specific roles to the activities, because executing the activities is not limited to one particular role. However, in a typical situation, the entire process of prioritizing the requirements is done by a project manager, one or more key customers and one or more people from the development team(s).

Since the task of prioritizing the requirements is actually just a small step in a series of activities related to handling requirements, this representation of the process ignores the fact that requirements need to be collected. At the start of the flow, listing the requirements is therefore seen as the first step.

As said, the first step in this process is listing all the requirements in a REQUIREMENTS SPREADSHEET. This is actually the only real deliverable that the process has: all other steps contribute to the spreadsheet and, in accordance with the notation standard, no other links to this concept have been made.

The second step is calculating the requirements priorities. This activity consists of several sub-activities. First of all, the steps of estimating the benefits when a requirement is realized and the relative penalties when a requirement is not realized (both on a 0-9 scale) are executed. These two activities can be performed in parallel. From the results, a total value per requirement is calculated. This number is used during the last sub-activity, calculating the priority numbers. However, before the calculation can be made, the relative costs and risks related to the realization of the requirements have to be estimated on a 0-9 scale.

Please note that, since all information is captured in the before mentioned concept REQUIREMENTS SPREADSHEET, no additional concepts are introduced here.

After the individual requirements have been given a priority number, they are sorted according to this ranking. The acquired result (still within the REQUIREMENTS SPREADSHEET) is discussed with the (key) stakeholders including the client and head developer. If necessary, the rating is adapted to the outcome of this discussion.

Because the FPM is based on estimating values and calculation with these values, the above described 'tuning' step can be of real value to make sure that the ranking fits the stakeholders' general feeling about the prioritization. Estimating values is a complicated task, and checking the resulted ranking could help the stakeholders in validating their estimates.

Figure 1 Process-deliverable diagram of the features prioritization matrix method.

Activity table

Activity	Sub-activity	Description
List all requirements		The in an earlier stage (not in the scope of this process) gathered requirements are listed in an REQUIREMENTS SPREADSHEET.
Calculate requirements priorities	Estimate relative benefits	The relative benefit received from realizing a specific requirement, rated on a scale from 0 to 9, is added to the REQUIREMENTS SPREADSHEET.
	Estimate relative penalties	The relative penalty resulting from not realizing a specific requirement, rated on a scale from 0 to 9, is added to the REQUIREMENTS SPREADSHEET.
	Calculate total values	The relative benefit and the relative penalty are summed and the acquired value is added to the REQUIREMENTS SPREADSHEET.
	Estimate relative costs	The relative costs that need to be made to realize a specific requirement, rated on a scale from 0 to 9, is added to the REQUIREMENTS SPREADSHEET.
	Estimate relative degrees of risk.	The relative degree of risk that realizing a specific requirement fails, rated on a scale from 0 to 9, is added to the REQUIREMENTS SPREADSHEET.
	Calculate priority numbers	priority = value %/ (cost % * cost weight + risk % * risk weight)
Sort requirements by priority		The requirements in the REQUIREMENTS SPREADSHEET are sorted descending by priority.
Discuss acquired prioritization with (key) stakeholders		The prioritization is discussed with stakeholders, like the client and head developer, in order to check the order of requirements.
Adapt ratings to stakeholder wishes		If the acquired rating of requirements is not according to the stakeholders' wishes, the REQUIREMENTS SPREADSHEET is manually changed to correctly reflect the wishes.

Concept table

Concept	Description
REQUIREMENT SPREADSHEET	A spreadsheet containing the requirements (including title, description, number, and other relevant data), and additional meta data (benefit, penalty, costs and risk) that is used for ranking the requirements by priority.
REQUIREMENT	A requirement is a feature that a stakeholder would like or needs to have implemented in the software package under investigation. It normally has an unique number for identification and a title and description. By applying Wiegers model, the following additional parameters are needed: relative benefit, relative penalty, value, relative costs, relative degrees of risk and finally a priority number, that is calculated based on the other additional parameters.

Example

In order to clarify the FPM method, the following table depicts an abbreviated version of a REQUIREMENTS SPREADSHEET for an accounting based software program.

Relative weights	2	1			1		0,5
FEATURE	Relative Benefit	Relative Penalty	Total Value	Value %	Relative Cost	Cost %	Relative Risk	Risk %	Priority
1. Query invoice status.	5	3	13	8,4	2	4,8	1	3,0	1,345
2. Generate monthly in-out report.	9	7	25	16,2	5	11,9	3	9,1	0,987
3. Resend outstanding invoice.	5	5	15	9,7	3	7,1	2	6,1	0,957
…
Totals	19	15	53	100	10	100	6	100	--

The stakeholders of this program have firstly decided for every requirement (or: feature) on the relative benefit that they gain from realizing the requirement and the relative penalty that they incur whenever the requirement is not realized. Those numbers are, if applicable, multiplied by an already set relative weight factor (top row of the table) and summed. That results in the 'Total Value'. Next, the value percentage for that particular requirement is calculated from the grand total value. The same is done for the relative cost that need to be made and the relative risk (in a technical sense) that results from realizing the requirement. Finally, the total value is divided by the cost percentage plus the risk percentage (again including any weighting), resulting in the prioritization. If needed, the acquired ranking can be modified by hand.

Weerd, I. v., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., & Bijlsma, L. (2006). On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support. Proceedings of the 1st International Workshop on Product Management, (3-12). Minneapolis/St. Paul, Minnesota, USA.

Weerd, Versendaal, & Brinkkemper. (2006). A Product Software Knowledge Infrastructure for Situational Capability Maturation: Vision and Case Studies in Product Management. Submitted for publication.

Wiegers, K. E. (1999, September). First Things First: Prioritizing Requirements.

Application articles

Davis, A. (2003). The art of requirements triage. IEEE Computer Society, /36/(3), 42-49.

Heninger, K. (1980, January). Specifying Software Requirements for Complex Systems: New Techniques and Their Application. IEEE Transactions on software engineering , /6/(1), 2-13.

Karlsson, J., & Ryan, K. (1997). A cost-value approach for prioritizing requirements. IEEE Software , /14/(5), 67-74.

Karlsson, J., Wohlinb, C., & Regnellc, B. (1998). An evaluation of methods for prioritizing software requirements. Information and Software Technology , /39/(1), 939-947.

Linberg, K. (1999). Software developer perceptions about software project failure: a case study. Journal of Systems and Software , /49/(2-3), 177-192.

Lutz, R. (1996). Targeting safety-related errors during software requirements analysis. Journal of Systems and Software , /34/(3), 223-230.

Porter, A., & Votta, L. (1998, December). Comparing Detection Methods For Software Requirements Inspections: A Replication Using Professional Subjects. Empirical Software Engineering , /3/(4), 355-379.

Porter, A., Votta, L., & Basili, V. (1995). Comparing Detection Methods For Software Requirements Inspections: A Replicated Experiment. IEEE transactions on software engineering, /21/(6), 563-575.

Wiegers, K. E. (2000, January/February). Karl Wiegers Describes 10 Requirements Traps to Avoid. Retrieved march 1, 2007, from Process Impact. Web site: http://www.processimpact.com/articles/reqtraps.html