need to see how other people prioritize requirements

[timm]

@neilernst

Achimugu, Philip, et al. "A systematic literature review of software requirements prioritization research." Information and Software Technology 56.6 (2014): 568-585.

table 5 is amazing https://goo.gl/jLnuPb

neil: u know this stuff better than i. if we divided table4 into singl goal vs multi goal and varianceAware vs not, how many of these are in our turf (multi goal varianceAware)?

[timm]

@neilernst ypu reading github notifications?

for your local briefing, table5 from the above paper could be cool.

how many of those methods

• report median and variance of the possible decisions (as do we)?
• handle multiple goals (as do we)?
• can handle mixed models with numbers and symbols (like we can)?
• can learn thresholds where decisions change (as can we)?
• report what decisions need to be made first in order to minimize the impact of future decisions (as we do)?

[neilernst]

I didn't see table 5 - just table 4 and table A1. I assume table 4? I agree it is a nice structured review of that (these SLRs serve a purpose after all!)

[neilernst]

@timm I think the closest is probably Paolo Tonella using IGA - http://www.sciencedirect.com/science/article/pii/S0950584912001292. They have at least the notions of thresholds and filtering non-informative comparisons. But George's approach allows us to encode the notion of non-comparable requirements, ie. unlike AHP, we can handle deeper and more complex structures.

[timm]

@neilernst @bigfatnoob

wow... is implementation order of the prioritization of the agreed requirements (as Paolo does) the same as proposing a discussion order on the requirements (as George does)?

if yes, they George's stuff is an alternate technology to that proposed by Paolo and all the next releast planning people

.... interesting...

[neilernst]

in the sense that both approaches identify 'problem' nodes, i.e., nodes requiring human input, I'd say yes. But I do think the notion of prioritization is more nuanced than the one they suggest (or the NRP people).

For our use cases, I think when to implement a decision is only one aspect. So what their approach misses is the idea of other relationships / orderings: cost, benefit, timeliness, etc.

[timm]

For our use cases, I think when to implement a decision is only one aspect. So what their approach misses is the idea of other relationships / orderings: cost, benefit, timeliness, etc.

can't help feeling that with the right tweaks, we can get NRP out of the current rig... could be wrong...