|Philip Hallam-Baker||Jan 26, 2001 9:05 am|
|From:||Philip Hallam-Baker (pba...@verisign.com)|
|Date:||Jan 26, 2001 9:05:03 am|
I don't object to the ESA scheme and don't propose to change our approach at this point -- your explanation of the approach is very helpful (in fact I'm glad I screwed up in public, because I suspect that others will also benefit from your explanation. I apologize if I made you repeat yourself; I didn't get onto all of the subgroup lists immediately).
Actually I didn't actually explain the terms, thought I would try them on folk first using the 'is this at first sight obvious enough for people to understand test'.
The background to this is work I and others did at the MIT AI lab in structured dialogue. One of the projects was an 'open meeting' for Vice President Al Gore's 'Reinventing Government' campaign. This was generally considered a success and I have been wanting to try similar in a standards forum.
The basic idea of the ESA requirements analysis is to structure a design document. In the form I suggest we apply there would be four main headings:
1) Requirements The most abstract statement of the requirements that the specification must meet. E.G. space probe must survive temperature changes during voyage
2) Constraints Constraints under which the specification is to be applied E.G temperature varies between -200deg Celcius to +2000 Farenheight
3) Architecture (Esa term is Architectural Specification) Means of meating the requirements under the specific constraints E.G. use thermal bricks
4) Specification (Esa term Design specification) The specific means of meeting the requirements. E.G. use termalite 234 bricks cat #442-129409(b)
For convenience each clause has a label which begins either R, C, A or S to denote the category and is displayed in square brackets [S-Whatever].
The basic premise is that when complete the document should satisfy the following criteria:
1) Every Architectural feature should satisfy at least one requirement or constraint statement
2) Every Specification feature should satisfy at least one architectural statement
3) Every Requirement should be satisfied by at least one Architectural statement (we are not going to do this being a valid statement :-)
4) Every Constraint should be satisfied by at least one architectural element.
In the finished spec one ends up with a matrix of correspondences in each section. this is very usefull in making sure that the requirements were actually satisfied...
It is a rather more formal and structured method of discussion than is normal in IETF process but I have used it successfully in the past with CERN physicists.
The trick to requirements analysis is that most engineers think in terms of solutions first rather than problems. Typically the requirements are reverse engineered out of the specification. Our brains are not designed to start from abstract concepts (use tool to kill wilderbeast), it works backwards from particulars (use club to kill wilderbeast, use stone to kill wilderbeast) to generalised abstract ideas.
PS: If this works we can apply structured threat analysis as an encore :-)