From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Wed Aug 04 2004 - 21:52:58 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id 8BABA26203
=09for <re-online@it.uts.edu.au>; Tue, 3 Aug 2004 23:14:23 +1000 (EST)
Received: from hotmail.com (bay12-f34.bay12.hotmail.com [64.4.35.34])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id 44DBC1D63B3
=09for <re-online@it.uts.edu.au>; Tue, 3 Aug 2004 23:14:18 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Tue, 3 Aug 2004 06:14:16 -0700
Received: from 128.237.11.72 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Tue, 03 Aug 2004 13:14:16 GMT
X-Originating-IP: [128.237.11.72] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Tom,
Excellent set of arguments with examples. I totally agree in principle wit=
h
only minor variations in the details. Let us hope that the security
community learns to use these techniques to create quantified unambiguous
requirements.
Don
Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
Software Engineering Institute (SEI)
Carnegie Mellon University (CMU)
Pittsburgh, PA 15213-3890
(412) 268-6874
dgf@sei.cmu.edu
http://www.donald-firesmith.com
>From: Tom Gilb <tom@gilb.com>
>Reply-To: re-online@it.uts.edu.au
>To: Didar Zowghi <didar@it.uts.edu.au>
>CC: re-online@it.uts.edu.au
>Subject: [re-online] How should you specify Security Requirements
>Date: Mon, 2 Aug 2004 20:19:06 +0200
>
>
>>Don, I will give some feedback in CAPS if I may. I agree with you of
>>course and the Security guys are making lame irrelevant excuses.
>I don't do threads, but what I say can be copied anywhere. Tom@gilb.com,
>www.gilb.com see particularly Competitive Engineering book manus and
>chapter on Scales of Measure.
>
>> > Everyone,
>> > Can anyone think of ways to quantitatively specify security
>>requirements
>> > that capture "how much" security (e.g., identification,
>>authentication,
>> > authorization, confidentiality, integrity, availability,
>>non-repudiation,
>> > etc.) is needed and required?
>>ANYTHING CAN BE EXPRESSED QUANTITATIVELY
>> > I am having an ongoing (and relatively unfruitful) discussion with
>>some
>> > security experts who state that it is essentially impossible to
>>specify
>> > quantitative security requirements
>WELL I CHALLENGE THEM TO PROVIDE ME WITH ANY EXAMPLE THAT CANNOT BE
>QUANTIFIED.
>(NOTE THAT SUCH PEOPLE OFTEN MIX UP THE CONCEPTS OF QUANTIFICATION AND
>ACCURACY OF MEASUREMENT. IT IS IMPORTANT TO CLARIFY WHAT WE ARE DEBATING
>AND NOT ASSUME SHARED TERMINOLOGY).
> FROM MY GLOSSARY OF PLANGUAGE (@ WWW.GILB.COM)
>--------------------------------------------------- paste from
>Glossary--------------------------------------
>
>Quantify, To=09=09=09=09=09Concept *385 May 9, 2003 B
>To quantify is to specify numerically.
>
>Notes:
>1. To articulate a variable attribute, using a defined scale of measure,
>and specifying one or more benchmark or target levels on the Scale. The
>resulting specification is =E2=80=98quantified=E2=80=99.
>
>2. In particular, we need to be clear that =E2=80=98to quantify=E2=80=99 i=
s not
>identical to the concept of =E2=80=98to measure.=E2=80=99 Measuring is the=
act of
>determining where we are, on a defined scale of measure, in practice by
>using a Meter.
>
>
>
>Quantification is a type of specification that is a pre-requisite for
>other processes, such as Estimation, Measurement, Testing, and Feedback
>Control.
>
>3. Quantification must not be confused with estimation, either. You can
>quantify without estimation, and without measurement! Estimation is to
>determine a particular (qualifier specified) past or future number, on a
>defined scale of measure.
>
>4. In Planguage, quantification begins with the definition of a Scale.
>Quantification continues, and takes on more specific meaning by using
>benchmarks, targets, assumptions and the many other specification
>parameters, that relate to the defined scale of measure.
>
>Dictionary Definition of =E2=80=98Quantify=E2=80=99
>1. To determine or express the quantity of; indicate the extent of;
>measure2. To express in quantitative terms, or as a numerical
>equivalentLogic to make the quantity or extension of a term or symbol
>clear and explicit by the use of a quantifier, as all, none, or some.
> Webster=E2=80=99s New World=E2=84=A2 College Dictionary (Third Edition).
>Our definition of quantify ((identical to variant 2 above) does not admit
>to the term =E2=80=98measure=E2=80=99 which is contained in this definitio=
n (variant
>1), and in common use of the words. For us =E2=80=98measurement=E2=80=99 i=
s a quite
>distinct activity (like variant 1 above), based on the quantification,
>(but not identical to it).
>
>Related Concepts [Quantify, To *385]:
>=E2=80=A2 Scale *132
>=E2=80=A2 Meter *093
>=E2=80=A2 Measure, To *386: To measure is to determine the numeric level o=
f a
>scalar attribute, using a defined process.
>=E2=80=A2 Estimate, To *059
>
>Type [Quantify, To *385]: Verb.
>
>-------------------------------------------------------
>Measure, To=09=09=09=09=09=09Concept *386 May 9, 2003
>To measure is to determine the numeric level of a scalar attribute under
>specified conditions, using a defined process, by means of examining a
>real system.
>
>Notes:
>1. Measurement is done on the defined Scale, with respect to specified
>qualifier conditions.
>
>2. Measuring is done using defined Meters.
>
>Example:
>Usability:
>Scale: Mean Time To Learn.
>Meter [Experts]: Use the upper 5% of our experienced staff in tests.
>Meter [Novices]: Use 10% of current year=E2=80=99s intake of new people.
>Fail [Experts, Complex Task]: 15 minutes.Goal [Novices, Simple Tasks]: 10
>minutes.
>Two different Meter specifications are made in order to make it clear how
>the two different targets shall be measured.
>3. Measuring is distinct from quantification and estimation.
>Quantification is merely defining an attribute with the help of a scale o=
f
>measure, and benchmarks and/or target values. Estimation is trying to
>determine future results based on past data.
>
>Related Concepts [Measure, To *386]:=E2=80=A2 Scale *132
>=E2=80=A2 Meter *093
>=E2=80=A2 Quantify, To *385
>=E2=80=A2 Estimate, To *059
>
>Type [Measure, To *386]: Verb.
>------------------------ end paste from concept glossary for PLanguage
>
>
>
>>and that architectural constraints to
>> us e
>> > certain state-of-the-practice security countermeasures, mechanisms,
>>and
>> > tools is as good as it can get (e.g., "The system shall incorporate
>>an
>> > intrusion detection mechanism.")
>
>TG:
>1. architecture constraints are only one class of requirement. They are
>limited to
>1a. their precision ( the above example is very vague)
>1b. their actual implementation effects ( qualities and costs)
>1c. their intent ( why they were stated, needs to be stated, in order to
>avoid misuse and unintended use of the constraint.
>1d their authority level and consequent priority.
>IT IS NOT TRUE THAT THEY ARE THE ONLY VIABLE MECHANISM. THIS STATEMENT
>COULD ONLY BE MADE BY A PERSON IGNORANT OF HOW TO SPECIFY THE QUALITY
>LEVELS OF SECURITY QUANTITATIVELY ( WHICH IS THE ACKNOWLEDGED PROBLEM
>HERE).
>
>MORE ON ALL THE ABOVE ISSUES IN MY WRITINGS ON IMPACT ESTIMATION TABLES (
>SEE CE BOOK CHAPTER ON THIS) AND MY WRITINGS ON PRIORITY MANAGEMENT ( SEE
>PAPER ON WWW.GILB.COM BY GILB AND MAIER))
>>
>> > Basically, my argument IS that we can specify testable requirements,
>>is met
>> > with the counter arguements that developers will not sign up for suc=
h
>> > requirements,
>TG: DEVELOPERS DO NOT UNILATERALLY HAVE THE RIGHT TO 'SIGN UP' FOR
>REQUIREMENTS MADE BY HIGHER LEVELS OF AUTHORITY. THEY CAN IN THE ROLE OF
>DESIGNER/ENGINEER/ARCHITECT GIVE INFORMATION ABOUT TECHNOLOGICAL OPTIONS,
>THEIR EFFECTS AND COSTS, AND LEAVE IT TO PROPER STAKEHOLDERS TO DECIDE
>WHAT THEY WANT TO DO ABOUT IT.
>
>>that security testing always breaks the security of
>> systems,
>
>TG: IRRELEVANT ARGUMENT. WE ACKNOWLEDGE THAT NO SECURITY SYSTEM IT
>PERFECT. WE ALSO ACKNOWLEDGE THAT ALMOST PERFECT SECURITY MAY COST MORE
>THAN IT IS WORTH. SO THE QUESTION IS ONLY WHETHER THE AGREED AND COSTED
>REQUIREMENTS LEVELS OF SECURITY ARE MET BY A DEVELOPED SYSTEM.
>
>> > and that the arms race between systems developers and attackers
>>obsoletes
>> > any testable requirement anyway.
>>TG: GENERALLY TRUE ABOUT ANY SYSTEM IN A COMPETITIVE ENVIRONMENT AND
>>ABOUT ANY COMPETITIVE QUALITY LEVEL. IRRELEVANT ARGUMENT. NOT RELEVANT A=
S
>>AN ARGUMENT ABOUT NOT SETTING AND MEETING SOME REQUIREMENTS. REF DEMING'=
S
>>SAYING THAT THE PLAN DO STUDY ACT STATISTICAL PROCESS CONTROL CYCLE WILL
>>CONTINUE 'AS LONG AS THERE IS COMPETITION).
>
>> > I (DF) propose various testable requirements based on the concept of
>>a quality
>> > criteria (a statement about the system that provides evidence either
>>for
>> or
>> > against the existence of a=C2=A0 security quality subfactor) combined
>>with a
>> > threshold on some scale.=C2=A0 Examples of my suggested requirements
>>would be
>> > something like:
>
>> > "Authentication:=C2=A0 The system shall correctly verify the claimed
>> > identification of the user a minimum of 99.9% of the time when under
>> attack
>> > by an attacker of moderate sophistication using readily-available
>>tools
>> whe=3D
>> > n
>> > the attack lasts no more than 30 minutes."=C2=A0 whereby moderate
>> sophistication
>> > and readily-available tools are properly defined terms.
>>-----------------------------------------------------------------------
>>------------------------ above example looked at in Planguage, below, b=
y
>>Gilb-------------
>
>TG: in PLanguage (see CE www.gilb.com) we would normally identify all
>potentially ambiguous and unclear terms and define them as best we could.
>For example:
>
>Authentication:
>Scale: time when under attack by an Attacker of defined [
>Sophistication; default =3D Moderate] using defined [Tools; default=3D
>Readily-available]
>> when attack lasts no more than defined [Attack Duration; default 30
>>minutes].
>Meter [Acceptance] <they system itself will somehow verify the attainmen=
t
>of the Goal level??>.
>
>Goal [Next Release] 99.9%. Stakeholder: Generic Government Body.
>Past [Sophistication =3D Innovative Expert, Tools =3D Innovative Expert
>Level, Attack Duration =3D 1 hour or more] 99.998% <- <ref to real case
>inserted here>.
>
>Wish [ Sophistication =3D Innovative Expert, Tools =3D Innovative Expert
>Level, Attack Duration =3D 1 hour or more] 99.99998%
>
>
>------------ Related sample of Definitions-------------more and better
>could be done, this is to show 'style'------
>
>Attacker: defined as a person or instance initiating a security attack.
>Synonym: Attack Perpetuator.
>
>Tools: Set: {Readily-available, Innovative Expert Level, <etc.}.
>=09Readily Available: defined as: available with same ease as websites,
>textbooks and at low or no cost to obtain and use by the Sophistication
>level defined .
>=09Innovative Expert Level: defined as: tools invented by the Innovative
>Expert that no specific defenses can tackle, and generic defenses are ver=
y
>weak at dealing with.
>
>Sophistication: Set: {Moderate, Amateur, Expert, Innovative Expert}.
>=09Moderate: defined as: Attacker neither Amateur nor Expert or better
>=09Innovative Expert: defined as Attacker using new attack technology tha=
t
>is not directly and effectively dealt with by existing security tools and
>methods.
>
>Attack Duration: defined as: the clock time from first instance of the
>attempted attack (successful or not) ever identified until no further
>attacks are actively initiated by the same Attacker. This is not to be
>confused with the Attack Effects Duration.
>
>Attack Effects Duration: defined as: the clock time duration from first
>known successful attack until last known successful attack.
>=09Successful Attack: defined as: any attack that penetrates a system and
>causes delay, corruption or any other ill effects to a system, whether th=
e
>effects were intended or not by the perpetuator.
>
>
>
>
>> > Such requirements are rejected as infeasable to implement and not
>> acceptable to those responsible for ensuring the security of the
>>system.
>>
>TG: IT IS NOT CLEAR ON WHAT BASIS SUCH REQUIREMENTS ARE INFEASIBLE. A MOR=
E
>DETAILED ARGUMENT IS NECESSARY FOR ME TO REJECT THE ASSERTION. DOES IT
>HAVE SOMETHING TO DO WITH THEIR IGNORANCE IN HOW TO SPECIFY THE
>REQUIREMENT? DOES IT HAVE SOMETHING TO DO WITH THE AVAILABLE TECHNICAL
>SOLUTIONS 9 ARE THEY 'INFEASIBLE?) . WHAT DOES INFEASIBLE MEAN ( OUTSIDE
>STATE OF ART, TOO EXPENSIVE TO BE JUSTIFIED?). THIS WHOLE DISCUSSION MUST
>BE MADE ON A MORE SPECIFIC SOUND BASIS. RIGHT NOW, AS 'QUOTED' , IT HAS N=
O
>MERIT AS IT HAS NO SPECIFIC BASIS.
>
>> > I believe that:
>> > - Security requirements should be testable like all other types of
>> > requirements.
>TG: AGREED: THAT IS THE FUNCTION OF ONE OR MORE DEFINED 'METERS' AS IN TH=
E
>EXAMPLE ABOVE - TO DEFINE OR AT LEAST OUTLINE THE PROPOSED TEST PROCESS.
>> > - Security requirements can be quantified like all other types of
>>quality
>> > requirements.
>AGREED TG.
>
>> > - Security requirements should be based on the needs of the clients
>TG: AGREED, BUT I WOULD CALL THEM STAKEHOLDERS, AND WOULD DEFINE DIFFEREN=
T
>REQUIREMENTS FOR DIFFERENT STAKEHOLDERS
>
>>and
>> not
>> > watered down because of securities immaturity as a field, especially
>>with
>> > regard to requirements engineering.
>
>AGREED TG: REQUIREMENTS CAN NOT BE WATERED DOWN BECAUSE THE RESPONSIBLE
>REQUIREMENTS PEOPLE ARE IGNORANT. BETTER CLASS OF ENGINEER IS REQUIRED.
>
>> > - Systems should be built to pass security tests of a specific
>> quantifiable
>> > level based on an analysis of the associated security risks.
>
>TG AGREED: MORE SPECIFiCALLY:
>1. REQUIREMENTS ANALYSIS: analysis of stakeholder needs and values to
>begin with
>2. DESIGN: then analysis of available design technology to see what they
>cost, and possible conflicts with other prioritized requirements
>(including architecture constraints) for the same system.
>3. DECISION: THE STAKEHOLDERS, NOW (AFTER 1 AND 20 aware of their choices=
,
>will select required levels and expect to pay the estimated costs for
>reaching them.
>
>
>> > - Just because a system passes security tests at the time of
>>acceptance
>> > testing and does not pass the same tests later as attacks become mor=
e
>> > sophisticated is not a problem with either the requirements and
>>tests,
>> but
>> > rather a consequence of the arms race and merely means that the
>>system
>> must
>> > be updated over time to remain secure to the level needed by the
>> > clients/users of the system.
>TG: AGREED
>
>> > What do you think?=C2=A0 Am I being unrealistic to push for the same =
kinds
>>and
>> > characteristics of requirements for security that we as a discipline
>>have
>> > demanded for all other kinds of requirements?=C2=A0
>
>TG: IT IS A NECESSITY THAT THE SECURITY REQUIREMENTS ARE PROCESSED BY
>ENGINEERS IN THE SAME WAY AS ALL OTHER SYSTEM REQUIREMENTS. THIS IS THE
>ONLY BALANCED WAY TO UNDERSTAND VALUES AND PRIORITIES, RISKS ETC AND MAKE
>REASONED DECISIONS THAT STAKEHOLDER MANAGEMENT CAN UNDERSTAND AND ACCEPT.
>
>>Is security fundamentally
>> > different, making such requirements impossible?=C2=A0 Are my argument=
s
>>flawed?
>> > Can you think of other arguments to use with the security community?
>TG: NO -NOT DIFFERENT, NO NOT FLAWED ( BUT WE CAN ARTICULATE AND DIALOGUE
>WITH REAL OPPONENTS BETTER). YES (STATED ABOVE AND MORE AVAILABLE AS
>NEEDED)
>> What
>> > would you recommend if you were required to write or review security
>> > requirements?
>h
>SECURITY SPECIFICATION POLICY =C2=A9 Tom@Gilb.com, July 29 2004-----------=
an
>indented word version is attached or available from tom@gilb.com on
>request. Additional ideas are solicited, this is just a draft off top of
>mind.
>
>=09SECURITY SPECIFICATION POLICY =C2=A9 Tom@Gilb.com, July 29 2004
>=E2=80=A2=09Purpose: debate with re-online@it.uts.edu.au, and
>donald_firesmith@hotmail.com
>=09Security Requirement
>=E2=80=A2=09Security Requirements (SR) will be specified using Planguage
>o=09(or equally clear and structured requirements method. See www.gilb.co=
m
>CE for details)
>=E2=80=A2=09A clear distinction will be made between stakeholder needs and=
values
>on the one hand (using Wish, Stretch level of specification) and final
>agreed traded off requirement levels (Goal level;
>o=09 with appropriate qualifiers for when, where and under what condition=
s
>or events) .
>=E2=80=A2=09As far as possible the requirements will be set in terms of
>stakeholder effects: probabilities, % and timings:
>o=09 NOT unwittingly in terms of design constraints ( password etc.).
>=E2=80=A2=09When Architecture Constraints are set as requirements, then th=
e
>following justification and background will be specified along with the
>Constraint:
>o=09Authority, Rationale, Assumptions, Expected Costs, Risks, Issues,
>Approval Instance.
>=E2=80=A2=09The SR Spec. will be quality controlled for clarity,
>o=09and not be acceptable if the Major defect level (ambiguities, unclear
>specs) exceeds 1.0 /300 words of specification. (see Spec QC method in CE
>book manus at www.gilb.com for details of this process).
>=09Security Design:
>=E2=80=A2=09The Security Engineers will find and document one or more feas=
ible
>design options, for stakeholder review.
>=E2=80=A2=09They will NOT suppress knowledge of the existence or propertie=
s of
>designs from the stakeholder,
>o=09 because of any opinion they hold about cost or feasibility. That
>decision is for the stakeholders, not the developers to make.
>=E2=80=A2=09The Security Design options will be documented using an quanti=
fied
>Impact Estimation (IE) table.
>=E2=80=A2=09Detailed IE method in CE book ms IE chapter at www.gilb.com an=
d in
>Gilb papers in Crosstalk Dec 1998, =E2=80=9CImpact Estimation Tables:
>Understanding Complex Technology Quantitatively=E2=80=9D.
>o=09The impact estimation [for Security Design Options] will cover:
>=E2=99=A3=09All quantified and specified security levels needed or valued =
by
>defined stakeholders
>=E2=8E=A5=09(all types of impact on security for the entire system, not ju=
st the
>types this design is primarily focussed on)
>=E2=99=A3=09All conflicts or priority considerations with respect to all o=
ther
>non-security requirements (like performance, Usability)
>=E2=99=A3=09All related life-cycle costs (development and operations)
>=E2=99=A3=09All potential risks with the technology
>=E2=99=A3=09All unresolved issues about the technology
>=E2=99=A3=09All assumptions about the technology
>=E2=99=A3=09All useful sources such as websites related to the technology.
>(Sources for Evidence about the estimates)
>=E2=99=A3=09The degree of uncertainty about the estimates and the reasons =
for the
>uncertainty
>=09Security Evolution
>=E2=80=A2=09We assume that irrespective of designed security levels, the n=
eed will
>probably occur in the future, perhaps even before initial delivery of the
>system, for improvements in security design
>=E2=80=A2=09The system should be designed to be reasonably open ended
>o=09(adaptable at low cost, and not extraordinary costs caused by
>sub-optimization initially) for improved security design in the future.
>=E2=80=A2=09A responsible Security Engineering Owner will be assigned to h=
ave an
>overview of all security-related issues and to be consulted with any
>system engineering changes with respect to potential impact on security.
>=09Stakeholder Rights
>=E2=80=A2=09Stakeholders in the system
>o=09Are anyone potentially affected by the system attributes including
>users, authorities, the public.
>o=09They have the right to:
>=E2=99=A3=09Be asked about their needs
>=E2=99=A3=09Be analyzed with respect to their needs
>=E2=99=A3=09Be completely and clearly explained their rights and options i=
n a
>language that allows them to make intelligent decisions about their
>priorities
>=E2=99=A3=09Be shown the consequences of any changes that could possibly b=
e of
>interest to them
>=09Developer Obligations
>=E2=80=A2=09Developers (of the total system, and the security system in
>particular) are obliged to:
>o=09Determine all relevant stakeholders (all 35!)
>o=09Professionally analyze the needs and values of the stakeholders
>o=09Estimate satisfactory levels of security numerically for the
>stakeholders ( in preparation for a dialogue with the stakeholders)
>o=09Design security technology options professionally with respect to
>numeric impacts on security requirements, all other requirements and
>constraints
>o=09Discuss options intelligently and coherently with stakeholders
>o=09Accept the stakeholder decisions as to what they value and what
>resources they are willing to use in their security
>o=09Keep the stakeholders informed of security developments such at new
>threats and new security technology, experiences and cost levels.
>----------- end of 2004 security policy, a word version is available on
>request tom@gilb.com--------------
>
>
>HERE IS A MORE GENERIC POLICY I DRAFTED IN 2000
> SOFTWARE POLICY
>(suggestion, draft)
>
>Version SEPTEMBER 20 2000
>
>OWNER:
>
>Editor: Gilb@acm.org. Detailed practical technical background for this
>draft see www.result-planning.com and especially =E2=80=98Priority Managem=
ent=E2=80=99
>(116 pages manuscript).
>
>Purpose:
> to define a powerful framework
>for improving your organization=E2=80=99s ability
>to improve their software organization=E2=80=99s capability,
>as defined in their quantified objectives.
>
>Constraint:
>this policy should never exceed one physical page, to keep it focussed.
>
>.STAKEHOLDER VALUE:
> For all software and systems engineering projects
> we will formally identify all critical stakeholders, internal and
>external.
>We will identify their critical and profitably-served requirements.
>The requirements will be testable and, if variable,
> they will be quantified.
>Delivering this defined value to these stakeholders
>will be the primary focus and measure
>of all product development process activity.
>
>Rationale: to focus our efforts on critical needs, listen to =E2=80=98voic=
e of
>stakeholders=E2=80=99.
>
>.ENDS/MEANS CLARITY:
>project requirements will focus on the real =E2=80=98stakeholder-perceived
>value=E2=80=99 as the =E2=80=98requirements=E2=80=99.
>They will NOT allow design or strategy to replace the real stakeholder
>needs.
>Requirements and design to meet those requirements will be rigorously
>separated
>in terms of project specification and work processes.
>
>Rationale:
>extreme clarity of real needs,
>never confusing this with technology with good intent.
> Help engineers to focus efforts on serving and competing on the market.
>
>
>.NUMERIC CLARITY:
> all notions of qualities (stakeholder values) and costs will
> in all contexts (requirements, design impacts, project progress,
>contracts with customers and suppliers)
>be expressed in terms of numeric levels on defined scales of measure,
>and measured in practice with defined =E2=80=98Meters=E2=80=99.
>If it varies, if you can say =E2=80=98improved=E2=80=99,
>then you must convert these ideas into numbers
>on defined scales of measure,
>which become the language of the project.
>
>Rationale:
>we must have perfect clarity of the stakeholder-critical values,
>and numeric definition is the ONLY acceptable way to do that.
>This is necessary for multinational communication.
>This saves time to market, human resource and will more effectively targe=
t
>our stakeholder values.
>It allows feedback and correction processes to operate.
>
>
>.NUMERIC DEVELOPMENT PROGRESS:
> the primary instrument for tracking development progress will be
>the numeric progress for defined stakeholder values (product and service
>qualities)
> towards defined and agreed targets,
>with respect to time.
>A secondary set of measures will be with respect to the costs or resource=
s
>planned.
>
>Rationale:
>this management tracking concept is intended to allow projects to monitor
>their own progress realistically,
> using the same measures which any other level of managers would use to
>judge them.
>It is intended to be the main component for discussion and evaluation for
>any meeting, review, milestone or judgement.
> It should replace conventional milestone progress reporting.
>
>.WORK PROCESS ENTRY/EXIT CONTROL:
>All software engineering specifications (from contract to code)
>will be subject to formal entry and exit control.
>This is primarily numeric and based on =E2=80=98Major defects remaining=E2=
=80=99
>levels,
> i.e. economic suitability for downstream work processes.
>Default level maximum 1 major defect remaining per page.
>
>Rationale:
>to make sure that poor specification practices do not
>pollute downstream activity,
>and threaten time to market, human resources or product quality.
>
>Best Wishes, Tom
>
>--
>Tom@Gilb.com (or tgilb@attglobal.net)
>Www.gilb.com (other telephones/addresses)
>Fjordside Cabin (right now! - all Summer ) +47 64 93 84 64
>Home/Office +47 66801697 (If no answer within 4 rings this will be
>transferred to cabin number))
>Euro Mobile (SMS) +47 920 66 705
>Mail: Iver Holtersvei 2, NO-1410 Kolbotn, Norway
>
>
>I AM FROM FRIDAY 16 JULY AT THE CABIN FOR THE SUMMER. READING. WRITING AN=
D
>HAPPY TO DISCUSS PROFESSIONAL ISSUES WITH FRIENDS AND CLIENTS!
>
>
>--------------------------------------------------------------------------=
This archive was generated by hypermail 2.1.6 : Mon Aug 09 2004 - 09:00:25 EST