6 SOFTWARE QUALITY $1.2 As reflected by the wording of its definition,robustness is by nature a more fuzzy notion than correctness.Since we are concerned here with cases not covered by the specification,it is not possible to say,as with correctness,that the system should "perform its tasks"in such a case;were these tasks known,the abnormal case would become part of the specification and we would be back in the province of correctness. This definition of "abnormal case"will be useful again when we study exception On exception handling.It implies that the notions of normal and abnormal case are always relative to a handling see certain specification;an abnormal case is simply a case that is not covered by the chapter 12. specification.If you widen the specification,cases that used to be abnormal become normal-even if they correspond to events such as erroneous user input that you would prefer not to happen."Normal"in this sense does not mean "desirable",but simply "planned for in the design of the software".Although it may seem paradoxical at first that erroneous input should be called a normal case,any other approach would have to rely on subjective criteria,and so would be useless. There will always be cases that the specification does not explicitly address.The role of the robustness requirement is to make sure that if such cases do arise,the system does not cause catastrophic events;it should produce appropriate error messages,terminate its execution cleanly,or enter a so-called "graceful degradation"mode. Extendibility Definition:extendibility Extendibility is the ease of adapting software products to changes of specification. Software is supposed to be sofi,and indeed is in principle;nothing can be easier than to change a program if you have access to its source code.Just use your favorite text editor. The problem of extendibility is one of scale.For small programs change is usually not a difficult issue;but as software grows bigger,it becomes harder and harder to adapt. A large software system often looks to its maintainers as a giant house of cards in which pulling out any one element might cause the whole edifice to collapse. We need extendibility because at the basis of all software lies some human phenomenon and hence fickleness.The obvious case of business software("Management Information Systems"),where passage of a law or a company's acquisition may suddenly invalidate the assumptions on which a system rested,is not special;even in scientific computation,where we may expect the laws of physics to stay in place from one month to the next,our way of understanding and modeling physical systems will change Traditional approaches to software engineering did not take enough account of change,relying instead on an ideal view ofthe software lifecycle where an initial analysis stage freezes the requirements,the rest of the process being devoted to designing and building a solution.This is understandable:the first task in the progress of the discipline was to develop sound techniques for stating and solving fixed problems,before we could worry about what to do if the problem changes while someone is busy solving it.But now6 SOFTWARE QUALITY §1.2 As reflected by the wording of its definition, robustness is by nature a more fuzzy notion than correctness. Since we are concerned here with cases not covered by the specification, it is not possible to say, as with correctness, that the system should “perform its tasks” in such a case; were these tasks known, the abnormal case would become part of the specification and we would be back in the province of correctness. This definition of “abnormal case” will be useful again when we study exception handling. It implies that the notions of normal and abnormal case are always relative to a certain specification; an abnormal case is simply a case that is not covered by the specification. If you widen the specification, cases that used to be abnormal become normal — even if they correspond to events such as erroneous user input that you would prefer not to happen. “Normal” in this sense does not mean “desirable”, but simply “planned for in the design of the software”. Although it may seem paradoxical at first that erroneous input should be called a normal case, any other approach would have to rely on subjective criteria, and so would be useless. There will always be cases that the specification does not explicitly address. The role of the robustness requirement is to make sure that if such cases do arise, the system does not cause catastrophic events; it should produce appropriate error messages, terminate its execution cleanly, or enter a so-called “graceful degradation” mode. Extendibility Software is supposed to be soft, and indeed is in principle; nothing can be easier than to change a program if you have access to its source code. Just use your favorite text editor. The problem of extendibility is one of scale. For small programs change is usually not a difficult issue; but as software grows bigger, it becomes harder and harder to adapt. A large software system often looks to its maintainers as a giant house of cards in which pulling out any one element might cause the whole edifice to collapse. We need extendibility because at the basis of all software lies some human phenomenon and hence fickleness. The obvious case of business software (“Management Information Systems”), where passage of a law or a company’s acquisition may suddenly invalidate the assumptions on which a system rested, is not special; even in scientific computation, where we may expect the laws of physics to stay in place from one month to the next, our way of understanding and modeling physical systems will change. Traditional approaches to software engineering did not take enough account of change, relying instead on an ideal view of the software lifecycle where an initial analysis stage freezes the requirements, the rest of the process being devoted to designing and building a solution. This is understandable: the first task in the progress of the discipline was to develop sound techniques for stating and solving fixed problems, before we could worry about what to do if the problem changes while someone is busy solving it. But now Definition: extendibility Extendibility is the ease of adapting software products to changes of specification. On exception handling see chapter 12