Ivan Marsic • Rutgers
University 144
3.4 Specifying Goals
The basic idea of goal-oriented requirements engineering is to start with the aggregate goal of the whole system, and to refine it by successive steps into a goal hierarchy.
AND-OR refinements … Problem frames can be related to goals. Goal-oriented approach distinguishes different kinds of
goal, as problem-frames approach distinguishes different problem classes. Given a problem decomposition into basic frames, we can restate this as an AND-refinement of the goal hierarchy:
to satisfy the system requirement goal, it is necessary to satisfy each individual subgoal of each basic frame.
When programmed, the program “knows” its goals implicitly rather than explicitly, so it cannot tell those to another component. This ability to tell its goals to others is important in autonomic
computing, as will be seen in Section 9.3 below.
State the goal as follows: given the states A=locked, B=lightOff, C=user positively identified, D=daylight
Goal is the equilibrium state to be reached after a perturbation. Initial state: A
∧B, goal state: ¬A∧¬B. Possible actions:
α—setOpen; β—setLit Preconditions for
α: C; for β: D We need to make a plan to achieve
¬A∧¬B by applying the permitted actions.
Program goals, see also “fuzzy” goals for multi-fidelity algorithms, MFAs, [Satyanarayanan Narayanan, 2001]. http:www.cs.yale.eduhomeselkin Michael Elkin
The survey “Distributed approximation,” by Michael Elkin. ACM SIGACT News, vol. 36, no. 1, Whole Number 134, March 2005.
http:theory.lcs.mit.edu~rajsbaumsigactNewsDC.html The purpose of this formal representation is not to automatically build a program; rather, it is to
be able to establish that a program meets its specification.
Chapter 3 • Modeling and System Specification
145
3.5 Summary and Bibliographical Notes
This chapter presents … I have seen many software-development luminaries gripe about software quality see [Jackson,
2001], Ch.12 Microsoft Word example. I feel that the situation is much more complex than ensuring quality. Software appeal depends on what it does functionality, how good it is
quality, and what it costs economy. Different people put different weights on each of these, but in the end all three matter. Microsoft figured that the functionality they deliver is beyond the
reach of smeller software vendors who cannot produce it at a competitive price, so they emphasized functionality. It paid off. It appears that the market has been more interested in low-
cost, feature-laden products than reliability for the mass market kind of products. It worked in the market, thus far, which is the ultimate test. Whether this strategy will continue to work, we do
not know. But the tradeoff between quality functionality economy will always be present.
Also see the virtues if the “good enough” principle extolled here: S. Baker, “Why ‘good enough’ is good enough: Imperfect technology greases innovation—and
the whole marketplace,” Business Week, no. 4048, p. 48, September 3, 2007. Online at:
http:www.businessweek.commagazinecontent07_36b4048048.htm
Comment
Formal specifications have had lack of success, usually blamed on non-specialists finding such specifications difficult to understand, see e.g., [Sommerville, 2004, p. 116; Larman, 2005, p. 65].
The usual rationale given for avoiding rigorous, mathematically driven program development is the time-to-market argument—rigor takes too much time and that cannot be afforded in today’s
world. We are also told that such things make sense for developing safety-critical applications, such as hospital systems, or airplane controls, but not for everyday use. Thanks to this
philosophy, we can all enjoy Internet viruses, worms, spam, spyware, and many other inventions that are thriving on lousy programs.
The problem, software ends up being used for purposes that it was not intended for. Many of-the- shelf software products end up being used in mission-critical operations, regardless of the fact
that they lack robustness necessary to support such operations.
It is worth noticing that often we don’t wear what we think is “cool”—we often wear what the “trend setters” in our social circle, or society in general, wear [Gladwell, 2000]. But, as Petroski
[1992], echoing Raymond Loewy, observes, it has to be MAYA—most advanced, yet acceptable. So, if hackers let the word out that some technique is cool, it shall become cool for the masses of
programmers.
Bibliographical Notes
Much of this chapter is directly inspired by the work of Michael Jackson [1995; 2001]. I have tried to retell it in a different way and relate it to other developments in software engineering. I