The important thing is to understand that real-time software is a strict subset of "software with timing constraints".
If you want to be nitpicky about it, all software has timing constraints: if the algorithm is correct, but it's not gonna give you the correct answer until one billion years from now, then it's not very useful. So one can make a quite reasonable argument that all software has some sort of timing constraint. Even, say, a sorting routine has some timing requirements.
Does that mean we should say that all software is real-time software? No. That stretches the definition of real-time software to a point where it becomes useless. I would never call mergesort a real-time application (even though there is an upper bound on the running time of mergesort).
Instead, we should realize that not all timing requirements are created equal. Empirically, some timing requirements are very strict and are non-trivial to achieve, while others are straightforward to achieve. For instance, "the brakes must be applied within 30 ms of pressing the brake pedals" is non-trivial to achieve: if we've got some generic software running on a multiprocessor polling the brake pedal sensors, if we are not careful, we could easily end up failing to notice the brake pedal has been pressed for over 30 ms. For instance, maybe a garbage collector kicks in and runs for 50ms, preventing the application code from running for the duration; maybe several other processes are running and the sensor polling process doesn't get a chance to run for a stretch of 50ms; or any number of other possibilities. So that would be an example a situation where we need to apply special techniques to ensure that the timing requirement is met. Software like that is called real-time software.
In contrast, when we have software that technically has some timing requirements but where the timing requirements are relatively easy to achieve, we do not call it real-time software (in general). For instance, consider a web browser/web site: "when I click on a link to CNN, the CNN web page should start to show up within a few seconds, or a minute at most"; or, "when I open a web page in the browser, it should either load within a minute or so, or else the browser should show a visible indication that it was unable to load the page". Those are timing requirements that do not require special real-time techniques to meet. In particular, no one would call your web browser an example of real-time software. There might be some timing requirements, but no one would call your web browser a real-time system, and your web browser was not built using real-time implementation techniques.
With that understanding, it is straightforward to see that there is plenty of safety-critical software that is not real-time software. There are safety-critical systems that are not built using real-time techniques because, while they might have some sort of timing requirement, the timing requirement is easy enough to meet that there is no need for special real-time techniques or systems.
For instance, think of a medical X-ray machine. One requirement might be "when the doctor programs it to irradiate at X units of beam strength for Y minutes, the machine does it, and it does not generate more than X units or run for more than Y minutes". Another requirement might be "the machine beeps whenever it is emitting radiation". Both of these requirements can be achieved without real-time systems. Consequently, I would call this a safety-critical system but not a real-time system.
