On attainable vs. valuable. A bit of a catch-22. It must be both. But I think it is easier to redefine a valuable requirement (perhaps eroding the value) until it is attainable, than it it is to redefine an attainable requirement until it is valuable.

Good point about correctness versus value. I think about it in terms of context. A valuable goal might have been for the USA to “beat” the Soviets in the geopolitical realm. Two requirements may have been “be first to the moon” and “devalue their ICBMs.” Those requirements embody some ideation – a strategy towards achieving the objective. Both have a ‘value’ and both have ‘correctness’ – but as you say, those notions are intertwined.

Really fun to think about it with this level of rigor, especially when revisiting (for me, anyway) these earlier articles. Thanks!

Then, of similar importance: attainable, verifiable and complete.

Then: unambiguous and consistent.

Then: correct!!

Then: design freee and atomic.

Then: passionate and stylish

Finally: concise.

So… we agree about the most important and the least important, but we diverge interestingly in between.

I rank attainable more highly because it is closely linked to valuable: What use is a hugely valuable and otherwise “perfect” requirement if it is simply unattainable?

I rank correctness less highly because much of the value of correctness is delivered by the higher priority properties. The definition above says the requirement “must actually further the objective it supports”, for example. In my view, the proposition that the requirement is valuable ensures this. So it is valuable, attainable, verifiable, complete, unambiguous and consistent… but also incorrect… Can’t be very incorrect, it seems to me!

The original list order comes from pragmatic marketing’s list of eight characteristics. That said, I think valuable is the most important – no reason to waste time on requirements without value. Correctness is the next most important characteristic – if we get it wrong, it doesn’t matter how well it is understood. I would follow that with unambiguous – even if we document the right stuff, and write it down accurately, it is worthless if our writing is misunderstood.

I would follow those with completeness and consistency, then attainable and verifiable. Then design-free, atomic, passionate, concise, and stylish.

I break it down into “stuff we must do to have a chance” and “stuff that makes us better / more efficient.”

How would you (or anyone else) prioritize these elements relative to one another?

I need to work through the detailed articles and reconcile with my own list of requirem1ent questions. This is a checklist I use to validate a requirement. I have a separate checklist for specifications in general, which covers the more general points like conciseness and unambiguousness.

At least we agree to put value at the top of the list! Do we agree to judge the merit of all the others using this criterion? To give one example: how much more value does a concise requirement add than a verbose one? My most concise requirements generally lack the immediacy of some of my more verbose ones. And requirements full of redundancy have an interesting characteristic, in my experience: they are less likely to be completely wrong!