A. van Lamsweerde and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. TSE, 26(10):978--1005, 2000. Home/Search Document Details and Download
Summary Related Articles Check |
This paper is cited in the following contexts:
First 50 documents
A Reuse-Based Approach to Determining Security Requirements - Sindre, Firesmith, Opdahl (Correct)
....that goals and threats are opposites, their relationship to requirements are quite the same (e.g. that there can be many different choices of requirements to address the same goal or threat) Hence, our approach is also related to goal oriented approaches. For instance, the obstacles discussed in [36] (in connection with the KAOS method) could be likened to our threats, and [19] in connection with the GBRAM approach) discusses the linking of security privacy policies and requirements. Also relevant is the work on trust in i [37] by which threats can also be modeled. Rather than ....
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering," IEEE Transactions on Software Engineering, vol. 26, pp. 978-1005, 2000.
Trustworthy Refinement Through Intrusion-Aware Design - Ellison, Moore (2002) (Correct)
....only to induce a specification from a collection of scenarios [Potts 95] System requirements for both functional and non functional requirements can be defined as scenarios. A thread through the scenario literature involving obstacle analysis deals explicitly with a negative view [Potts 95, van Lamsweerde 00] Obstacle analysis identifies and analyzes obstacles to realizing usage scenarios. Intrusions, or attacks, can be viewed as an obstacle to the security of a system. Negative scenarios are sometimes used during obstacle analysis, but primarily only to show the reality of the obstacle [Potts 95, ....
van Lamsweerde, A. & Letier, E. "Handling Obstacles in GoalOriented Requirements Engineering." IEEE Transactions on Software Engineering 26, 10 (October 2000): 978-1005.
The Application of Software and Safety Engineering Techniques to.. - Foster (2003) (1 citation) (Correct)
....supports the formal analysis of the specification. This approach does, however, employ heuristics in the early goal refinement stages, as well as AND OR graphs for goal decomposition. In particular, the KAOS approach supports scenario analysis [160] and obstacle identification and resolution [159], as in GBRAM. Chung [44] uses a similar approach to the goal directed requirements acquisition of Dardenne et al. 51] Chung s process oriented approach to information system development represents and uses the security requirements during the semi formal, partially automated, development ....
Axel van Lamsweerde and Emmanuel Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on Software Engineering, 26(10):978--1005, October 2000. Available from: http://www.info.ucl.ac.be/research/projects/AVL/ReqEng. html.
Goals, Interpretations, and Policies in Information Systems.. - Regev, Wegmann (2001) (Correct)
....[12] 13] 22] 34] Goal oriented requirements engineering approaches promise to specify systems that better support stakeholders by analyzing their goals. Goals are viewed as the source of all requirements. Goals are considered to be, more stable than the requirements to achieve them. [45] By focusing on goals rather than on interactions, it is also easier to investigate different ways of achieving the stated goals and to detect and solve conflicts between them. In this paper we argue that in the field of enterprise information systems, the understanding of the notions of ....
....built in order to help organizations achieve their goals. Requirements Engineering (RE) is the discipline that seeks to produce a detailed description of an information system to be built so that it matches the goals of the organization for which it was built. As defined by van Lamsweerde Letier [45], RE is, concerned with the elicitation of highlevel goals to be achieved by the envisioned system, specifications of software behavior, and to their evolution. In the RE community, goals are usually defined as objectives to be achieved by the system and its environment [14] 43] 44] 45] ....
[Article contains additional citation context not shown here]
A. van Lamsweerde, E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering," IEEE Trans. Software Eng. Special Issue on Exception Handling, 2000.
Security Requirements Engineering : When.. - Crook, Ince, Lin.. (2002) (6 citations) (Correct)
....There is a need for an important bottom up view of security requirements engineering. Our vision includes the development of a framework to examine systematically requirements and anti requirements building on preliminary work, such as that by van Lamsweerde combining goal and obstacle analysis [VL00]. There are a number of policy description languages, for example Ponder [DDLS00] that have been used for low level specifications of distributed system management. Moffett [Moff99] has posited that these might be used for high level policy specification within requirements engineering. We ....
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-oriented Requirements Engineering", IEEE Transactions on Software Engineering, 26(10). 2000.
Towards a Model-based COTS-aware Requirements Engineering Process - Chung, Cooper (2001) (Correct)
....specifications. Our work is focused on creating and modeling a requirements engineering approach that explicitly supports the use of commercial off the shelf (COTS) components. Our approach is called the COTSAware Requirements Engineering (CARE) approach. It is both goal oriented (e.g. see [1,2,3]) and agent oriented (e.g. see [4] There are two models that describe the CARE approach: a process model and a product model. The process model is the focus of this work. Here we present the process model in the i framework [4] and demonstrate its use with a Digital Library System ....
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26, September 2000.
From Object Orientation to Goal Orientation: A Paradigm.. - van Lamsweerde, Letier (2003) Self-citation (Van lamsweerde Letier) (Correct)
No context found.
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26, No. 10, October 2000, 978-1005.
From System Goals to Intruder Anti-Goals: Attack.. - van Lamsweerde.. (2003) Self-citation (Van lamsweerde) (Correct)
No context found.
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, October 2000.
Deriving Tabular Event-Based Specifications from.. - De Landtsheer.. (2003) (1 citation) Self-citation (Van lamsweerde Letier) (Correct)
No context found.
A. van Lamsweerde and E. Letier, "Handling Obstacles in GoalOrientedRequirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, October 2000.
From Object Orientation to Goal Orientation: A Paradigm.. - van Lamsweerde, Letier Self-citation (Van lamsweerde Letier) (Correct)
No context found.
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26, No. 10, October 2000, 978-1005.
High Assurance Requires Goal Orientation - Letier, van Lamsweerde (2002) Self-citation (Van lamsweerde Letier) (Correct)
.... Positive and negative interactions with the other system goals can be captured in goal models and managed appropriately [Lain98] exceptional conditions in the environment that may prevent critical goals from being achieved can be identified and resolved to produce more robust requirements [Lam00a]; the goals can be specified precisely and refined incrementally into operational software specifications that provably assure the higher level goals [Dar96, Let02a, Let02b] This paper does not describe new research results per se. Our aim here is to illustrate the relevance and benefits of ....
.... systems and is frequently used to illustrate other methods such as, e.g. the SCR method [Heit96] and its analysis techniques [Bha99, Jef98, Gar99] Illustrations on larger, more complex systems such as the LAS ambulance despatching system and the BART train control system can be found in [Lam00a, Lam00b, Let01]. 2. GOAL ORIENTED ANALYSIS OF REQUIRE MENTS FOR A SAFETY INJECTION SYSTEM We follow the KAOS method [Lam00b] to gradually derive the operational requirements for the safety injection software from the underlying system goals. A goal refinement graph is elaborated first by identifying relevant ....
[Article contains additional citation context not shown here]
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", 1EEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26, No. 10, October 2000, 978-1005.
Deriving Operational Software Specifications from System Goals - Letier, van Lamsweerde (2002) (1 citation) Self-citation (Van lamsweerde Letier) (Correct)
....the non functional goal offsprings from the goal graph; 5) functional goals assigned to software agents are operationalized into operations to meet them. Variants of this general scheme are available to integrate scenariobased elicitation [30] conflict analysis [26] and obstacle analysis [28]. The next sections focus on the last step of goal operationalization. 3. SEMANTICS OF OPERATIONALIZATION This section provides the necessary foundations for the operationalization techniques presented in the next section; in particular, the notion of correct operationalization is made fully ....
....operational. Goal mining from operational specifications allows for various goal level analysis, e.g. checking the operational formulation for completeness with respect to goals left implicit; identifying and resolving obstacles to goal achievement in order to produce more robust requirements [28, 29]; identifying and resolving conflicts at the goal level [26] and exploring alternative system proposals [33] To illustrate pattern based goal mining from operational specifications, consider the following excerpt from the initial problem statement for a simple autopilot [4] If the pilot dials ....
[Article contains additional citation context not shown here]
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, October 2000.
Goal-Oriented Requirements Engineering: A Guided Tour - van Lamsweerde (2001) (38 citations) Self-citation (Van lamsweerde) (Correct)
.... goals are non functional goals requiring the state of software objects to accurately reflect the state of the corresponding monitored controlled objects in the environment [My192, Dar93] such goals are often overlooked in the RE process; their violation may be responsible for major failures [Lam00a] Performance goals are specialized into time and space performance goals, the former being specialized into response time and throughput goals [Nix93] Security goals are specialized into confidentiality, integrity and availability goals [Amo94] the latter can be specialized in turn until ....
....obstacle was just mentioned in [Yue87] It was elaborated further in [Pot95] where scenarios are shown to be a good vehicle for identifying goal obstructions. Some heuristics for identifying obstacles can be found in [Pot95] and [Ant98] More formal techniques are described in [Lam98a] and then [Lam00a] for: the abductive generation of obstacles from goal specifications and domain properties, the systematic generation of various types of obstacle resolution, e.g. goal substitution, agent substitution, goal weakening, goal restoration, obstacle mitigation, or obstacle prevention. Obstacles ....
[Article contains additional citation context not shown here]
A. van Lamsweerde and E. Letier, "Handling Obstacles in GoalOriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, 2000.
Agent-Based Tactics for Goal-Oriented Requirements Elaboration - Letier, van Lamsweerde (2002) (2 citations) Self-citation (Van lamsweerde Letier) (Correct)
.... that can be assigned as responsibility of single agents [Dar93] Terminal goals assigned to agents in the software to be become requirements; terminal goals assigned to agents in the environment become assumptions (or normative policies) the latter cannot be enforced by the software to be [Lam00a]. In general, alternative responsibility assignments are to be explored; for example, the goal reverse thrust enabled when landing plane on runway [Lad95, Jac95] might be assigned to the Pilot or the Autopilot agent. Different goal Proceedings ICSE 2002, 24th International Conference on Sofware ....
.... o ReverseThrustEnabled (G2) together with the following assumption on the environment MovingOnRunway WheelsTurning (Ass) Obstacle analysis would reveal that this assumption is in fact too strong because of the possibility of, e.g. plane aquaplaning on a wet runway but this is another story [Lam00a]. The functional subgoal G2 is still not realizable by the Autopilot agent because this agent cannot directly monitor whether the wheels of the plane are turning. Applying one of our tactics again would produce a further refinement of goal G2 into an accuracy subgoal WheelsTurning ....
[Article contains additional citation context not shown here]
A. van Lamsweerde and E. Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26 No. 10, October 2000, pp. 978-1005.
Security and Trust Requirements Engineering - Paolo Giorgini Fabio (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. TSE, 26(10):978--1005, 2000.
Domain System Statecharts: - The Good The (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, 26(10):978--1005, 2000.
Embedding Policy Rules for Software-Based Systems in a.. - Strembeck (2005) (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling Obstacles in GoalOriented Requirements Engineering. IEEE Transactions on Software Engineering (TSE), 26(10), October 2000.
An Integrated Approach to Engineer and Enforce Context.. - Strembeck, Neumann (2004) (Correct)
No context found.
VAN LAMSWEERDE,A.AND LETIER,E. 2000. Handling obstacles in goal-oriented requirements engineering. IEEE Trans. Softw. Eng. 26,10(Oct.).
A Lightweight Process for Architecture Recovery: From Code.. - Svetinovic, Godfrey (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, Vol. 26, No. 10, 2000.
Formal Analysis of Early Requirements Specifications - Fuxman (2001) (6 citations) (Correct)
No context found.
Axel van Lamsweerde and Emmanuel Letier. Handling obstacles in goaloriented Requirements Engineering. IEEE Transactions on Software Engineering, Special Issue on Exception Handling, 2000.
Defining Agents in a COTS-Aware Requirements Engineering Approach - Chung, Cooper (2002) (Correct)
No context found.
van Lamsweerde, A. and Letier, E., "Handling Obstacles in Goal-Oriented Requirements Engineering", IEEE Trans. on Software Eng., Vol. 26, September 2000, pp. 978-1005.
From Goals to Aspects: Discovering Aspects from Requirements.. - Yijun Yu Julio (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling obstacles in goal-oriented requirements engineering. IEEE Trans. Software Eng., 26(10):978--1005, 2000.
An Approach to Engineer and Enforce Context Constraints in.. - Neumann, Strembeck (2003) (5 citations) (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on Software Engineering, 26(10), October 2000.
Architecture-Level Requirements Specification - Svetinovic (Correct)
No context found.
A. van Lamsweerde and E. Letier. Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, Vol. 26, No. 10, 2000.
Attribute-Based Software Evolution: - Patterns And Product (Correct)
No context found.
A. van Lamsweerde, and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on Software Engineering, Vol. 26, No. 10, (October 2000).
First 50 documents
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC