Goals can be expressed in a number of ways, the first type is the Achieve goal. The Achieve goal prescribes intended behavior, where the TargetCondition must sooner or later hold, whenever some other condition holds the current system state. The corresponding specification would look like what's shown here. Achieve a TargetCondition, if the CurrentConditon holds, then at some point, you know you will reach the TargetCondition. For example, to achieve the BookRequestSatisfied condition in our library system, the Achieve goal would state, if the book is requested, then sooner or later, a copy of the book is borrowed by the requesting page write. For our train system, in order to achieve the goal of a fast journey, one goal could be stated as, if the train is at some platform, then within five minutes, it's going to be at the next platform. Let's also consider our meeting scheduling system. Let's say we want to achieve the goal of, a meeting request is satisfied. Think about this for a few seconds, the meeting request needs to be satisfied. One way that we could write this is to say achieve meeting request satisfied. If a meeting is requested, then sooner or later the meeting does take place and is attended by all important invited participants. We can also write maintain goals for our system. Maintain goals prescribe intended behaviors where some good condition must always hold. Accuracy goals are usually a type of Maintain statement. Maintain goals follow the temporal pattern of Maintain, Some GoodConditioon. Potentially if CurrentCondition then always Some GoodCondition. These statements can also leave out the if part, if SomeCondition, then GoodCondition. For example, a Maintain goal in our train system may be that the doors are closed while the train is moving. Always, if a train is moving, then its doors are closed. If the goal is to Maintain WorstCaseStoppingDistance then a requirement might be, if the train is following another train then its distance must be sufficient to allow the other to stop suddenly. As another concrete example, let's go back to that library system again. Let's say we want to maintain accurate book classification, again, that's maintain accurate book classification. What might you write there? If a book is registered in the library directory, then always it's key word base classification reflects on its covered topics, makes sense, right? Notice the structure of these statements, and look at these examples, remember, the if then is optional. So ask yourself, always what, or, if this condition, then always what? Another type of goal that we can write are Avoid statements. Avoid goals are related to Maintain goals, very, very similar. Avoid goals are often used in security. Achieve goals refer to some future state given some arbitrary Current one. Maintain and Avoid goals refer to every future possible state. You can possibly rewrite those so that they go up to some particular point rather than anything in the future, but, in general. In an Avoid goal, you write it as Avoid Some BadCondition, and then define it as if Some CurrentCondition then if that happens, then never let that bad condition happen. Or if you just never want something to be able to happen, ignore the if. For example, if you don't want others in the library system to see BorrowerLoans, you could write a statement like this one here, Avoid BorrowerLoansDisclosed. Never let patron loans be disclosed to other patrons. These statements are especially useful in security. Avoid goals are very useful in security, because usually we're saying, don't ever do this, we can never allow this. Try to think of some of the examples that you've seen in your own work, and in systems that you've used of how avoid goals could be useful. One example might be Avoid unauthorized access. We want to avoid unauthorized access if the user has less than top secret security clearance. If they don't have top secret security clearance then never, the user cannot access documents or systems above their security level. Unlike behavioral goals, soft goals prescribe preferences, where these preferences go along alternative system behaviors. In soft goals, the overall goal is to be more fulfilled as along some alternatives than along others. Please see the additional reading for more information on how we define soft goals, and how we evaluate them. Goal satisfaction doesn't make a lot of sense for soft goals, because we can't observe that the a're actually satisfied by some course of behaviors, and not satisfied by others. Soft goals are not the same as goals whose satisfaction is required X percent of cases, those are behavioral goals. Soft goals are more probabilistic goals, with behavioral goals, is it satisfied or is it not? In soft goals, it's only required to be satisfied sometimes. And in your analysis, you're looking at how much has it satisfied along this alternative, versus this other alternative? This concept of partial satisfiability led to the creation of the term satisficing. This defines a partial degree of satisfaction. The state of the art of evaluating, validating and verifying our probabilistic goals, is still really limited right now. So, especially while you're reading the additional reading, think about what kinds of goals the paper's talking about. What are some examples of those goals? In soft goals, you'll often use the words like maximize, minimize, increase, reduce, improve. For example, we might, for our library program, say, the workload of the library staff should be reduced. Also in the library system, the biographical search engine of our library should be usable, usable by non-computer science students. In most cases, soft goals should be clarified much more when you're writing your actual requirements document, so that those requirements can be testable. But for right now, we're using our soft goals to learn more about alternatives and prioritizations.
