Nuseibeh B, Easterbrook S (2000) Requirements Engineering: A Roadmap. In: The Future of Software Engineering, Special Issue 22nd International Conference on Software Engineering, ACM-IEEE @ NUS Home/Search Document Details and Download
Summary Related Articles Check |
This paper is cited in the following contexts:
First 50 documents
NFR's: Fact or Fiction? - Burge, Brown (Correct)
....needs and desires, are used to both guide the development of the system and to determine if the completed system is what the customer requested. Because of its importance, requirement specification has become a research area known as Requirements Engineering (RE) both in Software Engineering [23, 15] and Systems Engineering [9, 5] The primary goal of Requirements Engineering is to capture and represent system requirements so that they can be traced through to both implementation and testing to ensure that the resulting system does what the customer has requested. Requirements are commonly ....
....be trading off cost versus safety or resources used versus performance. 2.3 Software Requirements When designing software, the consideration of requirements falls into a sub field of Software Engineering known as Requirements Engineering. There are several RE areas where research is being done [15]: eliciting requirements, modeling and analyzing requirements, communicating the requirements, reaching agreement on requirements, and evolving requirements. There is also work done specifically on NFRs. For example, the NFR Framework [6] repre sents the NFRs as goals that must be satisfied by ....
B. Nuseibeh and S. Easterbrook. Require- ments engineering: a roadmap. In Proc. of the Conference on The Future of Software Engineering, pages 35-46, Limerick, Ireland, 2000.
A Relation-based Approach to Use Case Analysis - Fantechi, Gnesi, Lami (Correct)
....document and it represents a starting point towards the formal verification of some relevant aspects. 1. Introduction The problem of the analysis of software requirements with respect to some consistency and correctness parameters has been extensively exploited in several ways in recent years [18] . For example, formal methods and tools have been used for this purpose when a formal representation of software requirements has been adopted. Currently , in the common practice formal notations are not always used in the first description of the system. More frequently Natural Language (NL) ....
B. A. Nuseibeh and S. M. Easterbrook, Requirements Engineering: A Roadmap, In A. C. W. Finkelstein (ed) "The Future of Software Engineering". (Companion volume to the proceedings of the 22nd International Conference on Software Engineering, ICSE'00). IEEE Computer Society Press.
Feature Based Composition - Jansen (Correct)
....the problem domain, which makes communication about the entities (features) between developers and the customer market department easier. # Quality requirement based decomposition [3] 5] Quality requirement based decomposition is an emerging field from the requirement engineering community [39][21]. Quality attributes are mapped onto entities with similar quality requirements on which decomposition choices are made. As with decomposition, there are several composition approaches, the most notable: # Aspect Orientated Programming (AOP see 4.1) # Dynamic inheritance, Subject Orientated ....
Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a roadmap. In Proceedings of the conference on The future of Software engineering, pages 35--46. ACM Press, 2000. http: //doi.acm.org/10.1145/336512.336523
Tool Support for Distributed Requirements Negotiation - Grünbacher, Braunsberger (2003) (Correct)
....capabilities, interfaces, properties, development, and evolution. The goal of specifying complete and consistent requirements is increasingly seen as unpromising and misleading and there is a stronger focus on negotiation techniques for identifying, analyzing and resolving conflicting requirements [9][10] Facilitating the active participation of stakeholders [11] is seen as crucial for project success by understanding the organizational and social context. Requirements emerge from a process of co operative learning in which they are explored, prioritized, negotiated, evaluated, and documented ....
Nuseibeh B., Easterbrook S. Requirements Engineering: A Roadmap, In: The Future of Software Engineering, Special Issue 22nd International Conference on Software Engineering, ACM-IEEE, pp. 37---46, 2000.
Understanding the Requirements for Developing Open Source.. - Scacchi (2001) (5 citations) (Correct)
....publication with revisions, December 2001. 1. Overview The focus in this paper is directed at understanding the requirements for open software development efforts, and how the development of these requirements differs from those traditional to software engineering and requirements engineering [10, 17, 22, 28]. It is not about hypothesis testing or testing the viability of a prescriptive software engineering methodology or notational form. Instead, this study is about discovery, description, and abstraction of open software development practices and artifacts in different settings in different ....
....across different communities We assume there is no a priori model or globally accepted framework that defines how open software is or should be developed. Subsequently, our starting point is to investigate open software practices in different communities from an ethnographic perspective [2, 28, 38]. We have chosen four different communities to study. These are those centered about the development of software for networked computer games, Internet Web infrastructure, X ray astronomy and deep space imaging, and academic software design research. In contrast to efforts that draw attention to ....
[Article contains additional citation context not shown here]
NUSEIBEH, R. and EASTERBROOK, S.: 'Requirements Engineering: A Roadmap', in A. Finkelstein (ed.), The Future of Software Engineering, ACM and IEEE Computer Society Press, http://www.softwaresystems.org/future.html, 2000.
Reconciling Software Requirements and Architectures.. - Grünbacher, Egyed.. (Correct)
....the transition from an EasyWinWin requirements negotiation into a C2 style architectural model. 1 Introduction Software systems of today are characterized by increasing size, complexity, distribution, heterogeneity, and lifespan. They demand careful capture and modeling of requirements [20][24] and architectural designs [23] 25] early on, before the low level system details begin to dominate the engineers attention and significant resources are expended for system construction. Understanding and supporting the interaction between software requirements and architectures remains one ....
....low level system details begin to dominate the engineers attention and significant resources are expended for system construction. Understanding and supporting the interaction between software requirements and architectures remains one of the challenging problems in software engineering research [20]. Evolving and elaborating system requirements into a viable software architecture satisfying those requirements is still a difficult task, mainly based on intuition. Little guidance is available for modeling and understanding the impact of architectural choices on the requirements. Software ....
Nuseibeh B., S. Easterbrook. Requirements Engineering: A Roadmap, In: The Future of Software Engineering, Special Issue 22nd International Conference on Software Engineering, ACMIEEE, pp. 37---46, 2000.
Requirements Honesty - Pinheiro (2002) (Correct)
....and the third to validation. These principles are sometimes related to requirements properties like correctness and consistency. The ideas behind them are present in old and recent surveys. Roman [27] uses the term appropriateness referring to requirements specification. Nuseibeh and Easterbrook [22] say that one 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 ....
B. Nuseibeh and S. Easterbrook. Requirements engineering: A roadmap. In A. C. W. Finkelstein, editor, The Future of Software Engineering, Limerick, Ireland, June 2000. IEEE Computer Society Press. (Companion volume to the proceedings of the 22nd International Conference on Software Engineering, ICSE'00).
The Inevitable Pain of Software Development, Including of Extreme.. - Berry (Correct)
....guilt. 6.4. Requirements Engineering The basic premise of requirements engineering is spend sufficient time up front, before designing and coding, to anticipate all possible requirements and contingencies, so that design and coding consider all requirements and contingencies from the beginning [10, 27]. Consequently, fewer changes are required, and the B L upswing is both delayed and moderated. Data show that errors found during requirements analysis cost one order of magnitude less to fix than errors found during coding and two orders of magnitude less to fix than errors found during operation ....
Nuseibeh, B. and Easterbrook, S., "Requirements Engineering: A Roadmap," in The Future of Software Engineering 2000.
Softw Syst Model (2003) / Digital Object Identifier.. - Reconciling.. (Correct)
No context found.
Nuseibeh B, Easterbrook S (2000) Requirements Engineering: A Roadmap. In: The Future of Software Engineering, Special Issue 22nd International Conference on Software Engineering, ACM-IEEE
Process Modeling in e-Business Systems Requirements Analysis - Steven Bleistein Computer (Correct)
No context found.
B. Nuseibeh and S. M. Easterbrook, "Requirements Engineering: a Roadmap," presented at Proceedings of the International Conference on Software Engineering (ICSE 2000.
Strategy-Oriented Alignment in Requirements Engineering.. - Bleistein, al. (2004) (Correct)
No context found.
NUSEIBEH, B. and EASTERBROOK, S. M. (2000): Requirements engineering: a roadmap. Proceedings of the International Conference on Software Engineering (ICSE 2000). Limerick, Ireland, ACM Press.
Original Article - Berry Daudjee Dong (Correct)
No context found.
Nuseibeh B, Easterbrook S (2000) Requirements engineering: a roadmap. In: Finkelstein A (ed) The future of software engineering. ACM, Limerick, Ireland
Strategy-Oriented Alignment in Requirements Engineering.. - Bleistein, al. (2004) (Correct)
No context found.
NUSEIBEH, B. and EASTERBROOK, S. M. (2000): Requirements engineering: a roadmap. Proceedings of the International Conference on Software Engineering (ICSE 2000). Limerick, Ireland, ACM Press.
Process Modeling in e-Business Systems Requirements Analysis - Steven Bleistein Computer (Correct)
No context found.
B. Nuseibeh and S. M. Easterbrook, "Requirements Engineering: a Roadmap," presented at Proceedings of the International Conference on Software Engineering (ICSE 2000.
Requirements Capture in Natural Language Problem - Li (Correct)
No context found.
Nuseibeh B. Easterbrook S. (2000) Requirements Engineering: A Roadmap.
Specifying Privacy Policies with P3P and EPAL: Lessons.. - Stufflebeam, Anton, He.. (Correct)
No context found.
B.A. Nuseibeh and S.M. Easterbrook. Requirements Engineering: A Roadmap, In A.C.W. Finkelstein (ed.) The Future of Software Engineering. (Companion Volume to the Proc. of the 22 nd International Conference on Software Engineering, ICSE'00). IEEE Computer Society Press, 2000.
Formal Analysis of Early Requirements Specifications - Fuxman (2001) (6 citations) (Correct)
No context found.
B. Nuseibeh and S. Easterbrook. Requirements Engineering: a roadmap. In ICSE - Future of SE Track, pages 35--46, 2000.
Information Modeling: the process and the - Required Competencies Of (2003) (Correct)
No context found.
Nuseibeh, B., Easterbrook, S.: Requirements engineering: a roadmap. In: 22nd International Conference on Software Engineering, Ireland, ACM (2000) 35--46
A Relation-based Approach to Use Case Analysis - Fantechi Gnesi Lami (Correct)
No context found.
B. A. Nuseibeh and S. M. Easterbrook, Requirements Engineering: A Roadmap, In A. C. W. Finkelstein (ed) "The Future of Software Engineering". (Companion volume to the proceedings of the 22nd International Conference on Software Engineering, ICSE'00). IEEE Computer Society Press.
Study on Management of Open Source Software Projects - Nair (2002) (Correct)
No context found.
Nuseibeh, R., Easterbrook, S., `Requirements engineering: a roadmap', ACM and IEEE Computer Society Press, 2000.
Defining Agents in a COTS-Aware Requirements Engineering Approach - Chung, Cooper (2002) (Correct)
No context found.
Nuseibeh, B. and Easterbrook, S., "Requirements engineering: a roadmap", in A. Finkelstein, editor, "The Future of Software Engineering", Special Volume published in conjunction with ICSE
Round-Trip Prototyping Based on Integrated Functional.. - Homrighausen, Six.. (2002) (Correct)
No context found.
Nuseibeh B, Easterbrook S. Requirements engineering: a roadmap. In ICSE-18, The future of software engineering, Limerick, Ireland, 2000, pp 35--46
Management View on Current Requirements Engineering.. - Nikula, Sajaniemi.. (2000) (Correct)
No context found.
Nuseibeh, Bashar and Steve Easterbrook (2000), Requirements Engineering: A Roadmap, in: Proceedings of the 22 International Conference on Software Engineering, New York: ACM, pp. 35-46.
Reconciling Software Requirements And Architectures.. - Grünbacher, Egyed.. (2003) (Correct)
No context found.
Nuseibeh B, Easterbrook S (2000) Requirements Engineering: A Roadmap. In: The Future of Software Engineering, Special Issue 22nd International Conference on Software Engineering, ACM-IEEE
The Role of Emotion, Values, and Beliefs in - The Construction Of (Correct)
No context found.
Nuseibeh, B., Easterbrook, S.: Requirements Engineering: A Roadmap. In: Finkelstein, A.: The Future of Software Engineering 2000. ACM, Limerick, Ireland (June 2000)
First 50 documents
Online articles have much greater impact More about CiteSeer.IST at NUS Add search form to your site Submit documents Feedback
CiteSeer.IST at NUS - Copyright Penn State and NEC. Hosted by the School of Computing, National University of Singapore.