From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66752102482bbdca X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Required Metrics Date: 2000/05/07 Message-ID: #1/1 X-Deja-AN: 620185576 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <8es65n$5hn$1@nnrp1.deja.com> <%MoQ4.7915$wb7.556168@news.flash.net> <8eulom$u8m$1@nnrp1.deja.com> <3914F1DC.A5EE1751@earthlink.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 957677921 216.215.86.137 (Sun, 07 May 2000 00:38:41 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Sun, 07 May 2000 00:38:41 CDT Newsgroups: comp.lang.ada Date: 2000-05-07T00:00:00+00:00 List-Id: "Robert I. Eachus" wrote in message news:3914F1DC.A5EE1751@earthlink.net... > Let me see if I can spread a little oil on the water here. Ken sees > the shalls, and is used to saying "Aha, a requirement. I must find all > such requirements--explicit, implicit, and derived--during requirements > analysis, allocate them, and plan to test them." Actually, it has nothing to do with the word "shall." It has to do with the word "requirement". It has nothing to do with allocation or testing. It has to do with whether requirements for which vendors believe any conceivable implementation will pass -- that is, it does not constrain their actions in any way whatsoever -- are requirements. If a vendor says, "I implemented this requirement a certain way" -- that is, the requirement was acknowledged in some form in the implementation -- it's a requirement. You can argue about whether it was the best implementation, or whether it's testable, etc. but that's a different argument. When a vendor says, "This requirement does not constrain me in any way," that's trouble. > But since the nature of Chapter 13 is to be very implementation > dependent, and difficult to test, users, especially embedded system > users, wanted a stronger "moral" commitment to features that they felt > were necessary, even if they were untestable. Such moral commitments > became Implementation Advice and Documentation Requirements. "Committment" implies that vendors take some specific action in response to the requirement. As we've seen, that isn't necessary to sign the DOC with a clear conscience. So, do you still believe this "moral" committment is being met? > Again, from a user's point of view, all this nit-picking is > irrelevant. A user who needs, say, a compiler which never takes more > than 1 millisecond for a clock interrupt is not going to be satisfied > with some random document. He or she is going to write those > requirements in the purchasing contract. Any such requirements in the > contract will not specify that this or that feature be documented, but > the actual required performance. Well, I would hope less often that they used to -- I know my group has sworn off these custom contracts wherever possible. After having spent well into seven digits on compilers in the last 15 years, I don't think we'll be back anytime soon.