Proposed report of the Requirements & Requirements-Capture Committee of
SLD.

Members: Steve Grout (chair), Ron Waxman, Jean Mermet, Steve Schultz, Greg
Peterson, Shashi Kumar, Lecj Jozwiak, Giulio Gorla

Chair's proposed RRC position:

 - Thanks very much to Peterson, Schultz, Kumar, Jozwiak and Gorla for
their review of teh powerpoint RRC working materials sent to Il Ciocco
meeting. 

 - Discussion on defining what constitutes a constraint vs requirement was
very useful.

 - All results should be added to the requirements information taxonomy

 - Agrees fully with the Il Ciocco meetings conclusions about what actions
the RRC should proceed to do and/or complete:

   + Create and complete a taxonomy of requirements and constraints
     information categories, classes, types, with examples by 1Q98.
     o per the Il Ciocco discussions, propose to add the following to the
       taxonomy:
       - Any additional categories, types, etc., that may not have been
         considered as yet, e.g., back-end RRC.
	 o Chair agrees that it will not be possible to identify
           everything.  The need is to identify 'most' and a broad enough
           group so the RRC considers enough types so that the SLDL
           activity on RRC will be well-based.  Happy to add others
	   at any time.
       - Add Inheritance, extensions, object-oriented mechanisms/concepts
       - Taxonomy to include 'columns' concerning
         + typical type of representation of RRC, e.g., written, 'understood',
           machinable design rule, part of SLDL or HDL, back of
           envelope, etc.
           o Chair believes that SLDL requirements to captured and tracked
             down thru the system implementation will be
             composed always as a very wide range of ways that they are
             manifested.  SLDL will only have SOME of these as machinable,
	     parametric-able, decomposable/distributable, trackable,
	     backannotateable, and comparable. (Are there other '-ables'
	     of requirements life-cycle? -  'Your mileage may vary' :-)
         + degree of machinability
	 + degree of being able to track thru system implementation
           lifecycle.
	 + degree of being able to decompose each entry where each RRC taxonomy
           entry applies to and is derived from teh previous step in teh
           implementaiton life cycle.
	 + Other Taxonomy columns?
	   o Suggestions for others are requested.
	 
   + As part of this activity, we need create complete definitions for
     constraints, objectives, requirments, and other related terms.
     o Chair proposes that an electronics-industry-wide precise set of
       agreed-to definitions may not be possible.  On the other hand, the
       ELEMENTS of these definitions are probably applicable.  That is, we
       may have to create a definition for a certain type of RRC
       information and then arbitrarily giving it a name, with that name then
       being used for SLDL activity going forward.  

   + Get inputs and feedback from RRC domain experts, requirements
     collection companies, system design houses (who work extensively on RRC),
     and related RRC EDA professionals, to get agreement on what the best
     approach to take on implementing RRC support should be.

   + Create a RRC Recommended Practices document working from the taxonomy
     and inputs on the implementation approach (assuming this is teh approach
     to take).

   + Create a standard tool interface and format for RRC based on 
     the taxonomy and inputs on the recommended practice approach.
     o This probably needs of course to be coordinated with the SLDL
       architecture approach, i.e., determine whether the
       requirements/constraints input to SLDL is a direct part of SLDL or
       should be a separate interface.