Re: profiles/modules/levels

I was also looking at this issue and I tend to agree with Andrew.  This is 
my proposal:

GLx : Address methodology for representing technical requirements

         CP x.1 : Indicate methodology to be implemented.
Rational for this checkpoint should indicate the benefits of knowing which 
methodology was chosen.

Ex/Tech. : should include examples for profiles, level, modules or any 
other methodology. The rational for each could be included here.

Note: this guideline will allow the flexibility in choosing a methodology 
for representing the technical requirements.

CP x.2:  If applicable, indicate if chosen methodology is mandatory for 
conformance . ( was used in profile CP.)

CP x.3: if applicable, indicate any mandatory conditions or constraints on 
the use of chosen methodology. ( was used in module CP)

                 CP x.4: Define chosen methodology relationship and 
interaction with other dimensions of variability. ( was used in profiles, 
modules, levels CPs)

                 CP x.5: If applicable , define any minimal requirements in 
chosen  methodology.   ( was used in profile CP)

                 CP x.6  : If applicable, address rules in methodology 
chosen. ( was used in profile CP)

Sandra

At 02:45 PM 4/28/2003 +0100, Andrew Thackrah wrote:


>  My take on DoV
>
>  I think the role of SpecGL should be to advise the author that DoV is 
> something that
>  they should be thinking about when writing a spec. We can include 
> examples of
>  things like levels, profiles etc to illustrate what we mean. However, 
> since it seems
>  from QAWG discussion that there are differences of opinion on our 
> definition of
>  p/m/l then I don't think we are in a position to impose a rigid 
> definition on others.
>
>  Better to say "consider the possibility of using some kind of DoV 
> structure, look at
>  these specs for examples of good practice. If it suits your technology, 
> create a
>  DoV architecture. It doesn't matter if your DoV does not conform to 
> someone elses
>  definition of a profile or whatever - all you have to do is document 
> your chosen system
>  and if you have more than one DoV then document the relationship between 
> them."
>
>  So I think in SpecGL all DoVs should be under one Guideline. We should 
> mention
>  p/m/l as examples but not be prescriptive about them. After all, we are 
> encouraging
>  people to think about the design of their technology, not trying to 
> shoehorn them into
>  the design of someone elses technology.
>
>  -Andrew

Sandra I. Martinez
National Institute of Standards and Technology
100 Bureau Drive, Stop 8970,
Gaithersburg, Md. 20899

(301) 975-3579
sandra.martinez@nist.gov

Received on Monday, 28 April 2003 10:59:32 UTC