Requirements/Architectural analysis

[Philip Hallam-Baker <pbaker@verisign.com>]

> 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.

		Phill

PS: If this works we can apply structured threat analysis as an encore :-)