On Fri, Sep 20, 2013 at 6:20 AM, Harald Alvestrand <harald@xxxxxxxxxxxxx> wrote:
I'd like to snippet Phil's suggestion to an abbreviated version of one sentence, becaue I think this is right on.To my mind, the first thing to focus on is making our specs readable, so that it's possible to understand that they have not been compromised.
On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
The issue we need to focus on is how to convince our audience that our specifications have not been compromised
That means that complexity is our enemy.
There are two types of unnecessary complexity. One is caused by having useless mechanism and the other by insufficient abstraction. It is not always possible to distinguish one from the other.
The key in my view is to look at use cases and requirements and look to see if the need for multiple features is driven by a requirement or not.
For example, do we really need 30 different authentication algorithms in a protocol? Whenever we talk about authentication we end up with a new framework on the existing frameworks rather than just picking one.
Restricting requirements to those driven by use cases helps cull that type of complexity. 'Support the SPLUNGE password authentication' might be a useful requirement or it might not. If there is an existing infrastructure of SPLUNGE users that we need to interoperate with, then there will be a use case. If the requirement has been inserted by the academic who designed SPLUNGE then there is no supporting use case.
The EASA requirements analysis scheme we tried to use at CERN had a practice that I have adopted in some of my specs of labeling each requirement with a short form label [R-SPLUNGE] which then allows for automated checking for consistency to show that each requirement is supported by at least one use case and show which requirements are met and thus which use cases.
Website: http://hallambaker.com/