Latency
graham.travers at bt.com
graham.travers at bt.com
Mon Feb 3 12:11:50 CET 2003
Henning,
Having reflected on this, as you suggested, I have a few comments, which are
embedded in your text below.
Regards,
Graham Travers
International Standards Manager
BTexact Technologies
e-mail: graham.travers at bt.com
tel: +44(0) 1359 235086
mobile: +44(0) 7808 502536
fax: +44(0) 1359 235087
HWB279, PO Box 200,London, N18 1ZF, UK
BTexact Technologies is a trademark of British Telecommunications
plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.
-----Original Message-----
From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
Sent: 01 February 2003 15:34
To: problem-statement at alvestrand.no
Subject: Latency
< snip >
The costs are also clear:
< snip >
- Different contributors: writing requirements may tend to attract the
professional standards-goers rather than academics, researchers and
developers.
GT - Why is this a cost ? Leaving aside the (dubious) definition of
"professional standards-goer", why are "academics, researchers and
developers" more likely to understand what the industry needs than other
people, who just may be working on operational systems in the real world ?
< snip >
- Additional opportunities for obstructionism. It is easy to add ever
more requirements or argue, in the abstract, about requirements,
particularly if people are trying to 'position' their prospective solution.
GT - This may be true; but there's already plenty of opportunity for
obstructionism in arguments over which solution(s) to use.
< snip >
"The disadvantage of waterfall development is that it does not allow for
much reflection or revision. Once an application is in the testing
stage, it is very difficult to go back and change something that was not
well-thought out in the concept stage."
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci519580,00.html
GT - This is all the more reason NOT to rush to implementation / testing.
"Well it doesn't do what's required; but it's nearly finished, so we can't
change it now." is not an attitude that's calculated to improve the
industry take-up of IETF work. The statement above is not an argument for
avoiding the requirements stage, but for iteration in the
requirements-design process ( which could actually take even longer ! )
< snip >
Henning
More information about the Problem-statement
mailing list