[Safety-related]: Software, Requirements and System parts



Date view Thread view Subject view Author view

Jonathan Moffett (jdm(at)cs.york.ac.uk)
Thu, 28 May 1998 08:48:52 +0100


I am forwarding this to the list as it was filtered out because it did not contain "safety" in the subject line. Jonathan Moffett Safety-critical mailing list moderator >Date: Wed, 27 May 1998 21:11:36 +0000 >To: hise-safety-critical(at)cs.york.ac.uk >From: Felix.Redmill(at)ncl.ac.uk (Felix Redmill) >Subject: Software, Requirements and System parts >Sender: hise-safety-critical-request(at)cs.york.ac.uk >Reply-To: hise-safety-critical(at)cs.york.ac.uk > > >***** FOR THE ATTENTION OF THE MAILING LIST ADMINISTRATOR ***** > >The following message lacks a Subject: line or >lacks the keyword "safety" from the Subject: line. > >Please resubmit the message, if appropriate, to >"hise-safety-critical". > >***** FOR THE ATTENTION OF THE MAILING LIST ADMINISTRATOR ***** > >Ann Wrightson wrote: > >>Hardware and software are very often talked of as >>(at)natural parts' of a system. That makes sense from one >>point of view - software and hardware design activities >>are usually separate, hardware and software can be bought >>and sold separately, etc. >> > >>Because computer hardware (unlike DNA) is built so it can be >>loaded with different software, there is, I suggest, an illusion of >>separate-part-ness there which should be dispelled when it is seen >>that hardware and software are, in action, inseparable. >> > >Of course they are, for in a machine software IS hardware; it is A STATE OF >THE HARDWARE. Set up a row of binary switches in front of you and adjust >them to represent any code you like and you'll see what I mean. The code >can be represented in other ways, such as on paper, but the lights which >the switches control will not be controlled by the paper, only by the >hardware which are the switches. So the real (servicable) software is a >state of the hardware. > > >>So I suppose in a way I agree with David Parnas's view of requirements >>as documentation - but so is software. This is stretching the concept of >>documentation quite a bit - so I guess we need a new concept. > >You can document hardware textually, diagrammatically, ... Is the >documentation hardware? Hardware exists as a tangible entity, however many >other representations of it are drawn up. > >In the case of requirements, clearly the documentation is not the real >thing, as evinced by the number of rejected systems. So the documentation >is an attempt to represent the requirements. Thus, the requirements are NOT >documentation; they are represented, often inaccurately, by documentation. > >If we decide that 'software' is an entity in its own right (rather than, >say, the documentation of an algorithm), we find that it is represented in >at least two ways; on paper and in the machine. So I'm back to where I >started: the paper representation is the documentation of the real >software, which is a state of the hardware. In this case, though, unlike in >that of requirements, the documentation is a faithful representation of the >'real' thing. > >So, does software exist in two forms, or one? And, if so, does the question >arise as to whether one is more softwarish than the other? > >Felix. > > > >


Date view Thread view Subject view Author view