Well hello there, it’s been a while hasn’t it?
In the absence of our good host I thought I’d just pop in and offer some advice on how to use statistics for requirements compliance. Now of course what I mean by requirements compliance is that ticklish situation where the customer has you over the proverbial barrel with an eye-gouger of a requirement. What to do, what to do. Well dear reader all is not lost, what one can do is subtly rework the requirement right in front of the customer without them even recognising it…
No! I hear you say, ‘how can this wonder be achieved Screwtape?’
Well it’s really quite simple, when one understands that requirements are to a greater or lesser extent ‘operationally’ defined by their method of verification. That means that just as requirements belong to the customer so too should the method one uses to demonstrate that you’ve met them. Now if you’re in luck the customer doesn’t realise this, so you propose adopting a statistical proof of compliance, throw in some weaselling about process variability, based on the median of a sample of tests. Using the median is important as it’s more resistant to outlier values, which is what we want to obfuscate (obviously). As the method of verification defines the requirement all of a sudden you’ve taken the customer’s deterministic requirement and turned it into a weaker probabilistic one. Even better you now have psychological control over half of the requirement, ah the beauty of psychological framing effects.
Now if you’ll excuse me all this talk of statistics has reminded me that I have some souls to reap over at the Australian Bureau of Statistics*.Mmm, those statisticians, their souls are so dry and filled with tannin, just like a fine pinot noir.
Till the next time. Yours infernally,
*Downstairs senior management were not amused by having to fill out their name and then having a census checker turn up on their doorstep asking whether they were having a lend of the ABS.