On Fri, Mar 30, 2007 at 04:25:21PM -0700, Alan Coopersmith wrote:
> I've just been told that they've been trying to work with Stephen Hahn for
> the last year to get our requirements and watching tools-discuss for
> discussion on this, so clearly there's a broken communication path
> somewhere.
For what it's worth, an ancient Bugtraq-oriented requirements doc I
was working on is included here. One can think about this document in
two ways: as a set of required changes to Bugtraq, or as a subset of
the generic requirements (replace "Sun" with "a distributor"). So
ignore the introductory paragraph, though it does illustrate how much
has changed in a year. Apologies for the SWAN reference and the
possibly obscure nature of the document for those unfamiliar with
Bugster and Bugtraq.
ident "@(#)d-bug-tracking.txt 1.4 06/03/08 SMI"
Defect Management Requirements in an Open Development Paradigm
Version 1.0 [DRAFT]
Requirements are specified for modifications to Bugtraq2[0] and its
front-ends.
1. Background
These requirements assume various existing characteristics of Bugtraq2
and its front-ends and are not intended to be generally applicable to
an arbitrary DMS. We do not believe such a generic set of requirements
would have value because wholesale replacement of Sun's existing DMS is
not contemplated on account of budgetary and schedule constraints.
1.1. Definitions
Following the lead set in [1], we define the following:
- Closed component: a Sun software product or product component which is
not open to external development. This would apply to components
which are available only under closed source licenses as well as those
which are open source but for which Sun does not welcome bug reports,
RFEs, or contributions of code and other materials.
- Sun-sponsored open component: a Sun software product or product
component of which development is led by Sun; in this model,
infrastructure and processes are managed primarily by Sun.
These components usually originated at Sun; this class includes both
those components which have always been open to collaborative
development and those which originated as closed components and are
making the transition. Previous releases of Sun-sponsored open
components which have not been opened are closed components.
- Imported open component: a product or product component developed
primarily by and for parties not affiliated with Sun and licensed
under open source terms to Sun for incorporation into one or more Sun
products. These components are developed using infrastructure and
processes managed by entities other than Sun, although Sun may be an
active contributor to them.
2. Scope
These requirements apply to Sun's DMS only, including the Bugtraq2
schema and Bugster, bugs-by-mail, Bugster External, Monaco, and all
related and supplementary front-ends. They are not intended to
constrain Sun's participation in the development of imported open
components nor to require changes to the design or implementation of any
system other than Sun's DMS.
No requirement here is intended to alter existing mechanism or policy
for making selected information (confidential and otherwise) available
to pertners or other outside entities. For the purpose of this
document, entities with such existing arrangements are "Sun
participants."
3. Conventions
The requirements are ranked by necessity, using the terminology proposed
in IEEE Std 830-1998 [2].
4. Requirements
E0. Universal access
With the exceptions identified below, all CR data stored in Sun's DMS
and pertaining to Sun-sponsored open components and imported open
components must be available for search, view, and modify operations to
participants with or without SWAN access. Data must become available to
all users at the same time. Neither SWAN access nor Sun employment may
be required to fill any of the generally recognised CR workflow roles,
such as RE and IE. One possible implementation would allow
external-to-Sun users to register for and receive Bugtraq logins, but
this specification is not intended to require this provided that:
(a) all front-ends hide this distinction; that is, the use of a valid
e-mail address or username in any field in which such an identifier
would normally be accepted must be permitted regardless of whether the
individual identified has a login of the type currently provided to Sun
users, and
(b) all activity logs, notes, and other fields are tagged with the
user's true and unique identity, even if that user does not have a login
of the type currently provided to Sun users.
E1. Front-end-independent credentialing
A user's eligibility to perform restricted actions must not be
determined by the class or accessibility of the front-end used to
request those actions. Specifically, an authorisation strategy which
allows restricted operations only when accessed from on-SWAN locations
is not acceptable.
E2. Default differentiated access
A mechanism must exist to distinguish at the subcategory level and
optionally at higher taxons among components for which CRs by default:
A. may be searched, viewed, and modified by anyone
B. may be searched and viewed, and/or have additional notes,
attachments, or other content added, by anyone, but may not have
existing content modified or removed by non-Sun participants
C. may be searched and viewed, but not modified, by non-Sun
participants
D. may not be accessed in any way by non-Sun participants
("confidential CR")
A mechanism must exist to distinguish customers which should have their
names displayed in SRs to non-Sun participants from those which should
be masked. Paying customers whose contrary preference is not explicitly
known must be masked.
E3. Selective differentiated access
A mechanism must exist to indicate that a CR is private to Sun and no
part of it may be made accessible to non-Sun participants, even if the
CR's subcategory would otherwise cause it to be accessible.
E4. Alternate fields for confidential information
Storage must be provided within each CR for information which must not
be disclosed to non-Sun participants even if the CR containing it is not
a confidential CR. This storage must include (a) one or more note
fields, (b) an attachment pool, and (c) the existing fields used to
store escalation and other data specific to Sun's business processes and
unrelated to development. These are to be clearly distinguished from
non-confidential fields by name in the schema and textual front-ends and
visually in graphical front-ends.
E5. Differentiated messaging
All mail or other messages sent by the DMS to user-supplied addresses
(such as but not limited to a CR's interest list or a subcategory's
initial evaluator) containing CR data must enforce the confidentiality
of fields described in (E4) and CRs described in (E3).
E6. Access control enforcement
All front-ends must enforce the access restrictions described in (E2),
(E3), and (E4). It is not the intent of this specification to require
any particular method of enforcement.
C7. Multiple message destinations
Any field in which a single group e-mail address is typically used, such
as the initial evaluator field, must be extended so that distinct
messages may be sent to at least two destinations, one of which is
eligible to receive confidential information and the other not.
O8. Notification of changes to confidential information
An address which is not otherwise eligible to be sent confidential
information may instead be sent an indication that the confidential
information is present or has changed. If sent, this indication must
not include any part of the confidential content.
References
[0] http://bugtraq.central/
[1] Labrec, Charlie. Untitled [Defect management approaches], 2006.
[2] IEEE Std 830-1998, "IEEE Recommended Practice for Software
Requirements Specifications", 1998.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
