(Last modified Fri Apr 11 16:18 2008)

This glossary is an ongoing project, a work-in-progress, that lists definitions drawn from the requirements engineering literature (and related literatures) along with my own summaries and comments.  The definitions are presented in chronological order of publication, except that where I present a dictionary definition that is first.  Full citations for the references are given here. 

Table of Contents
abstract actor   abstraction   abstract use case   action   actor   agent   business rule	concrete use case   constraint   episode   event   forward  (activities)   goal   implied scenario	information hiding   logic   misuse case   nonfunctional requirement   obstacle   operational   problem frame	refactoring   requirement   restructuring   scenario   separation of concerns   software maintenance   task model	truth   use case   use case map (UCM)   uses  (relationship)

abstract actor

1. "An abstract actor typically describes a role that should be played against the system.  When different actors play similar roles they may inherit a common abstract actor."  [Jacobson+Christerson+1992-oose:171-172]

abstraction

1. "The transition of increasing detail through the forward progress of the life cycle maps well to the concept of abstraction levels.  Earlier stages of systems planning and requirements definition involve expressing higher level abstractions of the system being designed when compared to the implementation itself.  ... It is important to distinguish between levels of abstraction, a concept that crosses conceptual stages of design, and degrees of abstraction within a single stage."  [Chikofsky+Cross1990-redr:2]

abstract use case

1. "This refinement is mainly done by identifying similar parts of the use cases and extracting these similar parts.  In this way we only have to describe the similar part once instead of in all use cases showing this behavior.  Any changes to this part will thus automatically affect all use cases that share this part.  We call the use cases that we extract abstract use cases since they will not be instantiated on their own, but are only meaningful to describe parts which are common to other use cases  We call the use cases that really will be instantiated concrete use cases."  [Jacobson+Christerson+1992-oose:170]

action

1. "Work in problem solving has used more sophisticated models of action and time.  The most influential theory in this work has been the situation calculus [4].  The world is represented as a set of situations, each describing the world at a single instant in time.  An action is a function from one situation to another, and can be described by a set of prerequisites on the initial situation and a set of effects that will hold in the final situation.  While this model has been extremely useful in modeling physical actions by a single agent in an otherwise static world, it cannot easily be extended to account for simultaneous actions and events.  For example, the action described by the sentence, "I walked to the store while juggling three balls," seems to be composed of the action of walking to the store and the action of juggling three balls.  It is not clear how such a composite action would be defined if we view an action as a function from one instantaneous world description to another.  Furthermore, since an action in the situation calculus is equated with change, actions that involve no activity, or restore the world to its original state (e.g., running around a track), cannot be modeled."  [Allen1984-tgta:124]
2. "Given a temporal logic, we address how occurrences can be defined.  In particular, what do we know when we know an occurrence has occurred?  In problem-solving systems, actions are described by prerequisites (i.e., what must be true to enable the action), effects (what must be true after the action has occurred), and decomposition (how the action is performed, which is typically a sequence of subactions).  While such knowledge is crucial for reasoning about what actions to perform in a given situation, it does not define what we know when we know an action has occurred.  To clarify this, consider the simple action of turning on a light.

   There are few physical activities that are a necessary part of performing the action of turning on a light.  Depending on the context, vastly different patterns of behavior can be classified as the same action.  For example, turning on a light usually involves flipping a light switch, but in some circumstances it may involve tightening the light bulb (in the basement) or hitting the wall (in an old house).  Although we have knowledge about how the action can be performed, this does not define what the action is.  The key defining characteristic of turning on the light seems to be that the agent is performing some activity which will cause the light, which was off when the action started, to become on when the action ends.  An important side effect of this definition is that we could recognize an observed pattern of activity as "turning on the light" even if we had never seen or thought about that pattern previously."  [Allen1984-tgta:126]

actor

1. "The actors represent what interacts with the system.  ...  Actors are not like other objects in the respect that their actions are non-deterministic.  We differentiate between actors and users.  The user is the actual person who uses the system, whereas an actor represents a certain role that a user can play.  ...  The same person can thus appear as instances of several different actors."  [Jacobson+Christerson+1992-oose:127]

agent

1. "Agents are the entities or processes that seek to achieve goals within an organization or system based on the implicit responsibility that they must assume for the achievement of certain goals.  For example, given an Electronic Meeting System (EMS), a meeting initiator is the agent responsible for calling, or initiating, a meeting."  [Anton1996-gbra:138L¶1]
2. "a ... kind of object which acts as a processor for some actions."  [Lamsweerde+Letier1998-iogd:55]

business rule

1. "Business rules represent policies, procedures and constraints regarding how an enterprise conducts its business."  [Rosca+Greenspan+Wild2002-emds:361 abstract]. 
2. "Business rules are statements about the enterprise's way of doing business.  They reflect business policies.  Organizations have policies in order to:  satisfy the business objectsives, satisfy customers, make good use of resources, and conform to laws or general business conventions. 

   "Business rules become requirements, that is, they may be implemented in a software system as a means of a requirement of this software system."  [Leite+Leonardi1998-brop:69L¶2]. 

3. "... those aspects of the business environment which explicitly refer to policy statements about the operations of the business namely the business rules."  [Wan-Kadir+Loucopoulos2004-rebr:368L¶2]. 

concrete use case

1. See abstract use case [Jacobson+Christerson+1992-oose:170]. 

constraint

1. "Constraints are requirements that must be met for goal completion.  A constraint places a condition on the achievement of a goal."  [Anton1996-gbra:137L¶2]
2. "an implementable goal, that is, a goal that can be formulated in terms of states controllable by an agent."  [Lamsweerde+Letier1998-iogd:55]

episode

1. "Each episode, or major stage of activity in the schema, corresponds directly to a domain goal."  [Potts1995-ussu:248]
2. "It is possible to construct an unbounded number of scenarios from a model or system and user goals.  To constrain this set to salient scenarios, three heuristics are followed:  Each goal and obstacle is represented by one episode.  An episode is a sequence of actions allocated to actors.  An episode therefore represents a commitment to a single design proposal."  [Potts1995-ussu:249]
3. "An episode is a named subsequence [of events] that is usually shared among several scenarios.  It may have other attributes, like a scenario, and in fact, it may be a scenario;  but in its role as an episode everything other than its sequence of events is ignored."  [Alspaugh+Anton+1999-isms:143]

event

1. 'Mourelatos presents a detailed analysis of the different classes of occurrences describable in English, and his terminology will be adopted here.  The term occurrence is used to describe the class of all events, processes, actions, activities, and accomplishments.  This effectively includes all forms of sentence meanings except for assertions of states such as "The building is red" or "I am ten years old".  The class of occurrences is further subdivided by Mourelatos, and we will consider this subcategorization later as it becomes relevant.'  [Allen1984-tgta:125], referring to [Mourelatos1978-eps]
2. "Events are more difficult to handle than facts.  An event is something happening.  In the past, the only kind of events handled by AI researchers and most philosophers is what might be called a fact change, such as a block being moved from one place to another (McCarthy, 1968; Rescher, 1971).  The defining feature of an event on this theory are the changes in facts that the event brings about.  This approach suppresses some important features of events.  For instance, they take time.  A fact change is just a list of two facts;  how long it took is not describable.  Further, it is meaningless in fact-change formalisms to ask what happens in the middle of a fact change."  [McDermott1982-tlrp:109]
3. "The logic described here is based on temporal intervals rather than time points.  This approach arises from the observation that the only times we can identify are times of occurrences and properties.  For any such time, say the time I was opening the door, it appears to be possible to look more closely at the occurrence and decompose it;  hence, times can be decomposed into subtimes.  In other words, it seems that there is always a more detailed causal explanation if one cares, and is able, to look for it.  A good analogy, then, is that times correspond to intervals on the real line.  If we accept this, why not allow instantaneous time points as well?  First, they do not appear to be necessary.  Second, instantaneous time points will present difficulties with the semantics of our logic.  If one allows time points, one must consider whether intervals are open or closed.  For example, consider the time of running a race, R, and the time following after the race, AR.  Let P be the proposition representing the fact that the race is on; P is true over R, and ~P is true over AR.  We want AR and R to meet in some sense.  Whether both ends of the intervals are open or closed, AR and R must either share a time point or allow time between them.  Thus we have a choice between inconsistency or truth gaps, i.e., either there is a time when both P and ~P are true, or there is a time when neither P nor ~P is true.  One solution to this problem is to stipulate by convention that intervals are open at the lower end and closed at the upper end, but then every interval has only a single endpoint.  The artificiality of this solution reinforces the argument against allowing points.  Events that appear to refer to a point in time (e.g., finishing a race) are considered to be implicitly referring to another event's beginning or ending.  Thus time `points' will be considered to be very small intervals."  [Allen1984-tgta:127]
4. "An event is a single point in time when something happens, following Allen's [19] conception of temporal semantics.  Events are treated as semaphores which initiate a state transition.  For instance, the dispatch of goods from the warehouse to customer is triggered by a customer order (a request event)."  [Sutcliffe1998-sbra:8]
5. "Each action has one start event and one end event."  [Sutcliffe+Maiden+1998-ssbr:1074]
6. "An MSC describes the communication between a number of system components, and between these components and the rest of the world, called environment.  For each system component covered by an MSC there is an instance axis.  The communication between system components is performed by means of messages.  The sending and consumption of messages are two asynchronous events.  It is assumed that the environment of an MSC is capable of receiving and sending messages from and to the Message Sequence Chart;  no ordering of message events within the environment is assumed. 

   A global clock is assumed for one Message Sequence Chart.  Along each instance axis the time is running from top to bottom, however, a proper time scale is not assumed.  If no coregion or inline expression is introduced (see 7.1, 7.2) a total time ordering of events is assumed along each instance axis.  Events of different instances are ordered via messages — a message must first be sent before it is consumed — or via the generalized ordering mechanism.  With this generalized ordering mechanism "orderable events" on different instances (even in different MSCs) can be ordered explicitly.  No other ordering is prescribed.  A Message Sequence Chart therefore imposes a partial ordering on the set of events being contained."  [ITU1999-msc:21]

forward (activities)

1. "We assume that an orderly life-cycle model exists for the software development process.  The model may be represented as the traditional waterfall, as a spiral, or in some other form that generally can be represented as a directed graph.  While we expect there to be iteration within stages of the life cycle, and perhaps even recursion, its general directed-graph nature lets us sensibly define forward (downward) and backward (upward) activities."  [Chikofsky+Cross1990-redr:14]

goal

1. "1 a : the terminal point of a race b : an area to be reached safely in children's games
   2 : the end toward which effort is directed : AIM 3 a : an area or object toward which players in various games attempt to advance a ball or puck and usually through or into which it must go to score points b : the act or action of causing a ball or puck to go through or into such a goal c : the score resulting from such an act
   synonym see INTENTION"
   [Merriam-Webster]
2. "Goals are important in several respects.  They lead to the incorporation of requirements components which should support them.  They justify and explain the presence of requirements components which are not necessarily comprehensible to clients.  They may be used to assign the respective responsibilities of agents in the system;  more precisely, they may provide the basis for defining which agents should best perform which actions to fit prescribed constraints (according to their capabilities, reliability, cost, load, motivation, and so forth).  Finally, they provide basic information for detecting and resolving conflicts that arise from multiple viewpoints among human agents."  [Dardenne+Lamsweerde+Fickas1993-gdra:8]
3. "A goal is a nonoperational objective to be achieved by the composite system. Nonoperational means that the objective is not formulated in terms of objects and actions available to some agent in the system;  in other words, a goal as it is formulated cannot be established through appropriate state transitions under control of one of the agents."  [Dardenne+Lamsweerde+Fickas1993-gdra:20]
4. "Goal-based approaches focus on why systems are constructed providing the motivation and rationale to justify software requirements."  [Anton1996-gbra:137L¶1]
5. "In our experience, goals are characteristically more stable than the processes, organizational structures and operationis of a system which continuously evolve [1]; this is why we emphasize them."  [Anton1996-gbra:137R¶3]
6. "Goals are high level objectives of thes business, organization, or system.  They capture the reasons why a system is needed and guide decisions at various levels within the enterprise. ...

   "Achievement goals are objectives of some enterprise or system. ...

   "Maintenance goals are those goals that are satisfied while their target condition remains true."  [Anton1996-gbra:137R§2.1¶2,5,6]

7. "... a goal is an objective the composite system should meet."  [Lamsweerde+Letier1998-iogd:55]
8. "A goal is an objective the system under consideration should meet."  [Lamsweerde2001-gore:251L¶1]
9. "Goals are objectives the system under consideration must achieve."  [Letier+Lamsweerde2002-doss:119c2¶2]
10. "A goal can be achieved by the performance of a process."  [Salinesi+Rolland2003-fbms:650L¶4]

implied scenario

1. "Scenarios can combine in unexpected ways and certain system behaviours, not present in the scenario specification, may appear in all possible implementations of the system. These behaviours are called implied scenarios, and they arise because components have a local view of what is happening in the system."  [Uchitel+Kramer+Magee2001-dism:74]
2. "Definition 13.  (Implied Scenario)  Let Spec be a MSC specification with an alphabet L.  An implied behaviour is a word w ∉ L(Spec) over the alphabet L such that w ∈ L(P) for all implementations of Spec."  [Uchitel+Kramer+Magee2001-dism:79]
3. "An important observation on implied scenarios is that they are the result of an inconsistency between system decomposition and system behaviour.  Implied scenarios are not an artefact of a particular MSC language, they are the result of specifying the global behaviours of a system that will be implemented component-wise."  [Uchitel+Kramer+Magee2001-dism:79]

information hiding

1. 'Every module ... is characterized by its knowledge of a design decision which it hides from all others.  Its interface or definition was chosen to reveal as little as possible about its inner workings."  [Parnas1972-cbud]

logic

1. "Logic is the study of how to reason, how to deduce from hypotheses, how to demonstrate.  As presented here, logic is concerned with providing symbolic models of acceptable reasoning."  [Epstein2001-pl:1]

misuse case

1. A Misuse Case is a Use Case [1] from the point of view of an actor hostile to the System under Design. Its goal is not a system function but a threat posed by that hostile actor.  [Alexander2002-iiem:61]
2. Misuse case  A sequence of actions, including variants, that a system or other entity can perform, interacting with misusers of the entity and causing harm to some stakeholder if the sequence is allowed to complete.

   Misuser  An actor that initiates misuse cases, either intentionally or inadvertently.
   [Sindre+Opdahl2005-esrm:35]

nonfunctional requirement

1. "... global requirements on its development or operational cost, performance, reliability, maintainability, portability, robustness, and the like.  These nonfunctional requirements ..."  [Mylopoulos+Chung+Nixon1992-runr:483]

obstacle

1. "Goal obstacles are behaviors or other goals that prevent or block the achievement of a given goal.  Abstracting and identifying goal obstacles allows one to consider the possible ways for goals to fail and anticipate exception cases."  [Anton1996-gbra:137L¶5]
2. "Obstacles denote the reason why a goal failed.  Scenarios denote concrete circumstances under which a goal may fail.  Scenarios can, thus, be considered instantiations of goal obstacles."  [Anton1996-gbra:137L¶5]
3. "obstacles capture undesired [properties]."  [Lamsweerde+Letier1998-iogd:54]

operational

1. "1. Math., Logic, and Computing. Of, involving, or employing mathematical operators or logical operations. 
   2001 Bull. Symbolic Logic 7 223 It is useful to define the operational semantics of a language as a transition relation between states of an abstract machine.

   2. Philos. Of, relating to, or in accordance with operationalism [a form of positivism which defines scientific concepts in terms of the operations used to determine or prove them.]
   1990 E. HARTH Dawn of Millennium (1991) viii. 126 Operational approach: a quantity or object is defined by the operations we have to perform to ascertain it."  [OED]

2. "Operationalization is the process of defining a goal with enough detail so that its subgoals have an operational definition."  [Anton1996-gbra:137R§2.1¶3]

problem frame

1. "... problem frame, a structure consisting of principal parts and a solution task.  ... A problem frame is a generalization of a class of problems.  If there are many other problems that fit the same frame as the problem you're dealing with, then you can hope to apply the method and techniques that worked for those other problems to the problem you're trying to solve right now."  [Jackson1995-srsl:159]
2. "A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise."  [Jackson2001-pfas:xii]
3. "A problem frame is a kind of pattern.  It defines an intuitively identifiable problem class in terms of its context and the characteristics of its domains, interfaces, and requirement.  ... A problem frame is a kind of pattern that captures and defines a commonly found class of simple subproblem[s]."  [Jackson2001-pfas:76]

refactoring

1. "Refactoring is basically the object-oriented variant of restructuring."  [Mens+Tourwe2004-ssr,p126]
2. "The process of changing a system in such a way that it does not alter the external behavior of the code, yet improves its internal structure." [Fowler+Beck+1999-ride]

requirement

1. "A requirement specifies how a goal should be accomplished by a proposed system."  [Anton1996-gbra:137R§2.1¶3]

restructuring

1. "Restructuring is the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behavior (functionality and semantics)."  [Chikofsky+Cross1990-redr:2]

scenario

1. "1 a : an outline or synopsis of a play;  especially : a plot outline used by actors of the commedia dell'arte
   b : the libretto of an opera
   2 a : SCREENPLAY b : SHOOTING SCRIPT
   3 : a sequence of events especially when imagined;  especially : an account or synopsis of a possible course of action or events <his scenario for a settlement envisages... reunification -- Selig Harrison>"
   [Merriam-Webster]
2. "For example, consider the scenario of elevators serving passengers in a multistory building.  The components are the individual passengers, the elevator controller, and the elevator mechanism.  The behavior required of this composite system is the rapid transportation of passengers to their destination floors.  Decomposition defines what interaction is allowed between these components, for example, the controller may be allowed to issue start/stop commands to the elevator motors, thus causing movement of elevators;  passengers may be allowed to signal to the controller their presence at a floor and their desire to be transported in some direction.".  [Feather1987-lssd:199]
3. "Consider a scenario of a business lunch with two participants, the host and the visitor.  They eat at a restaurant with a very limited menu, offering only two choices:  an expensive steak special, or a more moderate chef's salad.  The host's company has an austerity measure to discourage overly large expense claims, and will only recompense the expense of a lunch if the total cost does not exceed some preset limit (otherwise no compensation whatsoever is given).  As it happens, the cost of two steak specials exceeds this limit, whereas the cost of two chef's salads, or one chef's salad and one steak special, falls below this limit.  Hence the two diners, if they wish to be compensated for their meal, must not both order steak.  Suppose that the host orders first.  This scenario is expressed in terms of behavior, histories, transitions, and so on, as follows."  [Feather1987-lssd:207]
4. "Scenarios are partial descriptions of system and environment behavior arising in restricted situations."  [Benner+Feather+1992-ussd:1]
5. "In the broad sense, a scenario is simply a proposed specific use of the system.  More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment.  Scenarios can be documented in different ways, depending on the level of detail needed.  The simplest form is a use case, which consists merely of a short description with a number attached.  More detailed forms are called scripts.  These are usually represented as tables or diagrams and involve identifying an action and the agent (doer) or the action.  For this reason, a script can also be called an action table."  [Potts+Takahashi+Anton1994-ibra:23]
6. "Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because they describe the system's behavior only in specific situations;  a specification, on the other hand, describes what the system should do in general."  [Potts+Takahashi+Anton1994-ibra:23]
7. "... we represented scenarios as sequences of actions at two levels of complexity:
   • Complete scenarios or families of scenarios. A scenario can have subcases, which make it then a family.  ... 
   • Episodes or phases.  The shared actions in different cases are called episodes or phases.  ..." 
   [Potts+Takahashi+Anton1994-ibra:25]
8. "Scenarios are behavioral descriptions of a system and its environment arising from restricted situations.  They exemplify behaviors enabling hidden needs to be uncovered and are useful for evaluating design alternatives and validating designs."  [Anton1996-gbra:138L¶4]
9. "Obstacles denote the reason why a goal failed.  Scenarios denote concrete circumstances under which a goal may fail.  Scenarios can, thus, be considered instantiations of goal obstacles."  [Anton1996-gbra:137L¶5]
10. "... scenarios are an expressive representation scheme which allow stakeholders to clearly relate to their experiences, ultimately faciliating the validation of requirements."  [Anton1997-girs:24¶0]
11. "Use of examples, scenes, narrative descriptions of contexts, mock-ups and prototypes have attracted considerable attention in Requirements Engineering, Human Computer Interaction and Information Systems communities.  Loosely all these ideas can be called scenario based approaches, although exact definitions are not easy beyond saying these approaches emphasise some description of the real world.  Experience seems to tell us that people react to 'real things' and that this helps clarifying requirements.  Indeed the widespread acceptance of prototyping in system development points to the effectiveness of scenario based approaches.  However, we have little understanding about how scenarios should be constructed, little hard evidence about their effectiveness and even less idea about why they work."  [Rolland+BenAchour+1998-pscf]
12. "Scenarios are descriptions of concrete system behaviors."  [Anton+Potts1998-rfss:219]
13. "All these scenarios have in common that they represent the operation of some proposed system."  [Anton+Potts1998-rfss:220]
14. "Each scenario in an object-oriented analysis illustrates a concrete instance of a use case."  [Anton+Potts1998-rfss:227]
15. "A scenario can be defined as a description of a possible set of events that might reasonably take place.  The main purpose of developing scenarios is to stimulate thinking about possible occurrences, assumptions relating these occurrences, possible opportunities and risks, and courses of action."  [Jarke+Bui+Carroll1998-smia]
16. "a domain-consistent composition of applications of actions by corresponding agent instances;  domain consistency means that the actions are applied in states satisfying their domain precondition together with the various domain invariants attached to the corresponding objects, with resulting states satisfying their domain postcondition."  [Lamsweerde+Letier1998-iogd:55]
17. "Most authors agree that, in broad terms, use cases and scenarios are descriptions of a sequence of actions or events for a specific case of some generic task which the system is meant to accomplish."  [Maiden1998-cssa:423]
18. "... one specific ordering of events, the ordering of which is dependent on the start and end events for each action specified in the originating use case ..."  [Maiden1998-cssa:423]
19. "Scenarios have been used with many different connotations.  One important distinction is between scenarios that form part of the specification of the required system, or are derived from it, versus scenarios that are captured from actual experience and do not originate from a system design.  The former view has been adopted in user cases in the object oriented literature [2, 8, 9], in which a use case embodies a projected vision of user interaction with the designed system.  Scenarios are threads of interaction which may occur through the network of a user case that describes several pathways in user-system interaction.  Scenarios of this type have several precedents, for instance, viewpoints in CORE [10] described interaction between an intended system and external agents, as did context diagrams in structured systems analysis [11].  We use scenarios in the second sense, as descriptions taken from reality before a system is implemented, and used to validate the required system." [Sutcliffe1998-sbra]
20. 'For our purposes scenarios are defined as "facts describing an existing system and its environment including the behaviour of agents and sufficient context information to allow discovery and validation of system requirements".'  [Sutcliffe1998-sbra]
21. "A scenario is a linear sequence of events, with associated attributes. ... The attributes of a scenario may include:  goals, viewpoints, pre- and post-conditions, purpose, concreteness level, author, requirements, events, actors and actions, as well as episodes."  [Alspaugh+Anton+1999-isms:143]
22. "There are clear advantages of narrative text for expressing UCs.  Stakeholders are familiar with the notation, and do not need formal training or expensive software tools.  However, narrative UCs are often ambiguous and lack structure."  [BenAchour+Rolland+1999-guca:36]
23. "However, the term scenario is intended to mean something more abstract here than UML's sequence of interactions, which express sequences in terms of wiring-level details.  With UCMs, scenarios are seen in terms of continuous paths directly superimposed on organizational structures and their sequences are of responsibilities performed by components of the system, not of interactions between components.  The paths are signatures of scenarios that may be used by a human observer to visualize scenarios progressing along them.  Compositions of paths (sets of wiggly lines) are macroscopic behaviour structures that are useful for architectural purposes." 
    [Buhr1999-mbca:1-2]
24. "A scenario describes a possible set of events that might reasonably take place.  Its purpose is to stimulate and document thinking about current problems, possible occurrences, assumptions relating to these occurrences, action opportunities, and risks.  Thus, scenarios must be linked to change goals.  Results from cognitive psychology ... indicate that scenarios offer a middle-ground abstraction between models and reality, providing a universally understood medium for participatory design, and facilitating reuse of design knowledge ...."  [Jarke1999-sm]
25. "In UCMs, a scenario is a partial description of system usage defined as a set of partially-ordered responsibilities a system performs to transform inputs to outputs while satisfying preconditions and postconditions."  [Amyot2003-iurn]
26. "Scenarios are for people:  a way to explain what they want, and to check that what is being asked for is correct."  [Alexander2004-issd:6]
27. '"A straight-line sequence of (possibly numbered, typically interactive) steps taken by independently-acting (presumably intelligent) agents playing (system) roles" is roughly what most people mean by Scenario in engineering today."  [Alexander2004-issd:12]
28. "In a nutshell, a scenario is an informal description of a situation ... in a CBS [computer-based system] environment and of a way that the CBS can be used."  [Breitman+Leite+Berry2005-sse]
29. "A scenario is a description that contains (1) actors, (2) background information on the actors and assumptions about their environment, (3) actors' goals or objectives, and (4) sequences of actions and events.  Some applications may omit one of the elements or they may simply or implicitly express it.  Although, in general, the elements of scenarios are the same in any field, the use of scenarios is quite different."  [Go+Carroll2004-bmev]
30. "A scenario (or course of events) describes the system's behavior as a unique flow of interactions taking place under given conditions with its users who try to achieve their goal."  [Salinesi2004-auc:146]
31. "Scenario-based specifications, such as message sequence charts (MSCs) [ITU 1996] and UML sequence diagrams [OMG 2002], are popular as part of requirements specifications.  Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system level functionality.  Their simplicity and intuitive graphical representation facilitates stakeholder involvement and makes them popular for conveying and documenting requirements.  Each scenario is a partial description that, when combined with all other scenarios contributes to the overall system description."  [Uchitel+Kramer+Magee2004-iesb:146]
32. "At the requirements level, scenarios describe sequences of interactions between agents of a system composed of software agents, human agents, and hardware devices such as sensors and actuators [7, 13].  Each interaction in such scenario corresponds to the occurrence of an event that is synchronously controlled by an agent and monitored by another agent [18, 11, 14]."  [Letier+Kramer+2005-mcsb:382]
33. A sequence of events.  The sequence is commonly abstracted from a particular time, and parameterized (possibly implicitly) by the use of generic terms (such as 'User') that may be replaced by specific instances to produce a more-concrete scenario.  The sequence may be accompanied by other information (such as pre- and postconditions, goals, requirements, ...).  The event sequence may be either a total or a partial order.  In its simplest form, a scenario is a linear sequence of events.  It may describe actual events or desired events.  [ Alspaugh ]

separation of concerns

1. "Let me try to explain to you, what to my taste is characteristic for all intelligent thinking.  It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects.  We know that a program must be correct and we can study it from that viewpoint only;  we also know that it should be efficient and we can study its efficiency on another day, so to speak.  In another mood we may ask ourselves whether, and if so:  why, the program is desirable.  But nothing is gained --on the contrary!  -- by tackling these various aspects simultaneously.  It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of.  This is what I mean by "focusing one's attention upon some aspect":  it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant.  It is being one- and multiple-track minded simultaneously."  [Dijkstra1974-rst:p0];  reprinted in [Dijkstra1982-swcp:p60-66].
2. "To my taste the main characteristic of intelligent thinking is that one is willing and able to study in depth an aspect of one's subject matter in isolation, for the sake of its own consistency, all the time knowing that one is occupying oneself with only one of the aspects.  The other aspects have to wait their turn, because our heads are so small that we cannot deal with then simultaneously without getting confused.  This is what I mean by focusing one's attention upon a certain aspect;  it does not mean completely ignoring the other ones, but temporarily forgetting them to the extend that they are irrelevant for the current topic.  Such a separation, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts that I know of.  I usually refer to it as 'a separation of concerns' ..."  [Dijkstra1976-dp:p210]

software maintenance

1. "Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment."  [ ANSI IEEE Std 729-1983 ]

task model

1. (under construction)

truth

1. "I will not try to explain truth and falsity here.  In general we understand well enough what it means for a simple sentence such as 'Ralph is a dog' to be taken as true or taken as false.  For such sentences we can regards truth as a primitive notion, one we understand how to use in most applications, while falsity we can understand as the opposite of truth, the not-true."  [Epstein2001-pl:2]

use case

1. "A use case is a specific way of using the system by performing some part of the functionality.  Each use case constitutes a complete course of events initiated by an actor and it specifies the interaction that takes place between an actor and the system.  A use case is thus a special sequence of related transactions performed by an actor and the system in a dialogue.  The collected use cases specify all the existing ways of using the system. 

   "To understand use cases we can view their descriptions as state transition graphs.  Each stimulus sent between an actor and the system performs a state change in this graph.  We can thus view a use case as existing in different states.  ... 

   "Like actors, use cases can be instantiated and this is done every time a user performs a use case in the system.  ... 

   "As several use cases can begin in a similar way, it is not always possible to decide what use case has been instantiated until it is completed." 

   [Jacobson+Christerson+1992-oose:159-160]

2. "The simplest form [of a scenario] is a use case, which consists merely of a short description with a number attached."  [Potts+Takahashi+Anton1994-ibra:23]
3. "... we may now define a use case as an equivalence class of scenarios ....  For example, the relation could equate all scenarios where some individual enters the phone number of some other individual ..."  [Graham1996-tsuc:131]
4. "The starting point for a successful object-oriented scenario construction effort must be an informal description of a scenario expressed in user-oriented terms.  Object-oriented methods therefore tend to adopt scenario descriptions at two separate levels.  The detailed level is the object-interaction level, in which the interacting actors are software objects.  Above this is the use case or user-oriented level, in which the system is a black box."  [Anton+Potts1998-rfss:227]
5. "Most authors agree that, in broad terms, use cases and scenarios are descriptions of a sequence of actions or events for a specific case of some generic task which the system is meant to accomplish."  [Maiden1998-cssa:423]
6. "The former view [scenarios as part of a specification] has been adopted in user cases in the object oriented literature ..., in which a use case embodies a projected vision of user interaction with the designed system.  Scenarios are threads of interaction which may occur through the network of a user case that describes several pathways in user-system interaction."  [Sutcliffe1998-sbra]
7. "Use cases are a unit of work that the user finds useful."  [Robertson+Robertson1999-mrp:51]
8. "There are clear advantages of narrative text for expressing UCs.  Stakeholders are familiar with the notation, and do not need formal training or expensive software tools.  However, narrative UCs are often ambiguous and lack structure."  [BenAchour+Rolland+1999-guca:36]
9. "The term 'use case' was first used by Ivar Jacobson to describe an amount of work to be done.  He chose to break the system into smaller units, as he felt that object models were not scalable.  So to conquer the complexity and largeness of modern systems, Jacobson said it was firstly necessary to partition them into convenient chunks, and that these chunks should be based on the users's view of the system." [Robertson+Robertson1999-mrp:53]
10. "A use case defines a sequence of actions a system performs that yields an observable result of value to a particular user."  [Haumer2004-ucbs:241, but also found elsewhere]
11. "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system."  [OMG2003-umls:Glossary-16]
12. "... all the if..then..else.. branches -- all the exceptional business events that have to handled.  There are usually far more of these than anyone thinks of initially ...  UML's answer to this problem is the Use Case, which has evolved far beyond what Jacobson originally proposed."  [Alexander2004-issd:15]
13. "A Use Case is composed of a collection of scenarios describing:  (i) alternative ways of achieving a goal, (ii) unwanted endings, and (iii) the reaction to potential exceptions that could arise at different times during otherwise normal scenarios."  [Salinesi2004-auc:146]
14. A use case is a collection of scenarios that achieve a common goal.  [ Alspaugh ]

use case map (UCM)

1. "UCMs use behaviour as a concrete, first-class architectural concept.  They describe scenarios in terms of causal relationships between responsibilities.  UCMs usually emphasize the most relevant, interesting, and critical functionalities of the system.  They can have internal activities as well as external ones.  UCMs are abstract (generic), and could include multiple traces.  With UCM, scenarios are expressed above the level of messages exchanged between components, hence they are not necessarily bound to a specific underlying structure.  UCMs provide a pathcentric view of system functionalities and improve the level of reusability of scenarios.  Finally, UCMs can handle both acceptance and rejection scenarios, a useful property for the definition of test cases."  [Amyot+Logrippo+1999-ucmc:46],
2. "The visual notation about to be introduced gives concrete form to this kind of mental picture by imposing sets of wiggly lines representing causal paths onto diagrams of organizational structure (Figure1).  The notation is called "Use Case Maps" (UCMs) because its wiggly lines may be viewed as mapping scenarios of use cases onto system organizations to show how the use cases are realized.  However, the term scenario is intended to mean something more abstract here than UML's sequence of interactions, which express sequences in terms of wiring-level details.  With UCMs, scenarios are seen in terms of continuous paths directly superimposed on organizational structures and their sequences are of responsibilities performed by components of the system, not of interactions between components.  The paths are signatures of scenarios that may be used by a human observer to visualize scenarios progressing along them.  Compositions of paths (sets of wiggly lines) are macroscopic behaviour structures that are useful for architectural purposes."  [Buhr1999-mbca:1-2]

uses (relationship)

1. "The descriptions of the abstract use cases are thus used in the descriptions of the concrete use cases.  This means that, when an instance of a use case follows the description of a concrete use case, at a certain point it continues by following the description of the abstract use case instead.  This relationship is thus some kind of inheritance.  However, it does not have exactly the same semantics as inheritance in an object-oriented programming language.  Therefore we give it a different name.  We call this relationship a uses relationship.  Intuitively, this is also easier to understand than inheritance as used in an OO language, since it is not discrete operations that are used, but rather sequences.  Therefore these sequences may have to be explicitly interleaved in the concrete use cases."  [Jacobson+Christerson+1992-oose:170-171]

Thomas A. Alspaugh
Assistant Professor, Informatics Dept.
School of Information and Computer Sciences