Results 1 - 10
of
17
Goal-Oriented Requirements Engineering: A Guided Tour
, 2001
"... Goals capture, at different levels of abstraction, the various objectives the system under consideration should achieve. ..."
Abstract
-
Cited by 162 (3 self)
- Add to MetaCart
Goals capture, at different levels of abstraction, the various objectives the system under consideration should achieve.
Agent-Based Tactics for Goal-Oriented Requirements Elaboration
, 2002
"... Goal orientation is an increasingly recognized paradigm for eliciting, structuring, analyzing and documenting system requirements. Goals are statements of intent ranging from high-level, strategic concerns to low-level, technical requirements on the software-to-be and assumptions on its environment. ..."
Abstract
-
Cited by 50 (6 self)
- Add to MetaCart
Goal orientation is an increasingly recognized paradigm for eliciting, structuring, analyzing and documenting system requirements. Goals are statements of intent ranging from high-level, strategic concerns to low-level, technical requirements on the software-to-be and assumptions on its environment. Achieving goals require the cooperation of agents such as software components, input/output devices and human agents. The assignment of responsibilities for goals to agents is a critical decision in the requirements engineering process as alternative agent assignments define alternative system proposals. The paper describes a systematic technique to support the process of refining goals, identifying agents, and exploring alternative responsibility assignments. The underlying principles are to refine goals until they are assignable to single agents, and to assign a goal to an agent only if the agent can realize the goal.
There are various reasons why a goal may not be realizable by an agent, e.g., the goal may refer to variables that are not monitorable or controllable by the agent. The
notion of goal realizability is first defined on formal
grounds; it provides a basis for identifying a complete taxonomy of realizability problems. From this taxonomy we
systematically derive a catalog of tactics for refining goals and identifying agents so as to resolve realizability problems. Each tactics corresponds to the application of a formal refinement pattern that relieves the specifier from
verifying the correctness of refinements in temporal logic.
Our techniques have been used in two case studies of significant size; excerpts are shown to illustrate the main
ideas.
Deriving Operational Software Specifications from System Goals
, 2002
"... Goal orientation is an increasingly recognized paradigm for eliciting, modeling, specifying and analyzing software requirements. Goals are statements of intent organized in AND/OR refinement structures; they range from high-level, strategic concerns to lowlevel, technical requirements on the softwar ..."
Abstract
-
Cited by 48 (4 self)
- Add to MetaCart
Goal orientation is an increasingly recognized paradigm for eliciting, modeling, specifying and analyzing software requirements. Goals are statements of intent organized in AND/OR refinement structures; they range from high-level, strategic concerns to lowlevel, technical requirements on the software-to-be and assumptions on its environment. The operationalization of system goals into specifications of software services is a core aspect of the requirements elaboration process for which little systematic and constructive support is available. In particular, most formal methods assume such operational specifications to be given and focus on their a posteriori analysis.
The paper considers a formal, constructive approach in which operational software specifications are built incrementally from higher-level goal formulations in a way that guarantees their correctness by construction. The operationalization process is based on formal derivation rules that map goal specifications to specifications of software operations; more specifically, these rules map
real-time temporal logic specifications to sets of pre-, post- and trigger conditions. The rules define operationalization patterns that may be used for guiding and documenting the operationalization process while hiding all formal reasoning details; the patterns are formally proved correct once and for all. The catalog of operationalization patterns is structured according to a rich taxonomy of goal specification patterns.
Our constructive approach to requirements elaboration requires a multiparadigm specification language that supports incremental reasoning about partial models. The paper also provides a formal semantics for goal operationalization and discusses several semantic features of our language that allow for such incremental reasoning.
Reasoning about Partial Goal Satisfaction for Requirements and Design Engineering
, 2004
"... Exploring alternative options is at the heart of the requirements and design processes. Different alternatives contribute to different degrees of achievement of non-functional goals about system safety, security, performance, usability, and so forth. Such goals in general cannot be satisfied in an a ..."
Abstract
-
Cited by 34 (2 self)
- Add to MetaCart
Exploring alternative options is at the heart of the requirements and design processes. Different alternatives contribute to different degrees of achievement of non-functional goals about system safety, security, performance, usability, and so forth. Such goals in general cannot be satisfied in an absolute, clear-cut sense. Various qualitative and quantitative frameworks have been proposed to support the assessment of alternatives for design decision making. In general they lead to limited conclusions due to the lack of accuracy and measurability of goal formulations and the lack of impact propagation rules along goal contribution links. The paper presents techniques for specifying partial degrees of goal satisfaction and for quantifying the impact of alternative system designs on the degree of goal satisfaction. The approach consists in enriching goal refinement models with a probabilistic layer for reasoning about partial satisfaction. Within such models, non-functional goals are specified in a precise, probabilistic way; their specification is interpreted in terms of application-specific measures; impact of alternative goal refinements is evaluated in terms of refinement equations over random variables involved in the system's functional goals. A systematic method is presented for guiding the elaboration of such models. The latter can then be used to assess the impact of alternative decisions on the degree of goal satisfaction or to derive quantitative, fine-grained requirements on the software to achieve the higher-level goals.
From Object Orientation to Goal Orientation: A Paradigm Shift for Requirements Engineering
- Radical Innovations of Software & System Engineering, Montery’02 Workshop, Venice(Italy), LNCS
, 2003
"... Requirements engineering (RE) is concerned with the elicitation of the objectives to be achieved by the system envisioned, the operationalization of such objectives into specifications of services and constraints, the assignment of responsibilities for the resulting requirements to agents such a ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
Requirements engineering (RE) is concerned with the elicitation of the objectives to be achieved by the system envisioned, the operationalization of such objectives into specifications of services and constraints, the assignment of responsibilities for the resulting requirements to agents such as humans, devices and software, and the evolution of such requirements over time and across system families. Getting highquality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as an area of primary concern in software engineering research and practice.
Fluent temporal logic for discrete-time in event-based models
- In Proceedings of the 10th European Software Engineering Conference
, 2005
"... Fluent model checking is an automated technique for verifying that an event-based operational model satisfies some state-based declarative properties. The link between the event-based and statebased formalisms is defined through "fluents " which are state predicates whose value are determi ..."
Abstract
-
Cited by 8 (3 self)
- Add to MetaCart
Fluent model checking is an automated technique for verifying that an event-based operational model satisfies some state-based declarative properties. The link between the event-based and statebased formalisms is defined through "fluents " which are state predicates whose value are determined by the occurrences of initiating and terminating events that make the fluents values become true or false, respectively. The existing fluent temporal logic is convenient for reasoning about untimed event-based models but difficult to use for timed models. The paper extends fluent temporal logic with temporal operators for modelling timed properties of discrete-time eventbased models. It presents two approaches that differ on whether the properties model the system state after the occurrence of each event or at a fixed time rate. Model checking of timed properties is made possible by translating them into the existing untimed framework.
Goal-oriented specification of adaptation requirements engineering in adaptive systems
- in: Proceedings of the Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’06
, 2006
"... Adaptive software is being used increasingly frequently by various users, such as the medical community, software industry, and in response to terror attacks. Therefore, understanding the requirements of an adaptive system is crucial to developing them correctly. Developers need to be able to reason ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Adaptive software is being used increasingly frequently by various users, such as the medical community, software industry, and in response to terror attacks. Therefore, understanding the requirements of an adaptive system is crucial to developing them correctly. Developers need to be able to reason about the requirements of a system’s adaptive behavior. Adaptation semantics are intended to describe how systems behave during adaptation. Previously, Zhang and Cheng formally specified three commonly occurring adaptation semantics in terms of Adapt operator-extended LTL (A-LTL). This paper presents goal-oriented specifications of these three adaptation semantics. These specifications, specified with the KAOS methodology, provide a graphical wrapper to the formal A-LTL specifications of the semantics. The combination of the goal-oriented, graphical KAOS specifications and A-LTL specifications provides the benefits of formal specifications as well as the benefits of an easier to understand, graphical, and more intuitive presentation of adaptive systems requirements. This work also provides a means to incorporate the adaptation semantics into the goaloriented requirements specifications of an adaptive system. Categories and Subject Descriptors: D.2.1 [SOFTWARE ENGINEERING]: Requirements/Specifications goal-driven requirements engineering, formal methods, reliability
High Assurance Requires Goal Orientation
- In Proc Int’l Workshop Reqmts for High Assurance Sys
, 2002
"... High assurance systems must guarantee safety, security, fault tolerance and survivability objectives; it is therefore essential that such objectives be made explicit, refined, specified precisely and completely in application-specific terms, interrelated and analyzed thoroughly. The paper argues tha ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
High assurance systems must guarantee safety, security, fault tolerance and survivability objectives; it is therefore essential that such objectives be made explicit, refined, specified precisely and completely in application-specific terms, interrelated and analyzed thoroughly. The paper argues that goals are an essential abstraction for eliciting, elaborating, modeling, specifying, analyzing, verifying, negotiating and documenting robust and conflict-free requirements for high assurance systems. A safety injection system for a nuclear power plant is used as a running example to illustrate the key role of goals while engineering such requirements.
Goal-Oriented Elaboration of Security Requirements
, 2001
"... We suggest an approach to software development that
integrates elaboration of security requirements at an early stage of the software life cycle. Reasoning about security in goal-oriented requirements engineering allows one to anticipate malicious behaviours of agents in the environment of the soft ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
We suggest an approach to software development that
integrates elaboration of security requirements at an early stage of the software life cycle. Reasoning about security in goal-oriented requirements engineering allows one to anticipate malicious behaviours of agents in the environment of the software-to-be and thereby systematically build more robust systems. We will elaborate attack patterns whose instantiation on a specific system will generate resolution strategies to avoid them, either by design strenghtening or by some alternative design. Cryptographic techniques will contribute to build secure systems that are resistant against hostile environment agents. The suggested approach is based on a formal specification methodology that has been validated on industrial projects.
Project of CS515x Goal-Oriented Requirements Engineering and Safety-Critical Systems By
"... Goal-orientation is becoming more and more recognized as a paradigm for eliciting, structuring, analyzing and documenting system requirements [Let02]. Goals have been known as essential components involved in the requirements engineering process [Lam01]. A lot of research work has been done on goal- ..."
Abstract
- Add to MetaCart
Goal-orientation is becoming more and more recognized as a paradigm for eliciting, structuring, analyzing and documenting system requirements [Let02]. Goals have been known as essential components involved in the requirements engineering process [Lam01]. A lot of research work has been done on goal-oriented method. And it is

