A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the 22nd International Conference on Software Engineering, Invited Paper, ACM Press, June 2000.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of the discipline into a number of well defined sub areas. 41] names elicitation, modeling and analyzing, communication, agreement and evolution of requirements as the core requirements activities. Other relevant activities are domain analysis, specification and specification analysis [51]. Many empirical and theoretical contributions have appeared in all those areas, but only in a few cases the research e#ort has been accompanied by a widespread adoption of tools and environments to support the various activities and processes. In particular, requirements management tools (e.g. ....

....requirements and the usefulness of building models based on those requirements have long been recognized in the literature. In [15] Al Davis states among his principles of Software Engineering: Increase, never substitute, natural language . Five years later, in his 2000 review and agenda paper [51], Axel van Lamsweerde observed: The final deliverable of the requirements phase is most often a document in natural language, that in addition to indicative and optative statements may integrate graphical portions of models [ A most welcome tool would be one to assist in the generation of ....

A. van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceedings of the 22 d International Conference on Software Engineering (ICSE 2000.

....into account process aspects and history of changes. The empirical results support the models underlying the proposed metrics. The empirical nature of this work allows to replicate the experiment in other industrial contexts and to benefit of our results. 1. Introduction Requirements Evolution [5, 6, 7, 13, 18, 19] is considered one of the most critical issues in developing computerbased systems. Requirements Evolution may cause increased cost as well as system degradation. This phenomenon arises in any industrial context developing computer based systems. Requirements Evolution is due to both social and ....

A. van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceedings of the 2000.

....aided by taking prospective users through usage scenarios [7] for example. Agent oriented approaches to development should not force any change in an applications requirements. Therefore, the techniques used in requirements engineering for agent based systems will be the same as those elsewhere [3, 12] (see Tropos [1] for an agent oriented software engineering methodology based on requirements engineering) A common requirements engineering technique is to describe the requirements in terms of functional goals it is intended to achieve and priorities and restrictions which, jointly, we call ....

A. van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceeding of the Twenty-Second International Conference on Software Engineering (ICSE00) , 2000.

....of the most important goals of elicitation is to find out what problem needs to be solved. They also rightly present validation as a very difficult problem concerning truth and knowledge. Similar points, mainly related to the importance of goal discovery and modelling, are made by van Lamsweerde [31]. 2.1. Purposefulness We build software for some reason. If that reason is fulfilled then the software is successfully built. Of course this idea of success is subjected to ethical considerations. One may, as I do, reject as successful a system built to satisfy unethical or immoral objectives. ....

A. van Lamsweerde. Requirements engineering in the year 00: A research perspective. In 22nd International Conference on Software Engineering, ICSE'00, Limerick, Ireland, June 2000. IEEE Computer Society Press.

.... quality attributes that can be improved through them [1, 3, 4, 7, 8, 9, 14, 15, 17, 18, 19, 21, 22] Despite the significant amount of research in architectural specification, there has been little attempt to formally relate it to higher levels of specification, such as the system requirements [24]. Only recently has interest begun to emerge in this regard [16, 20] In this paper we present our progress toward addressing an instance of this problem, namely relating high level functional specifications to software architecture specifications. We describe our approach in the context of a ....

....implementation is provided, and that its structure and behavior should be prescriptive with respect to the implementation. The relationship between architecture and requirements is, by contrast, less clear. On one side there is the awareness that requirements and architectures should be related [24]. On the other there is the di#culty of relating very di#erent concerns, modeled in di#erent ways. In this paper we tackled an instance of this problem by showing how a requirement on the data coherency of a system, modeled in a functional way, can be related to three variants of a software ....

A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the 2000.

....This is reflected, within individual approaches, in the use of multiple conceptual perspectives, multiple languages, multiple views or specifications, and multiple classifications. Additionally, a multidimensional view of requirements engineering overall has been emphasized by van Lamsweerde [12]. He characterizes the first 25 years of requirements engineering research as 6 addressing the four dimensions of ontology, structuring, specification, and reasoning, and he argues that the next 25 years will focus on multi X approaches, integrating multiple languages and formats, multiple ....

van Lamsweerde, A. Requirements Engineering in the Year 00: A Research Perspective. 22nd Int. Conf. on Software Eng., ACM Press, 2000, pp. 5--19.

....requirements and solution fragments. This graph is next used to pinpoint feature interactions and to guide an iterative architecture development and evaluation process. The structure of this feature solution graph resembles that of the goal hierarchy in goal oriented requirements engineering [2, 3]. The solution fragments included in this graph have much in common with Attribute Based Architectural Styles (ABASs) 1] In principle, any kind of solution description will do. The approach to generating and evaluating architectures from a feature solution graph is depicted in Figure 1. 2 ....

Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Conference Proceedings ICSE'00, pages 5--19, Limerick, Ireland, 2000. ACM.

....asset during the further implementation and evolution of the system. 1. Introduction In most requirements engineering documents, emphasis is placed on the chosen alternative. The discarded ones, and the arguments that led to a particular choice, are often not explicitly recorded and documented [17]. This makes it difficult to retrace decisions and explore alternatives. In our experience, the same holds for software architecture documentation. The architecture of a software system captures early design decisions. These early design decisions reflect major quality concerns, including ....

....emphasis is on identifying and resolving conflicts, rather than retaining a picture of the complete space of options. Early approaches to requirements engineering focussed on eliciting and documenting the requirements sec, and not the reasons for them. In goal oriented requirements engineering [17, 20], the relation between goals and requirements is represented explicitly. Recently, representation schemes used in goaloriented requirements engineering have also been used to represent dependencies between quality goals and architectural styles [5] The Architecture Tradeoff Analysis Method ....

Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Conference Proceedings ICSE'00, pages 5--19, Limerick, Ireland, 2000. ACM.

....on eliciting and documenting the requirements sec, and not the reasons for them. In goal oriented requirements engineering, the relation between goals and requirements is represented explicitly. Since goals may conflict, this requires resolution strategies to obtain a satisfactory compromise [11, 12]. Recently, representation schemes used in goal oriented requirements engineering have also been used to represent dependencies between quality goals and architectural styles [4] In our approach, the generation of a software architecture is based on a rich feature solution graph, which connects ....

Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Conference Proceedings ICSE'00, pages 5--19, Limerick, Ireland, 2000. ACM.

....The key achievement of this new approach is that it makes explicit the why of requirements. Quoting van Lamsweerde, before goal oriented requirements engineering] the requirements on data and operations were just there; one could not capture why they were there and whether they were sufficient [16]. van Lamsweerde s goal oriented requirements engineering approach provides for three levels of modelling: the meta level, that refers to domain independent abstractions. This model contains concepts such as goal, requirement, object, entity, and so on; the base level, containing ....

A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of ICSE'

....quality attributes. We do essentially the same in our FS graph, but we have a stronger focus on a construction generation oriented representation of the architectural knowledge. In goal oriented requirements engineering, the relation between goals and requirements is represented explicitly [8, 13]. A natural continuation of this line of thought is to connect requirements with high level design (i.e. architecture) This is done in GRL UCM [9] The work on Goal Oriented Language (GRL) in combination with UCM (GRL UCM) has a lot of similarities with the concepts presented in this paper. As ....

Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Conference Proceedings ICSE'00, pages 5--19, Limerick, Ireland, 2000. ACM.

.... It is furthermore a key action of many maturity models applied in industry (e.g. CMM [16] Desp ite this Requirements Evolution [1, 2, 10, 11, 18, 23] still remains one of the most critical issues for software organizations and is challenging for research and practice in Requirements Engineering [14, 25]. Current practice in Requirements Engineering [20, 22, 27] relies on general processes (e.g. elicitation, verification, etc. and methodologies (e.g. standards and templates for specifying requirements) that are adapted according to specific needs by plugging in other general processes (e.g. ....

Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceedings of the

....1 Introduction This chapter provides a brief introduction to the thesis, including background, motivation and thesis scope. 1. 1 Background Requirements documents play an important role in software systems development; their importance has been repeatedly recognized during the past 25 years [22]. In [6] Bell and Thayer observed that inadequate, inconsistent, incomplete or ambiguous requirements are very common and have a critical effect on the quality of the resulting software. The impact of errors in requirements on cost and safety has been demonstrated empirically. In a study of 387 ....

Axel van Lamsweerde, Requirements Engineering in the Year 00: A Research Perspective, To be appear in Proc. 22nd International Conference on Software Engineering, Limerick, June 2000, ACM Press

.... methodology called Tropos 1 , that integrates ideas from multi agent system technologies, mostly to define the implementation phase for the software development process [2] and ideas from Requirements Engineering, where actors and goals have been used heavily for early requirements analysis [5, 10]. In a recent state of the art survey on agentoriented software engineering [4] several principled but in 1 Tropos (from the Greek aeoj , trop e , which means easily changeable , also easily adaptable ) Permission to make digital or hard copies of all or part of this work for personal or ....

A. van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceedings 22nd International Conference on Software Engineering, Invited Paper, ACM Press, June 2000.

No context found.

A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the 22nd International Conference on Software Engineering, Invited Paper, ACM Press, June 2000.

No context found.

van Lamsweerde, A., Requirements engineering in the year 00: a research perspective, Proc. of 22nd Int. Conference on Software Engineering, Limerick, Ireland, June, 2000

No context found.

A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the 22nd International Conference on Software Engineering, Invited Paper, ACM Press, June 2000.

No context found.

A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. In Proceedings of the 22nd International Conference on Software Engineering, Invited Paper, ACM Press, June 2000.

No context found.

van Lamsweerde, A.: Requirements Engineering in the Year 00: A Research Perspective. Proceedings of 22nd International Conference on Software Engineering. ACM, Limerick, Ireland (June 2000) Isabel Ramos et al.

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