From: Andrew Gabb (agabb@tpgi.com.au)
Date: Wed Jan 21 2004 - 10:35:57 EST
Donald Firesmith wrote:
> Questions:
> - Do others have the same observations?
Yes. See my reasons at the end.
> - Do safety requirements exist at the software level, or only at the system
> level?
This is more difficult, because many developers see the system only as software + users. Again it comes in levels. Your safety requirements (and other requirements for trusted systems) *must* originate at the system level, but there will be many flowed down to both hardware and software subsystems and components.
> - Can anyone suggest analysis techniques that are appropriate for RE? Most
> seem to be designed for either reliability rather than safety (not the
> same!) or else after architecting when major components and their
> interactions have been identified. This is especially true for software
> (as
> opposed to system) safety requirements as software is dangerous when it
> interfaces with hardware (sensors or actuators) or users/operators.
Look for Hazard Analysis, FMEA and FMECA, all of which originate in the system and hardware world. I've know several projects to conduct hazard or safety reviews where scenarios are workshopped with users and interested others.
> - Can anyone suggest good examples of generally reusable product (as
> opposed
> to process) safety requirements?
Sorry, but no, and I would only expect to see these for specific product lines. Do no harm? Protect my data?
> - There are numerous publications (books, articles, conference papers) on
> safety engineering, but very little on safety requirements. Does anyone
> have any recommended reading on the topic?
You might like to check out DEF(AUST)5679 Standard 'The Procurement of Computer-Based Safety-Critical Systems'. You can download it from http://www.dsto.defence.gov.au/isl/defaust5679.html. This defence standard is admittedly process-based, but is reasonably pragmatic and looks at both system and software issues.
> I would be very interested in everyones' comments and experience.
> Thanks
> Don F.
You should note that when you talk about "acceptable level of safety" you are really talking about acceptable levels of damage or loss, which is how it's normally measured (like MTBF). Working with the military, I've noticed that they generally have no problems with the concepts of damage and safety, because they live with them, and many make decisions on that basis, day in and day out.
But some people have great problems with these concepts, probably due to socio-political influences, and this tends to make them averse to safety risk and, more importantly, averse to even *discussing* safety risk. (There are also legal and commercial influences which contribute - we don't want our customers to think that this can kill people, do we? So we use general caveats about using with parental supervision, etc.) This group - and they are probably a majority - will even strongly criticise others' pragmatic attempts on the subject. All this leads to euphemisms, obfuscations, risk hiding and omission in this area.
One way to test this is to ask the following question in a social group or dinner party: What is an acceptable level of road deaths in this country, and why? You'll be amazed at some of the answers, and at various attempts to avoid or theorise the subject - it makes some folks *very* nervous. As do discussions of 'triage', in the military and medical sense. It's also a good way to find out those who should never be given responsibility for any serious decision making.
Of course, there must *be* an acceptable level of road deaths - about the current level - or the government would spend much more money reducing it, ne?
Finally, customers and users are also averse to discussing acceptable damage levels, because they really want it "as good as possible for the money" - it *is* essentially a cost-effectiveness issue - and feel that signing up to damage levels would in some way compromise the quality of the product (and history tells us they are often right). Try talking to them about acceptable levels of availability - usually in terms of downtime - and you quickly find their 'needs' are unachievable. Of course, the fact that in most cases the 'engineers' themselves have little idea of what levels they can design and build to - for safety or availability - makes these discussions even more interesting.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 09:01:34 EST