
Thanks: 0
Likes: 0
Dislikes: 0

Junior Member
Requirements values and prioritizations
We all know that in working with requirements you sometimes have to allocate resources based on the requirement's importance to the project as a whole while making acceptable tradeoffs among sometimes conflicting goals such as quality, cost, and timetomarket. This goes to the ageold question of "How do you select a subset of the customers' requirements and still produce a system that meets their needs?" Well, now I've been told that the answer to this is the formal costvalue approach to a requirements prioritization scheme. So how do you implement this? This process has to be relatively simple, fast, and accurate (in terms of results). The prioritizing process also must hold stakeholder satisfaction as the ultimate goal. How do you do it? (Oh, yeah. You also usually have to express it in terms where quality must be maximized, cost minimized, and timetodelivery be as short as possible.) I'm looking for indepth here; preferably how you've applied this. As you can guess I'm in this situation right now.


Senior Member
Re: Requirements values and prioritizations
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by McKenna:
(Oh, yeah. You also usually have to express it in terms where quality must be maximized, cost minimized, and timetodelivery be as short as possible.)<HR></BLOCKQUOTE>
This reminds me of that phrase. "Quality. Cost. Time. Pick two." (Of course, I do not agree with that cliche but just thought I would bring it up for kicksandgrins.)
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Well, now I've been told that the answer to this is the formal costvalue approach to a requirements prioritization scheme. So how do you implement this?<HR></BLOCKQUOTE>
Okay, well how I do this sort of thing is pretty much via what you already said: prioritize requirements according to their relative value and cost. Generally I take various subsets of the requirements if that is possible. So, in that case, I would just compare alternatives in a stepwise fashion and measure their contribution to the objective  which is the release with certain functionality present. If you take that route to perdition, you have to operationally define quality as a relation to a candidate requirement's potential contribution to customer satisfaction with the resulting system. Similarly, you then have to operationally define cost as the cost of successfully implementing the candidate requirement.
In general, what I like to do (and this idea is certainly not original with me) is compare requirements pairwise according to their relative value and cost. The pairwise comparison approach includes a lot of redundancy (or, at least, it can) and is probably going to be less sensitive to judgmental errors common to techniques using absolute assignments, which I tend to avoid if at all possible. Another way to add to your model is to indicate inconsistencies (part of inconsistency management) by calculating a consistency ratio of judgmental errors. The smaller the consistency ratio, the fewer the inconsistencies, and thus the more reliable the results. (It is basically a builtin selfcorrecting feedback system for requirements; organizations used to love this when I showed it to them. Personally that is my favorite method.)
So let us just assume that you want to evaluate candidate requirements using the criterion of value. You are then asking how we could do this. Here is one solution that I like (but a gets a little, shall we say, "scientific"):
Set up the n requirements in the rows and columns of an [n*n] matrix. Let us assume here that you have four candidate requirements: REQ1, REQ2, REQ3, and REQ4, and you want to know their relative value. So: insert the n requirements into the rows and columns of a matrix of order n (in this case we have a [4*4] matrix, but, obviously, a normal one will be more complicated).
Now we perform pairwise comparisons of all the requirements according to the given set of criterion that indicates the value. You, however, have not provided a scheme of your own so permit me to make one up:
1: Of equal value (two requirements are of equal value)
3: Slightly more value (experience slightly favors one requirement over another)
5: Essential or strong value (experience strongly favors one requirement over another)
7: Very strong value (requirement is strongly favored and its dominance is demonstrated in practice)
9: Extreme value (evidence favoring one over another is of the highest possible order of affirmation)
The number is the basic value although most such schemes call it the "relative intensity." What about 2,4,6,8? Those will be the compromise values. In other words, they are intermediate values between two adjacent judgments.
Okay, so, for each pair of requirements (starting with REQ1 and REQ2, for example) insert their determined relative intensity of value in the position (REQ1, REQ2) where the row of REQ1 meets the column of REQ2. In position (REQ2, REQ1) insert the reciprocal value, and in all positions in the main diagonal insert a "1." Continue to perform pairwise comparisons of REQ1REQ3, REQ1REQ4, REQ2REQ3, and so on. For a matrix of order n, n*(n  1)/2 comparisons are required. Thus, in this example, six pairwise comparisons are required; they might look like this:
<PRE>
REQ1 REQ2 REQ3 REQ4
REQ1 1 1/3 2 4
REQ2 3 1 5 3
REQ3 1/2 1/5 1 1/3
REQ4 1/4 1/3 3 1
</PRE>
With this I now wse averaging over normalized columns to estimate the eigenvalues (if you will pardon the phrase) of the matrix (which represent the criterion distribution). A simple method for this is known as averaging over normalized columns. First, calculate the sum of the n columns in the comparison matrix. Next, divide each element in the matrix by the sum of the column the element is a member of, and calculate the sums of each row:
<PRE>
REQ1 REQ2 REQ3 REQ4 SUM
REQ1 0.21 0.18 0.18 0.48 1.05
REQ2 0.63 0.54 0.45 0.36 1.98
REQ3 0.11 0.11 0.09 0.04 0.34
REQ4 0.05 0.18 0.27 0.12 0.62
</PRE>
Then you normalize the sum of the rows (divide each row sum with the number of requirements). The result of this computation is referred to as the priority matrix and it is an estimation of the eigenvalues of the matrix:
<PRE>
[1.05] [0.26]
1/4 * [1.98] = [0.50]
[0.34] [0.09]
[0.62] [0.16]
</PRE>
Assign each requirement its relative value based on the estimated eigenvalues. From the resulting eigenvalues of the comparison matrix, the following information can be extracted:
REQ1 contains 26 percent of the requirements' total value
REQ2 contains 50 percent
REQ3 contains 9 percent
REQ4 contains 16 percent
Pretty nifty, huh? If we were able to determine precisely the relative value of all requirements, the eigenvalues would be perfectly consistent. For instance, if we determine that REQ1 is much more valuable than REQ2, REQ2 is somewhat more valuable than REQ3, and REQ3 is slightly more valuable than REQ1, an inconsistency has occurred and the result accuracy is decreased. The redundancy of the pairwise comparisons makes the method much less sensitive to judgment errors; it also lets you measure judgment errors by calculating the consistency index of the comparison matrix and then calculating the consistency ratio.
I could go into further detail but is this what you were looking for? Basically, there are five overall steps for a costvalue approach to requirements:
(1.) Requirements engineers carefully review candidate requirements for completeness and to ensure that they are stated in an unambiguous way. (This is akin to QA checklists for requirements, which should be done anyway.)
(2.) Customers and users (or surrogates) apply the pairwise comparison method to assess the relative value of the candidate requirements.
(3.) Software engineers in tandem with quality engineers use the pairwise comparison to estimate the relative cost of implementing each candidate requirement.
(4.) A software engineer uses the method to calculate each candidate requirement's relative value and implementation cost, and plots these on a costvalue diagram (value on yaxis; estimated cost on xaxis).
(5.) The stakeholders use the costvalue diagram as a conceptual map for analyzing and discussing the candidate requirements. Based on this discussion, software managers prioritize the requirements and decide which will actually be implemented. They can also use the information to develop strategies for release planning.
If you have worked in strict engineering disciplines, you will probably see a lot of familiar things here. Also, if the concept of "eigenvalues" threw you off, I just mean that as a linear transformation of the matrix. I am uncertain of what other term to use to convey the point.
In any event, I have used this in numerous places, from dot.com's to established corporations, and I have never yet seen it fail when actual requirements were present. However, it does depend on how much people adhere to the strict procedure. Also, if you look for consistency in a formulaic manner then you need a stable method of determing the consistency ratio and the consistency index.
[This message has been edited by JeffNyman (edited 11202001).]

Super Member
Re: Requirements values and prioritizations
Very interesting method and seems indeed very accurate and efficient.
I have only one question for Jeff:
considering that REQ3 from your example, is an "must to have" requirement (I always saw this kinf of requirements,where you don't care about cost or other stakeholders opinion  if you have no conficts) you would put it in the matrix, or you can skip these "must to have" requirements from this evaluation in order to simplify the process ?


Junior Member
Re: Requirements values and prioritizations
Hi,
Prioritizing requirements by pairwise comparision is called Analytic Hierarchy Process ( AHP ) as said by Jeff. This is one part of the QFD ( Quality Function Deployment ). If you need some more details about QFD please send me your mail id i will give you some papers.
bye
sridhar
anchoori@rediffmail.com


Junior Member
Re: Requirements values and prioritizations
Yeah, I know about AHP and stuff. This isn't bad as detailed here as it does seem to work. In fact I think the pairwise comparisons are what make AHP models less sensitive to problems. This also brings up a host of other issues such as calculating the consistency index/ratio. On the other hand, using the reciprocal in the matrix seems odd becuase then your consistency index is going to be random. Also, this is similar to paired comparisons I think. I'm not even sure if there's much of a difference.


Senior Member
Re: Requirements values and prioritizations
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Daniel_S:
considering that REQ3 from your example, is an "must to have" requirement ... you would put it in the matrix, or you can skip these "must to have" requirements from this evaluation in order to simplify the process ?<HR></BLOCKQUOTE>
Well, you can always skip having the requirements in there  at the risk of biasing the model in possibly unpredictable ways. All requirements should generally be included within a given subset of applicable requirements  if nothing else, it keeps them visible. (If I am understanding your point, this, in some ways, could be like asking if I should keep all "Severity 1" defects out of the defect report because, after all, we know we have to fix them.)
Also, REQ3 is not a "must to have" requirement necessarily. Look at the values it has percentagewise. That is also why I said that if you see REQ3 coming up as more valuable than REQ1, then you have discovered an inconsistency.


Senior Member
Re: Requirements values and prioritizations
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by McKenna:
In fact I think the pairwise comparisons are what make AHP models less sensitive to problems. This also brings up a host of other issues such as calculating the consistency index/ratio. On the other hand, using the reciprocal in the matrix seems odd becuase then your consistency index is going to be random. Also, this is similar to paired comparisons I think. I'm not even sure if there's much of a difference.<HR></BLOCKQUOTE>
Yes, but I do not use strict QFD methods because I tend to use pairwise comparisons in combination with planguagebased requirements. And, yes, you have to calculate your consistency index or ratio and you can do this in a similar fashion to calculating a confidence interval or even a Service Level Agreement, if you think of it in those terms. (Obviously the mechanics are different but the overall principle is roughly analogous.) And, yes, paired comparisons and pairwise comparisons are pretty much the same thing  you are just using a judgment matrix.
Also the matrix consistency will certainly not be random. What will be random is the consistency indices  and only for randomly generated reciprocal matrices. These are called random indices and are critical to the model. In fact, it is the ratio of the consistency indices to the random indices that marks out your consistency ratio. That is how you determine the the accuracy of the pairwise comparisons.

Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules
