During elicitation, you learn information that can be stated as both goals or domain properties. Remember that domain properties are statements about the environment itself. They reflect the physical properties that cannot be changed in this world, at least not with our current abilities. So, for example, if train doors are open, then they are not closed. As another example of a domain property, a borrowed book is not available to other patrons because there's only one piece of it. We write these domain statements in the indicative mood of is and are. They are environmental properties that hold true always unless our laws of physics suddenly change. Domain properties are different from goals in that they are indicative. Goals, on the other hand, are prescriptive. For example, if in our meeting scheduler, we said that meetings shall be scheduled so as to maximize the attendance of invited participants, that is a goal. If we instead said, Participants cannot attend multiple meetings at the same time, that is a domain property. In our library example, we might say something like, Borrowed copies of books shall be returned within the deadline. This is a goal that involves borrowers, library software and library staff. A domain property is like the one just mentioned: a borrowed book is not available to other patrons. The difference is that goals can be negotiated. They can be weakened. They can be prioritized. Domain properties, on the other hand, cannot. We need to include both types of properties and statements within our Requirements document. Goals picked can be discussed in different levels of abstraction. Higher-level goals are more strategic and more coarse-grained overall. The lower-level goals are more technical and they help us in determining lower-level requirements. Now, note that that does not mean that we should be getting into the design but they are just lower-level. As an example of this, let's say that in our meeting system, we had a requirement or, sorry, a goal that a meeting should be scheduled so as to maximize the attendance of the invited participants. That is a high-level goal. Attendance up, good. A low-level goal might be something like, when no date can be found outside of all of the excluded dates returned by the participants, then the constraints should be weakened by dropping the constraints of low-priority participants. It's much more defined when we state a low goal fashion. Coarser-grained goals can be refined into finer-grained goals. Our finer-grained goals may be abstracted towards the coarser goals to which they contribute. The finer-grained the goal, the fewer agents that are required toward that goal satisfaction. Goals can also be stated as requirements or expectations. Requirements are usually low-level goals. They are assigned to a single agent in the software to be. Expectations are goals that are assigned to a single agent but within the environment. For example, a requirement in a train system might be that the door is closed whenever the speed of the train is not zero. This is a responsibility of a single agent in the system to be, namely, this would be the train controller in our system. Another requirement may be that an acceleration command is sent every three seconds. That would be the responsibility of the station computer. Do note that requirements can be written at higher levels based on our goals but our main goal is to keep narrowing down those requirements to get to simple statements like these. For example, with the goal that all train doors shall remain closed while the train is moving, the participants there are including the train controller, the speed sensor, the door actuators. I think that's it. And so from this main goal, we can then refine it, as I just mentioned. Expectations are goals that are related to the environment and can also be broken down. For example, we can state that we expect the passengers to get out of the train when the train doors are open and they are at their destination platform. This is a prescriptive assumption about the overall environment. We're assuming that an elemental environment that we have no control over, in this case, our passengers, are going to do what we actually expect. This cannot be enforced by the software to be. Requirements are enforced by the software to be. As another example of this, of expectations versus requirements, let's go back to our meeting scheduler. One requirement there might be that the scheduled meeting date and the location should be sent to the email address of every participant who was on the invite e-list after that participant has been validated by the meeting initiator. That was a mouthful. Basically, everyone gets an email once the meeting is put out. An expectation would be that all invitees will respond within a week to said email. Another would be that invited participants will actually attend the meeting if the notified date and location fits the constraints that he or she has returned.
