By Topic

Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on

Date 9-13 Sept. 2002

Filter Results

Displaying Results 1 - 25 of 54
  • Proceedings IEEE Joint International Conference on Requirements Engineering

    Publication Year: 2002
    Save to Project icon | Request Permissions | PDF file iconPDF (322 KB)  
    Freely Available from IEEE
  • The impact of stakeholders' geographical distribution on managing requirements in a multi-site organization

    Publication Year: 2002 , Page(s): 319 - 328
    Cited by:  Papers (23)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (935 KB) |  | HTML iconHTML  

    The increasing globalization of software industry demands an investigation of requirements engineering (RE) in multisite software development organizations. Requirements engineering is a task difficult enough when done locally-but it is even more difficult when cross-functional stakeholder groups specify requirements across cultural, language and time zone boundaries. This paper reports on a field study that investigated RE challenges introduced by stakeholders' geographical distribution in a multi-site organization. The goal was to examine RE practice in global software development, to formulate recommendations for improvement as well as to provide directions for future research on methods and tools. Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact on requirements gathering, negotiation and specification. Findings reveal that aspects such as a lack of a common understanding of requirements, together with reduced awareness of working local context, trust level and ability to share work artifacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers. The paper concludes with recommendations for improving RE practice in this setting. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Author index

    Publication Year: 2002 , Page(s): 357 - 358
    Save to Project icon | Request Permissions | PDF file iconPDF (194 KB)  
    Freely Available from IEEE
  • Ambiguity and what to do about it [requirements engineering]

    Publication Year: 2002
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (194 KB)  

    A major concern of most software customers, managers, and requirements engineers is to remove ambiguity in communication of requirements and specifications. The most obvious solution is to try to anticipate all possible misunderstandings and write the requirements perfectly precisely. In practice, this does not work. This talk explains why it does not work, and offers easy, inexpensive methods for removing ambiguity - methods that anyone can do. The fundamental principle is to add redundancy, especially redundancy relating to context. High-bandwidth, informal communication is always a necessary supplement to formal, mathematical expressions. As software development is in essence the creation of formal, executable descriptions for the informal domains where our intents lie, we explore many ways to break up this process into small stages, allowing programmers and customers to detect ambiguity through real-world feedback. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Introducing requirements engineering: how to make a cultural change happen in practice

    Publication Year: 2002 , Page(s): 43 - 51
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (295 KB) |  | HTML iconHTML  

    Introducing requirements engineering appears to involve a cultural change in organizations. Such a cultural change requires that requirements are defined and managed systematically, not only from a technical point of view, but also from the customers' and users' points of view. This paper describes experiences gained from four Finnish organizations that have started to introduce requirements engineering to their product development. The goal of this study was to evaluate which factors support, and which prevent, a cultural change. Linking business goals to technical requirements via user needs and user requirements was one of the key improvement actions that supported cultural change. Eliciting needs directly front real users and representing user requirements in the form of use cases were also key activities. However, bringing about a change of culture was challenging because both managers and product development engineers held beliefs that prevented active user need elicitation and systematic user requirement documentation. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Visual requirements validation: case study in a CORBA-supported environment

    Publication Year: 2002 , Page(s): 81 - 88
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (314 KB) |  | HTML iconHTML  

    We present an approach to requirements validation in which the formal specification of the requirements is directly, interpreted and the results are visually, presented to the customer through a graphical user interface, relying on the customer to visually, validate the specified requirements. The communication between the user interface and the specification interpreter is accomplished through CORBA. The approach supports the cooperation of customers and developers in eliciting and validating the requirements. We present a case study of the application of the technique to the validation of a generic access control component. The use of CORBA has the advantage that any, CORBA-compliant language can be used for the user interface, independently of the implementation of the specification interpreter The contributions of the paper are 1) the presentation of a case stud), of the visual requirement validation technique, 2) the revision and improvement of a previously presented visual validation technique, and 3) the application of requirements validation to a reusable component. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Security requirements engineering: when anti-requirements hit the fan

    Publication Year: 2002 , Page(s): 203 - 205
    Cited by:  Papers (16)  |  Patents (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (297 KB) |  | HTML iconHTML  

    Everyone agrees that security is a problem, ranging from Microsoft to the banks that have been recent victims of rogue traders. What is paradoxical is that there does not seem to be a wholehearted commitment by both academics and industry to treat this topic systematically at the top level of requirements engineering. Our vision is of a future in which we inform the security requirements engineering process by organisational theory. This would act as the bridge between the well-ordered world of the software project informed by conventional requirements and the unexpected world of anti-requirements associated with the malicious user. We frame a vision for the requirements engineering community that would involve the community solving six difficult problems. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • On the use of visualization in formal requirements specification

    Publication Year: 2002 , Page(s): 71 - 80
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (569 KB) |  | HTML iconHTML  

    A limiting factor in the industrial acceptance of formal specifications is their readability, particularly for large, complex engineering systems. We hypothesize that multiple visualizations generated from a common model will improve the, requirements creation, reviewing and understanding, process. Visual representations, when effective, provide cognitive support by highlighting the most relevant interactions and aspects of a specification for a particular use. In this paper, we propose a taxonomy and some preliminary principles for designing visual representations of formal specifications. The taxonomy and principles are illustrated by sample visualizations we created while trying to understand a formal specification of the MD-11 flight management system. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Model based requirements engineering for embedded software

    Publication Year: 2002
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (263 KB)  

    Summary form only given. Software and systems development within the embedded area is dominated by model based design techniques. These techniques are commonly aligned to standard. modeling languages such as UML. Along with software and systems design techniques the concern of requirements management methodologies has been continuously increasing, with the aim of improving the overall development process. As a combination of both model based design techniques and requirements management methodologies, a new kind of requirements engineering methodology has been established. However, due to the complexity of this methodology and the high degree of informal aspects a unique and integrated methodology for requirements engineering is still needed. This presentation gives a survey of existing requirements classifications and motivates the use of model based requirements classification techniques. The transition of informal requirements to first models is illustrated. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A process model for distributed development of networked mechatronic components in motor vehicles

    Publication Year: 2002
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (231 KB) |  | HTML iconHTML  

    Increasing demands concerning safety, economic impact, fuel consumption and comfort result in growing utilization of mechatronic components and networking of up to now widely independent systems in vehicles. The development of such a complex and networked system requires a coordinated, systematic development process. In this contribution a suitable process model is presented. It supports the verification of a domain model considering functional requirements in an early stage of development. The process model takes two different types of modeling into account. Object oriented modeling is used to describe domain models and particularly supports aspects like re-use, exchangeability, scalability and distributed development. Data flow oriented modeling especially focuses on dynamic aspects and is employed to create a simulation model. Coupling points are identified allowing an automated mapping of these two types of models. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Risk management in challenging business software projects

    Publication Year: 2002 , Page(s): 8 - 10
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (206 KB) |  | HTML iconHTML  

    Today's business processes are dealing with sophisticated business-to-business relationships and elaborate software integrations in order to allow all application systems along the process chain to communicate and cooperate with each other. This makes business software projects increasingly complex and creates risks ranging from overspending to project failure. During the last few years several methodologies have emerged that help to reduce or even eliminate dangerous risk factors in business software projects. However, applying those methodologies to modern and complex e-business software projects is becoming more and more difficult, if not impossible. In most cases only suboptimal solutions are created. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Supporting requirements verification using XSLT

    Publication Year: 2002 , Page(s): 165 - 172
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (515 KB) |  | HTML iconHTML  

    We present a light-weight approach for the automatic verification of requirements. This approach is not based on natural language parsing techniques but on the representation of requirements in XML. In our approach, XSLT stylesheets are used not only to automatically generate requirements documents, but also to provide verification-oriented heuristics as well as to measure the quality of requirements using some verification-oriented metrics. These ideas have been implemented in REM, an experimental XML-based requirements management tool also described. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An analysis-revision cycle to evolve requirements specifications by using the SCTL-MUS methodology

    Publication Year: 2002 , Page(s): 282 - 288
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (321 KB) |  | HTML iconHTML  

    The development of requirements specifications can be supported by a cycle composed of two phases: analysis and revision. We use the SCTL-MUS methodology to bridge the gap between these two phases. The analysis phase provides diagnostic information if a desirable property is not satisfied by the current system specification. A crucial aspect of the analysis-revision cycle is how to use the diagnostic information provided to generate alternative system refinements which can be included in the system specification to satisfy the property in question (revision phase). Our approach allows translating the diagnostic information into system requirements refinements closed to the system domain. It facilitates to the stakeholders the decision of what system requirements refinements must be included in the system requirements specification. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using maturity assessments to understand the ERP requirements engineering process

    Publication Year: 2002 , Page(s): 255 - 262
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (382 KB) |  | HTML iconHTML  

    Applying standard requirements engineering (RE) processes is a major trend in today's enterprise resource planning (ERP) software engineering. It emerged five years ago with the promise to provide a mechanism helping ERP project organizations deliver their business requirements timely and within budget. This paper looks in depth at a standard ERP RE process and seeks answers to four questions: how well it is defined, what are the risks associated with its application in mature/immature organizations, what are the essential practices that contribute to its success, and what are the costs of the process and the quality of the delivered results. The main motivation of this paper is to provide some practical advice for using assessments to increase project teams' understanding of the ERP RE process. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Tool-based risk management made practical

    Publication Year: 2002
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (284 KB) |  | HTML iconHTML  

    Risk management has become one of the buzz words in the IT industry. The reasons can especially be found in the current economic crisis. While risk management is highly accepted in safety-critical industries (aerospace, healthcare), more and more branches (Web agencies, e-commerce, software in general) see the value of establishing risk management processes. As risk management seems to be clear from a theoretical point of view, it is not from a practical standpoint. This is the challenge for project leaders in real life projects. This one-page abstract summarizes the main aspects of the industrial presentation held at Requirements Engineering 2002 (RE02) in Essen/Germany. The complete presentation deals with how risk management can be grounded as an integral part of a requirements management process. A full paper (German and English) describing this approach is available from the author by email. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements management in a product line scenario

    Publication Year: 2002
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (236 KB)  

    Summary form only given. The product line approach is a major reuse concept that has shown concrete commercial results over the past years. Product lines achieve reuse in the functionality and solution space, and thus improve quality, cycle time and cost. They are specifically promising in cases where many variants are produced almost simultaneously, such as in telecommunication systems. Though appealing, the concept is difficult to introduce specifically into an existing development environment. All too often the impacts on requirements management are not considered globally enough. The opposite of a product line concept is to allow every variant of a product to implement its own requirements only loosely coupled to the base product. This article describes the introduction of a product line approach in Alcatel's S12 Switching System Business Unit. Success factors are described related to the interface with marketing, requirements definition, roadmapping and portfolio management, requirements reuse, planning and prioritization incremental development, and configuration management are explained. Practical impacts are described as well as tricks and traps. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Multi-faceted requirements modeling

    Publication Year: 2002 , Page(s): 112 - 119
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (290 KB) |  | HTML iconHTML  

    Modern systems engineering mandates the integration of heterogeneous models in systems design and analysis. Analysis of modern, mixed technology systems requires the horizontal integration of heterogeneous models for predictive analysis. The ever increasing role of performance constraints such as power, cost and throughput requires vertical integration of heterogeneous component models describing different requirements facets. The Rosetta (Alexander et al., 2000; 2001) specification language has been developed to address the issue of specification and analysis of heterogeneous models. We describe the semantics of Rosetta's specification composition in the context of systems level requirements modeling. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements patterns for embedded systems

    Publication Year: 2002 , Page(s): 127 - 136
    Cited by:  Papers (24)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (323 KB) |  | HTML iconHTML  

    In software engineering, design patterns propose solution skeletons for common design problems. The solution skeleton is described in such a way that the design can be used for other projects, where each application tailors the design to specific project constraints. This paper describes research into investigating how a similar approach to reuse can be applied to requirements specifications, which we term requirements patterns. Specifically, the paper explores how object-oriented modeling notations, such as the Unified Modeling Language (UML), can be used to represent common requirements patterns. Structural and behavioral information are captured as part of a requirements pattern. In order to maximise reuse, we focus on requirements patterns for embedded systems. This paper also describes case studies that illustrate how we have applied these general patterns to multiple embedded systems applications from the automotive industry. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Validating functional system requirements with scenarios

    Publication Year: 2002 , Page(s): 181 - 188
    Cited by:  Papers (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (344 KB) |  | HTML iconHTML  

    This paper addresses the problem of requirements engineering for complex socio-technical systems where an optimal set of technology components and human operators have to be selected to achieve system goals. Goals are achieved by tasks that are expressed as operational scenarios with variations in environmental conditions. The approach taken is to develop a probabilistic model of system reliability as a Bayesian Belief Network (BBN). The BBN model predicts human and machine reliabilities, given input variables representing the scenario and ranges of environmental conditions (i.e. weather, climate, etc.). A software tool, the System Reliability Analyser (SRA) is described that runs a set of scenarios against the BBN models while systematically varying the ranges of 12 input variables specifying properties of human operators such as training, technical equipment specification and environmental conditions. The tool reports human and technical equipment specifications that "survive" the scenario testing at a reliability level higher than a user-defined level. A case study evaluation of the tool is reported using a naval command and control domain, in which different combinations of human roles and equipment requirements specifications are automatically validated against a set of scenarios describing missile attacks on a navy frigate. The implication of using BBN technology and the SRA tool for automating socio-technical system requirements validation and optimising requirements selection in component-based systems is discussed. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Managing (requirements) evolutions of high assurance systems

    Publication Year: 2002
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (193 KB) |  | HTML iconHTML  

    Summary form only given. Long lifetime high assurance systems (HAS) present, among others, a peculiar property: evolutions are numerous. Because current standards for producing such HAS are not accurate enough regarding evolutions, we have considered that all the artefacts, which are produced during their development, should be recorded. Recording artefacts means developing an IS. By applying well-known IS principles supported by a relational database, we have considered their models, and then their exploitation. For the modelling part we have taken into account all the artefacts and their relationships, according to accurate representative UML abstract diagrams. Indeed, UML allows representing both static and dynamic aspects of any system. Because evolution management is the most difficult part of the HAS lifetime, we emphasise modelling requirements and evolutions. We show how these abstract UML meta-models and their instantiations can be used in two different ways: we have built up a Web database, which takes advantage of existing browsers, and, because recording all the artefacts is cumbersome, we have translated the abstract metamodels into a set of verification rules that allow manual checking of HAS properties such as release compatibility. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Efficient and systematic software evolution through domain analysis

    Publication Year: 2002 , Page(s): 237 - 244
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (325 KB) |  | HTML iconHTML  

    The goal of any domain analysis approach is to identify and document requirements on a set of systems in the same application domain in order to make development and maintenance activities more efficient. Experience in domain analysis often reports on valuable results with respect to requirements on a company's system family but, on the other hand, it is seen as an effort-intensive approach, which may consequently be seen as not economically useful for software development today. We describe experience with an approach towards domain analysis that tries to overcome this general problem by systematically coordinating domain analysis effort and necessary product (family) evolution activities. The result was the realization of a Web interface to an existing system family as well as a significant improvement of the existing software's usability, flexibility, and maintainability. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Integrating ECUs in vehicles - requirements engineering in series development

    Publication Year: 2002 , Page(s): 227 - 236
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (322 KB) |  | HTML iconHTML  

    This paper describes the research concepts and methodological aspects of a joint project of Fraunhofer ISST and BMWAG for an improvement of recording and management of requirements in the series development for the automotive sector. In a project, normally more than one car variant is developed. Using this approach requirement recording can be done on the project level as well as on a lower level, e.g. the level of a single car variant. To support an intensive reuse of requirement models the domain engineering approach is adapted to requirements engineering in that application domain. The methodology supports the recording of requirements on the project level or lower and the reuse of established requirement structures of the domain for a new application and it shows a way of how requirement structures of an application can be made available for further reuse in the domain. In addition, different consistency checks are supported. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements engineering in automotive development-experiences and challenges

    Publication Year: 2002 , Page(s): 331 - 340
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (368 KB) |  | HTML iconHTML  

    This paper summarizes problems, solutions and challenges of requirements engineering gained from the development of software-based automotive systems at DaimlerChrysler. The technical domains covered include telematics and entertainment, body electronics and chassis control for both passenger cars and commercial vehicles. Experiences include domain-specific issues, which are related to the different content of requirements in particular application areas and its specific notations, techniques, or process steps, as well as domain-independent issues which are largely independent from requirements content and related to the administration and management of requirements. We argue that the issues presented here, while not necessarily being in the current focus of the requirements engineering research area, are of crucial importance for improving requirements engineering in the development of software for automotive systems, and very likely, to many other kinds of systems as well. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Deriving use cases from organizational modeling

    Publication Year: 2002 , Page(s): 32 - 39
    Cited by:  Papers (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (569 KB) |  | HTML iconHTML  

    Use cases diagrams in the Unified Modeling Language (UML) have been used for capturing system functional requirements. However, the system development occurs in a context where organizational processes are well established Therefore, we need to capture organizational requirements to define how the system fulfils the organization goals, why it is necessary, what are the possible alternatives, etc. Unfortunately, UML is ill equipped for modeling organizational requirements. We need other techniques, such as i*, to represent these aspects. Nevertheless, organizational requirements must be related to functional requirements represented as Use Cases. In this paper we present some guidelines to assist requirement engineers in the development of Use Cases from the i* organizational models. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Analyzing Website privacy requirements using a privacy goal taxonomy

    Publication Year: 2002 , Page(s): 23 - 31
    Cited by:  Papers (15)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (480 KB) |  | HTML iconHTML  

    Privacy has recently become a prominent issue in the context of electronic commerce websites. Increasingly, Privacy policies posted on such websites are receiving considerable attention from the government and consumers. We have used goal-mining, to extract pre-requirements goals from post-requirements text artifacts, as a technique for analyzing privacy policies. The identified goals are useful for analyzing implicit internal conflicts within privacy policies and conflicts with the corresponding websites and their manner of operation. These goals can be used to reconstruct the implicit requirements met by the privacy policies. This paper interrelates privacy policy and requirements for websites; it introduces a privacy goal taxonomy and reports the analysis of 23 Internet privacy policies for companies in three health care industries: pharmaceutical, health insurance and online drugstores. The evaluated taxonomy provides a valuable framework for requirements engineering practitioners, policy makers and regulatory bodies, and also benefits website users. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.