Figure 1 (a) Means-Ends; (b)Decomposition;
(c) Contribution; (d) Correlation
From Requirements to Architectural Design –Using Goals and Scenarios Lin Liu Eric Yu
Faculty of Information Studies University of Toronto
140 St. George St., Toronto, ON M5S 3G6 Canada
{liu, yu}@fis.utoronto.ca
Abstract
To strengthen the connection between requirements and
design during the early stages of architectural design, a designer would
like to have notations to help visualize the incremental refinement of
an architecture from initially abstract descriptions to increasingly concrete
components and interactions, all the while maintaining a clear focus on
the relevant requirements at each step. We propose the combined use of
a goal-oriented language GRL and a scenarios-oriented architectural notation
UCM. Goals are used in the refinement of functional and non-functional
requirements, the exploration of alternatives, and their operationalization
into architectural constructs. The scenario notation is used to depict
the incremental elaboration and realization of requirements into architectural
design. The approach is illustrated with an example from the telecom domain.
In the context of Requirement Engineering and system architectural design, goal-driven and scenario-based approaches have proven useful. In order to overcome some of the deficiencies and limitations of these approaches when used in isolation, proposals have been made to couple goals, scenarios and agents together to guide the RE to architectural design process. As there are both overlap and gaps between these approaches, their interactions are complicate and highly dynamic.
In General, goals describe the objectives that the system should achieve through the cooperation of agents in the software-to-be and in the environment. It captures "why" the data and functions were there, and whether they are sufficient or not for achieving the high-level objectives that arise naturally in the requirement engineering process. The integration of explicit goal representations in requirement models provides a criterion for requirement completeness, i.e. the requirements can be judged as complete if they are sufficient to establish the goal they are refining.
Scenarios present possible ways to use a system to accomplish some desired functions or implicit purpose(s). Typically, it is a temporal sequence of interaction events between the intended software and its environment (composed of other systems or humans). A scenario could be expressed in forms such as narrative text, structured text, images, animation or simulations, charts, maps, etc. The content of a scenario could describe either system-environment interactions or events inside a system. Purpose and usage of scenarios also varies greatly. It could be used as means to elicit or validate system requirements, as concretization of use-oriented system descriptions, or as basis for test cases. Scenarios have also become popular in other fields, notably human-computer interaction and strategic planning.
In this paper, we explore the combined use of goal-oriented and scenario-based models during architectural design. The GRL language is used to support goal and agent oriented modelling and reasoning, and to guide the architectural design process. The UCM notation is used to express the architectural design at each stage of development. The scenario orientation of UCM allows the behavioral aspects of the architecture to be visualized at varying degrees of abstraction and levels of detail.
In next section, basic concepts of GRL and UCM are introduced. In Section 3, we summarized our approach of using GRL and UCM together to incrementally modelling requirements and architectural design. In section 4, a case study in wireless telecommunication domain is used to illustrate the proposed approach. In section 5, related works are discussed. Conclusions and future works are in section 6.
Goal-oriented Requirement Language (GRL) is a language for supporting goal and agent oriented modeling and reasoning of requirements, especially for dealing with Non-Functional Requirements (NFRs)[4][11]. It provides constructs for expressing various types of concepts that appear during the requirement and high-level architectural design process. There are three main categories of concepts: intentional elements, links, and actors. The intentional elements in GRL are goal, task, softgoal, and resource. They are intentional because they are used for models that allow answering questions such as why particular behaviors, informational and structural aspects were chosen to be included in the system requirement, what alternatives were considered, what criteria were used to deliberate among alternative options, and what the reasons were for choosing one alternative over the other.
A GRL model can either be composed of a global goal model, or a series of goal models distributed in several actors. If a goal model includes more than one actor, then the intentional dependency relationships between actors could also be represented and reasoned about. In this paper, the distributed goal models will not be discussed, we may have another paper studying the roles of agent-orientation in requirement and architectural design.
A goal is a condition or state of affairs in the world that the stakeholders would like to achieve. In General, how the goal is to be achieved is not specified, allowing alternatives to be considered. A goal can be either a business goal or a system goal. A business goal express goals regarding the business or state of the business affairs the individual or organization wishes to achieve. System goal expresses goals the target system should achieve, which, generally, describe the functional requirements of the target information system. In GRL graphical representation, goals are represented as a rounded rectangle with goal name inside.
A task specifies a particular way of doing something. When a task is specified as a sub-component of a (higher-level) task, this restricts the higher-level task to that particular course of action. Tasks can also be seen as the solutions in the target system, which will satisfice the softgoals (called operationalizations in NFR) or achieve goals. These solutions provide operations, processes, data representations, structuring, constraints and agents in the target system to meet the needs stated in the goals and softgoals. In GRL graphical representation, tasks are represented as a hexagon with task name inside.
A softgoal is a condition or state of affairs in the world that the actor would like to achieve, but unlike in the concept of (hard) goal, there are no clear-cut criteria for whether the condition is achieved, and it is up to subjective judgement and interpretation of the developer to judge whether a particular state of affairs in fact achieves sufficiently the stated softgoal. Softgoal is used to represent NFRs in the future system. Non-functional requirements, such as performance, security, accuracy, reusability, interoperability, time-to market and cost are often crucial for the success of a software systems. They should be addressed as early as possible in a software lifecycle, and be properly reflected in software architecture before a commitment is made to a specific implementation. In GRL graphical representation, A softgoal, which is "soft" in nature, is shown as an irregular curvilinear shape with softgoal name inside.
A resource is an (physical or informational) entity, with which the main concern is whether it is available. Resources are shown as rectangles in GRL graphical representation.
Intentional links in GRL includes means-ends, decomposition, contribution, correlation and dependency. Means-ends is used to describe how goals are in fact achieved. Each task connected to a goal by means-ends link is an alternative means for achieving the goal. Decomposition defines what other sub-elements needs to be achieved or available in order for a task to be performed. Contribution describes how softgoals, tasks, links contribute to others. A contribution is an effect that is a primary desire during modelling. Contributions can be either negative, or positive, can be either sufficient or partial. Following are the graphical representations for links.
Figure 1 (a) Means-Ends; (b)Decomposition;
(c) Contribution; (d) Correlation
Use Case Maps notation (UCMs) employ scenario paths to illustrate causal relationships among responsibilities. Furthermore, UCM provides an integrated view of behavior and structure by allowing the superimposition of scenario paths on a structure of abstract components. The combination of behavior and structure in UCMs enables architectural reasoning. Scenarios in UCM can be structured and integrated incrementally. This enables reasoning about and detection of potential undesirable interactions of scenarios and components. Furthermore, the dynamic (run-time) refinement capabilities of the UCM language allow for the specification of (run-time) policies and for the specification of loosely coupled systems where functionality is decided at runtime through negotiation between components.
The UCM notation is mainly composed of path elements, and also of components. The basic path notation address simple operators for causally linking responsibilities in sequences, as alternatives, and in parallel. More advanced operators can be used for structuring UCMs hierarchically and for representing exceptional scenarios and dynamic behavior. Components can be of different natures, allowing for a better and more appropriate description of some entities in a system.
Basic elements of UCMs are start points, responsibilities, end points and components. Starting points are filled circles representing pre-conditions or triggering causes. End points are bars representing post-conditions or resulting effects. Responsibilities are crosses representing actions, tasks or functions to be performed. Components are boxes representing entities or objects composing the system. Paths are the wiggle lines that connect start points, responsibilities and end points. A responsibility is said to be bound to a component when the cross is inside the component. In this case, the component is responsible to perform the action, task, or function represented by the responsibility.
Alternatives and shared segments of routes are represented as overlapping paths. An OR-join merges two (or more) overlapping paths while an OR-fork splits a path into two (or more) alternatives. Alternatives may be guarded by conditions represented as labels between square brackets. Concurrent and synchronized segments of routes are represented through the use of a vertical bar. An AND-join synchronizes two paths together while an AND-fork splits a path into two (or more) concurrent segments.
When maps become too complex to be represented as one single UCM, a mechanism for defining and structuring sub-maps become necessary. A top level UCM, referred to as a root map, can include containers (called stubs) for sub-maps (called plug-ins). Stubs are represented as diamonds. Stubs and plug-ins are used to solve the problems of layering and scaling or the dynamic selection and switching of implementation details.
Other notational elements include: timer, abort, failure point, and shared responsibilities. Detailed introduction and example of these concepts can be found in [2] [3].
Although UCM could represent the alternatives of system architectural design precisely in a high-level way, the tradeoffs between these alternatives, and the intentional features of making a design decision could not be explicitly shown in UCM models. And inevitably, as other scenario-based approaches, UCM models are partial.
GRL provides support for reasoning about scenarios by establishing correspondences between intentional GRL elements and functional components and responsibilities in scenario models of UCM. Modelling both goals and scenarios is complementary and may aid in identifying further goals and additional scenarios (and scenario fragments) important to architectural design, thus contributing to the completeness and accuracy of requirement, as well as quality of architectural design.
A complete requirement specification should clarify the objectives of a system to be achieved, the concrete behaviors and constraints of the system-to-be, and the entities being responsible for certain functions in that system.
Goal-based approaches focuses on answering the "why" questions of requirements (such as "why the system needs to be redesigned?" "Why a new architecture for TSMA is necessary?"), the strength of these approaches is that they could cover not only functional requirements but also non-functional requirements (in other words, the quality requirements). Although goal-orientation is highly appropriate for requirement engineering, goals are sometimes too abstract to capture at once. Operational scenarios of using the hypothetical system are sometimes easier to get in the first place than some goals that can be
made explicit only after deeper understanding of the system has been gained.
In our approach, GRL models are created, the original business goals and non-functional requirements are refined and operationalized, until some concrete design decisions are launched. These design decisions are then further elaborated into UCM scenarios. In the scenario authoring of this step, "how" questions are asked instead of "what".
At the same time, UCM scenarios are used to describe the behavioral features and architectures of the intended system in the restricted context of achieving some implicit purpose(s), which basically answers the "what" questions, such as "what the system should do as providing a in-coming call service?" "What is the process of wireless call transmitting?" Then, by issuing "why" questions referring to these scenarios (e.g. "why to reside a function entity in this network entity instead of the other?") some implicit system goals are further disclosed.
The GRL-UCM combination aims to elicit, refine and operationalize
requirements incrementally until a satisficing architectural design is
launched. The general steps of the process are illustrated in Figure 1.
To illustrate the interleaved application of GRL and UCM, we use an example from the mobile telecommunication systems domain [9]. A mobile switching center (MSC) is required to support narrowband and wideband voice, data and imaging services and so on. We use GRL and UCM together to trace the process from capturing the original business objective, to refining and operationalizing this objective, and to trading off each architectural design options.
Step 1: GRL Model- Original functional and non-functional
requirements are represented as three floating nodes in Figure 2. The goal
node in the middle represents the functional requirement on the TDMA that
it must support Narrowband and wideband voice, data and image services.
There are two quality requirements identified at the very beginning, one
is to maximize the call capacity in the new TDMA architecture, the other
is to minimize the cost of the infrastructure.
Figure 3: Original Goal Model with one functional goal and two non-functional goals
Step 2: UCM Model- The essential scenario that implements
the functional goal in above GRL model is given in Figure 3. The scenario
path (denoted by the wiggle line) represents a causal sequence of responsibilities
(denoted by a cross) that is triggered by an initial event (denoted by
a filled circle), resulting in a terminating event (denoted by a bar).
The responsibilities are not bound to any components.
Figure 4: Unbound use case path with responsibilities
Step 3: UCM Model – Binding Responsibilities to components of the future system.
The following UCM diagram (Figure 4) shows the existing
TDMA architecture. In this architecture, the Decoder of the Voice Coder
is located in the base station. This implies that the 64-kb/s PCM of decoded
voice will be transmitted out of the cell site to the switch for each call,
requiring an entire Digital Signal level 0 channel (DS0) to support the
64-kb/s signal.
Figure 5: Bound use case path with functional objects and physical entities
Step 4: GRL Model – Goal Refinement and Operationalization.
In the goal model in Figure 5, the original functional goal is connected
to the task node representing current solution for TDMA. It can be seen
that current solution can cause some delay per call, which may negatively
influence the voice quality of the call, and call capacity of the system.
This solution does not use packet switching protocol enough, so cost could
not be saved. Traffic performance between base station and switch is also
low.
Figure 6: Refined GRL model with one design solution and more non-functional requirements
With current infrastructure, the efficiency of TDMA is barely equivalent to that of analog system, which means the requirements on improving the capacity, quality, cost and performance are all weakly denied.
Step 5: UCM Model – Change the Binding of Responsibilities.
As the above design could not satisfy the non-functional
requirements of the infrastructure, other options should be explored. The
UCM model (in Figure 6) describes a new architecture to improve the capacity
of the TDMA cellular telecommunications system. In this design, the Decoder
of voice Coder is relocated into the switch instead of the base station,
then for each call the base station would transmit an 8-kb/s signal – rather
than a 64-kb/s signal to the switch. In such a system, a theoretical maximum
of 8´ capacity improvement is possible.
Figure 7: UCM model of another way of binding
Step 6: GRL Model – Contributions of the new architecture
to the non-functional requirements. The GRL model (in Figure 7) shows that
the new TDMA architecture with voice coder relocated in the switch weakly
satisficed the requirements on improving the capacity, quality, performance,
though at the same time the cost and complexity are negatively influenced.
To minimize call delay somehow increased the complexity and cost of the
architecture (represented in Figure 7 with correlation links). Compare
the two architectures, if a cell site supported x calls, the previous architecture
would need x DS0s to support those calls. But the Voice Coder relocation
architecture would requirement only x/3 DS0s. Given the evaluation result,
we judged that the new architecture to be an acceptable design.
Figure 8: GRL model evaluating the contribution of the new architecture to NFRs
GRL supports the evaluation of the satisficing of softgoal with a qualitative labeling procedure. The label of high-level model is propagated from the label of low level nodes, and the contribution from these nodes.
However, before putting this relocating solution into practice, other possible solutions should also be. The following is one possible solution without relocating the Decoder of Voice Coder.
Step 7: UCM Model – In Figure 9, by adding new functional
units without changing the location of Decoder of Voice Coder, a simplest
solution is described. For increasing call capacity, 32-kb/s adaptive differential
pulse code modulation (ADPCM) equipment is used with voice decoder still
in the base station.
Figure 9: UCM model of solution 3: new responsibilities and functional units added
Step 8: GRL Model – Evaluation of new architecture according
to the non-functional requirements, and compare to other options. The GRL
model in Figure 10 shows that this simplest solution weakly satisficed
the requirements on improving the capacity, performance, low cost and low
complexity. However, voice quality is seriously eroded by the electrical
echo, the delay for the extra cycle of speech coding, and the information
lost produced in this kind of architecture. While user puts voice quality
in a lower priority, this architecture could also be an acceptable choice.
Figure 10: Goal model evaluating the viability of solution 3
Having analyzed the benefits and tradeoffs of these architectures, we could see that UCM is a natural counterpart to GRL in the process from requirement to high-level design, because it provides the concrete model of each design alternative. Based on the architectural features in this model, new non-functional requirements of concern could be detected and added into the GRL model. At the same time, in the GRL model, new means to achieve the functional requirement could always be explored and be embodied in UCM model.
In the case study above, the UCM model are rather simplistic
because we have only tackled the highest level of architectural design
in the wireless telecommunication protocol. As we go down to the enough
detailed design, a UCM model could be fairly complex, and more modelling
constructs could be used. Figure 11 (From [1] ) is a root map of a mobile
system, it illustrates the "big picture" of a simplified mobile wireless
communication system. As shown in this graph, stubs are used to hide details
of certain sections of a scenario, e.g., the mobility management functions
(MM stub), the communication management functions (CM stub), the handoff
procedures (HP stub) and handoff failure actions (HFA stub).
Figure 11: The Mobile system Root Map[1];
A plug-in gives more detail for the stubs. For the limitation
of space we won’t present all of the plug-ins as well as explain the details
of each responsibility. However, one thing need to be notified is, for
each stub (especially a static stub), there could be more than one ways
to refine the plug-ins. This is a powerful construct to form new design
alternatives by integrating possible designs of various parts of the system.
Figure 12 depicts an integrated scenario of establishing
a call between the originating and the terminating parties. There could
be other possible designs, but we won’t investigate for the limitation
of space. Components in Figure 12 include: Originating Mobile Station (MS-O),
Originating Mobile switching Center (MSC-O), Home Location Register (HLR),
Visitor Location Register (VLR), Terminating Mobile Station (MS-T), Terminating
Mobile switching Center (MSC-T), Originating and Terminating Mobile Stations
(MS-OT).
Figure 12: Integration of Scenario Fragments
[1]
Although we used a telecommunication system architecture
example, the approach is applicable to allocation of responsibility in
software systems in general, where there are usually conflicting goals
and tradeoffs.
As existing scenario-based approaches are serving
different purposes, using different representational features, and having
different analysis capabilities, the concept of scenario needs to be differentiated
according to these contexts.
In Krutchen’s 4+1 model of software architecture [7], scenarios are used to show connections across other views such as logical view, process view, physical view and development view. The use of a multiple view model of architecture allows to address separately the concerns of the various stakeholders of the architecture. However, with an architecture model composed of several separate views it is not easy to keep a coherent track of the incremental design process. As UCM shows the behavioral and structural aspects together as one view, it is good for showing incremental elaboration of the design.
The Software Architecture Analysis Method (SAAM) [5, 6] is a scenario-based method for evaluating architectures. It provides a means to characterize how well a particular architectural design responds to the demands placed on it by a particular set of scenarios. Based on the notion of context-based evaluation of quality attributes, their method adopts scenarios as the descriptive means of specifying and evaluating quality attributes. For example, to evaluate the modifiability of a user interface architecture Serpent, two scenarios are considered, one is "changing the windows system/toolkit", and the other is "adding a single option to a menu". The similarities between this paper and SAAM include: both works concerns the quality of architecture, and both use scenarios to describe architectures. However, there are obvious differences: SAAM scenarios are use-oriented scenarios, which are designed specifically to evaluate certain quaility attributes of architecture. In GRL vs. UCM, scenarios are more design-oriented, which is the refinements of system requirements. The quality of the architectures corresponding to these scenario are judged based on expert knowledge rather than simulations or tests as in SAAM.
The combined use of goals and scenarios have been explored within RE, primarily for eliciting, validating and documenting software requirements. Van Lamsweerde and Willement studied the use of scenarios for requirement elicitation and explored the process of inferring formal specifications of goals and requirements from scenario descriptions in [8]. Though they thought goal elaboration and scenario elaboration are intertwined processes, their work regarding scenarios in [8] mainly focuses on the goal elicitation. Our emphasis happens to be on the other way around, i.e., how to use goal model (especially NFRs) to direct scenario –based architectural design. The fundamental point is that both the goal-oriented modeling in GRL and the scenario-based modeling in UCM run through requirement process to architectural design, so as their interactions.
In the CREWS project, Collete Rolland et al. have looked into the coupling of goal and scenario in RE with CREWS-L’Ecritoire approach [10]. In CREWS-L’Ecritoire, Scenarios are used as a means to elicit requirements/goals of the system-to-be. Their method is semi-formal. Both goals and scenarios are represented with structured textual prose. The coupling of goal and scenario could be considered as a "tight" coupling, as goals and scenarios are structured into <Goal, Scenario> pairs, which are called "requirement chunks". Their work focuses mainly on the elicitation of functional requirements/goals.
In UCM-GRL, both graphical representations and textual
descriptions (in natural language and XML format) for goal model and scenario
model are provided. The semi-formal graphical notations are intended to
be used during the early stages of architectural design, to help explore
and prune the space of design more alternatives. They are to be supplied
by for formal notations and analyses in subsequent stages. The current
coupling of goal and scenario is loose, as goal models and scenario are
all maintaining their local completeness, and one scenario may refer to
more than one goal, and vice versa. There are no rigid constraints on the
requirement process. That is, the goal model and scenario model could be
developed in parallel simultaneously, they interact whenever there are
design decisions need to be traded off, or new design alternatives need
to be sought, or new business goals, non-functional requirements are discovered….
Both functional and non-functional requirements are considered, and perhaps
even more attentions are devoted to non-functional requirements. The modelling
process involves both requirements engineering activities and high-level
architecture design.
In summary, goal-orientation and scenario-orientation
compensate to each other not only in requirement engineering but also during
the incremental architectural design process. The combined use of GRL and
UCM enables the description of both functional and non-functional requirements,
both abstract requirements and concrete system architectural models, both
intentional strategic design rationales, and non-intentional details of
concurrent, temporal features of the future system.
In the future, we hope to look into create visualized the connections between GRL and UCM to support a more formal combination of the two notations. Thus, the mapping and interacting between the two kinds of models would not rely so much on the human behaviors how they are used.
Another direction would be the accumulation of domain
knowledge as well as software design knowledge represented in GRL and UCM.
We would say that GRL and UCM are actually the container of knowledge,
and it is the knowledge that can be reused, and to guide the future design
process.
The work of this paper is motivated by an original
submission to ITU-T study group 10 on the topic of User Requirements Notation
(URN). The kind cooperation of people from Mitel Networks, Nortel Networks
and other institutions is gratefully acknowledged.