CONSTRAINTS AND REQUIREMENTS SUBCOMMITTEE

Meeting 8 - 10 July 1997 at Il Ciocco, Italy. 

PARTICIPANTS:
  Greg Peterson - petersgd@aa.wpafb.af.mil - Air Force Research Lab
     (acting chair)
  Shashi Kumar - shashi@ele.kth.se - Royal Institute of Technology (Sweden)
  Lecj Jozwiak - lech@ics.ele.tne.nl - Eindhoven University of Technology
  Giulio Gorla - Giulio.Gorla@italtel.it - Italtel
  Steve Schultz - ses@ti.com - Texas Instruments

Lots of debate about what precisely constitutes a constraint as opposed to
a requirement.  Debate ensued about a definition.  A couple general
definitions emerged, and the overall group can try to decide on one.  The
basic question of separating constraints from requirements was settled
within the group, and in the overall group, with both concluding that they
should be considered together.

REQUIREMENTS = CONSTRAINTS + OBJECTIVES; where constraints include precise
(mathematical) definitions that can be checked and objectives are general
goals without direct means to evaluate compliance.

An alternate definition included requirements as normative statements about
the overall system or transfer function, with respect to its interaction
with the environment.  Constraints are like requirements but affect the
subsystems and can be assigned or distributed among subsystems.
Specifically, constraints are implementation dependent and arise from
design choices.

Constraints

1)  We must be able to specify and verify partial descriptions
2)  We must be able to say what a given parametric value means
3)  We need to track constraint satisfaction
4)  We need to be able to "distribute" a constraint among components
5)  We need to reflect measurements up a hierarchy and compare to constraints

Requirements - based on slides from Steve Grout.

The current state of the REQUIREMENTS SUBCOMMITTEE, as described in the
slides by Steve Grout, seems to indicate a fair amount of ground work has
been completed in determining what domains exist for requirements, what
types of requirements exist, what specific requirements may be specified,
what operations or capabilities need to exist in support of requirements.

A motivational example of a methodology was created as a means of
illustrating the issues and generate discussion.  The definitions of
constraints and requirements are similar enough to conclude that the group
should include both areas for the foreseeable future.  The scope of the
group is as discussed in the overall SLD meeting, but it may be helpful to
mention the term "electronic" or some similar word to help convey the
focus of the group on considering systems containing electronics hardware,
software, and possibly also including mechanical, optical, and analog
models as needed.

Some future directions for the group were developed and may need some more
refinement.  

First, a COLLECTION OR TAXONOMY OF CATEGORIES, CLASSES, TYPES, AND EXAMPLES
OF CONSTRAINTS should be developed by 1Q98.  The direction of the group to
date seems to have been to identify all of them.  The sense of the group
was that this will not be possible or practical, and that
requirements/constraints handling systems or processes must be able to
handle extension, inheritance, or other means to include or refine
requirements, perhaps using object-oriented mechanisms.

Once this collection or taxonomy is collected, work can ensue to create a
RECOMMENDED PRACTICES document which can be used with the taxonomy for
driving the creation of standards as needed.  We need to get requirements
collection companies, other tool vendors, and systems design houses
together on this to get agreement on the best approach.

Once a recommended practices document and taxonomy are completed, we can
start to work towards a STANDARD TOOL INTERFACE AND FORMAT FOR
REQUIREMENTS.  In the short run, we should be able to use the taxonomy and
recommended practices to identify some high priority constraints.  We'd
like to be able to use the high priority constraints in some type of
demonstration and move towards a trial use or other standard on this as a
way to trailblaze for the more general problem.

All of the above activities will move towards the creation of a standard
interface and format for requirements and constraints.  This is a tough
problem and will take a while, so we have the phasing listed above.

Lots of SHORTER TERM ACTION ITEMS need to be covered.  
 - We need to agree on definitions of constraints and requirements.  
 - We need to get some inputs from the REQUIREMENTS CAPTURE folks (such as
RDD-100 and DOORS).  
 - Prototype interfaces between capture tools and HW and SW design tools
needs to be done as well.  
 - Not to mention all the back-end requirements that may be needed.