Requirement prioritization

Last updated

Requirement prioritization is used in the Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist. [1] [2]

Contents

Introduction

In Software product management there exist several sub processes. First of all there is portfolio management where a product development strategy is defined based on information from the market and partner companies. In product roadmapping (or technology roadmapping), themes and core assets of products in the portfolio are identified and roadmap constructions are created. In requirements management candidate software requirements for a product are gathered and organized. Finally, in the release planning activity, these requirements are prioritized and selected for a release, after which the launch of the software product can be prepared. Thus, one of the key steps in release planning is requirements prioritization.

Cost-value approach

A good and relatively easy to use method for prioritizing software product requirements is the cost-value approach. This approach was created by Joachim Karlsson and Kevin Ryan. The approach was then further developed and commercialized in the company Focal Point (that was acquired by Telelogic in 2005). Their basic idea was to determine for each individual candidate requirement what the cost of implementing the requirement would be and how much value the requirement has.

The assessment of values and costs for the requirements was performed using the Analytic Hierarchy Process (AHP). This method was created by Thomas Saaty. Its basic idea is that for all pairs of (candidate) requirements a person assesses a value or a cost comparing the one requirement of a pair with the other. For example, a value of 3 for (Req1, Req2) indicates that requirement 1 is valued three times as high as requirement 2. Trivially, this indicates that (Req2, Req1) has value ⅓. In the approach of Karlsson and Ryan, five steps for reviewing candidate requirements and determining a priority among them are identified. These are summed up below. [3]

  1. Requirement engineers carefully review candidate requirements for completeness and to ensure that they are stated in an unambiguous way.
  2. Customers and users (or suitable substitutes) apply AHP’s pairwise comparison method to assess the relative value of the candidate requirements.
  3. Experienced software engineers use AHP’s pairwise comparison to estimate the relative cost of implementing each candidate requirement.
  4. A software engineer uses AHP to calculate each candidate requirement’s relative value and implementation cost, and plots these on a cost-value diagram. Value is depicted on the y axis of this diagram and estimated cost on the x-axis.
  5. The stakeholders use the cost-value diagram as a conceptual map for analyzing and discussing the candidate requirements. Now software managers prioritize the requirements and decide which will be implemented.

Now, the cost-value approach and the prioritizing of requirements in general can be placed in its context of Software product management. As mentioned earlier, release planning is part of this process. Prioritization of software requirements is a sub process of the release planning process.

The release planning process consists of the sub processes:

  1. Prioritize requirements
  2. Select requirements
  3. Define release requirements
  4. Validate release requirements
  5. Prepare launch

Other prioritization techniques

Related Research Articles

<span class="mw-page-title-main">Risk management</span> Identification, evaluation and control of risks

Risk management is the identification, evaluation, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.

<span class="mw-page-title-main">Activity-based costing</span> Method of apportioning costs

Activity-based costing (ABC) is a costing method that identifies activities in an organization and assigns the cost of each activity to all products and services according to the actual consumption by each. Therefore this model assigns more indirect costs (overhead) into direct costs compared to conventional costing.

<span class="mw-page-title-main">Analytic hierarchy process</span> A structured technique for organizing and analyzing complex decisions

In the theory of decision making, the analytic hierarchy process (AHP), also analytical hierarchy process, is a structured technique for organizing and analyzing complex decisions, based on mathematics and psychology. It was developed by Thomas L. Saaty in the 1970s; Saaty partnered with Ernest Forman to develop Expert Choice software in 1983, and AHP has been extensively studied and refined since then. It represents an accurate approach to quantifying the weights of decision criteria. Individual experts’ experiences are utilized to estimate the relative magnitudes of factors through pair-wise comparisons. Each of the respondents compares the relative importance each pair of items using a specially designed questionnaire.

The Moscow method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018. CMMI is registered in the U.S. Patent and Trademark Office by CMU.

A technology roadmap is a flexible planning schedule to support strategic and long-range planning, by matching short-term and long-term goals with specific technology solutions. It is a plan that applies to a new product or process and may include using technology forecasting or technology scouting to identify suitable emerging technologies. It is a known technique to help manage the fuzzy front-end of innovation. It is also expected that roadmapping techniques may help companies to survive in turbulent environments and help them to plan in a more holistic way to include non-financial goals and drive towards a more sustainable development. Here roadmaps can be combined with other corporate foresight methods to facilitate systemic change.

The change request management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. Its main goals are to support the processing and traceability of changes to an interconnected set of factors.

ISO/IEC 27005 "Information technology — Security techniques — Information security risk management" is an international standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) providing good practice guidance on managing risks to information. It is a core part of the ISO/IEC 27000-series of standards, commonly known as ISO27k.

<span class="mw-page-title-main">Enterprise life cycle</span> Process of changing an enterprise over time

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

<span class="mw-page-title-main">Project management triangle</span> Model of the constraints of project management

The project management triangle is a model of the constraints of project management. While its origins are unclear, it has been used since at least the 1950s. It contends that:

  1. The quality of work is constrained by the project's budget, deadlines and scope (features).
  2. The project manager can trade between constraints.
  3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.

Decision-making software is software for computer applications that help individuals and organisations make choices and take decisions, typically by ranking, prioritizing or choosing from a number of options.

This is a worked-through example showing the use of the analytic hierarchy process (AHP) in a practical decision situation.

Potentially All Pairwise RanKings of all possible Alternatives (PAPRIKA) is a method for multi-criteria decision making (MCDM) or conjoint analysis, as implemented by decision-making software and conjoint analysis products 1000minds and MeenyMo.

This is a worked-through example showing the use of the analytic hierarchy process (AHP) in a practical decision situation.

<span class="mw-page-title-main">IT risk management</span>

IT risk management is the application of risk management methods to information technology in order to manage IT risk, i.e.:

SDI Tools

SDI Tools is a set of commercial software add-in tools for Microsoft Excel developed and distributed by Statistical Design Institute, LLC., a privately owned company located in Texas, United States.

UNICOM Focal Point is a portfolio management and decision analysis tool used by the product organizations of corporations and government agencies to collect information and feedback from internal and external stakeholders on the value of applications, products, systems, technologies, capabilities, ideas, and other organizational artifacts—prioritize on which ones will provide the most value to the business, and manage the roadmap of how artifacts will be fielded, improved, or removed from the market or organization. UNICOM Focal Point is also used to manage a portfolio of projects, to understand resources used on those projects, and timelines for completion. The product is also used for pure product management—where product managers use it to gather and analyze enhancement requests from customers to decide on what features to put in a product, and develop roadmaps for future product versions.

References

  1. ↑ Lehtola, Laura, Marjo Kauppinen, and Sari Kujala. "Requirements prioritization challenges in practice." Product focused software process improvement. Springer Berlin Heidelberg, 2004. 497-508.
  2. ↑ Berander, Patrik, and Anneliese Andrews. "Requirements prioritization." Engineering and managing software requirements. Springer Berlin Heidelberg, 2005. 69-94.
  3. ↑ Karlsson, J. & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements, IEEE Software September/October 1997, 67-74.
  4. ↑ "ICE Scoring Model for Prioritization".

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.