By Topic

Requirements Engineering, 2000. Proceedings. 4th International Conference on

Date 19-23 June 2000

Filter Results

Displaying Results 1 - 25 of 35
  • Proceedings Fourth International Conference on Requirements Engineering. ICRE 2000. (Cat. No.98TB100219)

    Save to Project icon | Request Permissions | PDF file iconPDF (204 KB)  
    Freely Available from IEEE
  • Requirements-related risks in critical systems

    Page(s): 3
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (65 KB)  

    Summary form only given, as follows. This talk considers some of the roles that requirements engineering plays in computer system development, with particular emphasis on systems with critical requirements such as security, reliability, safety, and survivability. The RISKS archives are littered with cases attributable to requirements problems that propagate throughout development, from which many lessons need to be learned. Various possible remedies are discussed. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Z specifications meet Mathematica for exploratory prototyping

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (62 KB)  

    In order for formal methods to achieve widespread acceptance, associated tools must become more accessible to the average user. This work describes ZEM (Z Embedded in Mathematica), a new tool supporting the major phases of the requirements analysis life cycle. ZEM is best described as an animator for Z specifications with a theorem proving component. The overall goal in its design has been twofold: (1) to encourage the use of formal methods by a wider group of practitioners and (2) to provide an environment that facilitates exploratory prototyping. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Why is it so difficult to introduce requirements engineering research results into mainstream requirements engineering practice?

    Page(s): 67 - 68
    Save to Project icon | Request Permissions | PDF file iconPDF (68 KB)  
    Freely Available from IEEE
  • Why is it so easy to introduce requirements engineering technology transfer panels into mainstream practice?

    Page(s): 69 - 70
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (165 KB)  

    This position paper has summarized conclusions reached by prior panels and has suggested moving on. One suggested focus is attention to the network of research dependencies that must be in place for us to succeed. A second focus is the need for a close working relationship between business and systems concerns. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Transferring research results in requirements to practice: obstacles and incentives

    Page(s): 71 - 72
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (48 KB)  

    Described here are three obstacles to more widespread use of formal techniques in software development and three significant benefits that result from using formal techniques to describe and analyze requirements. Major obstacles to the adoption of formal techniques in practical software development are 1) the lack of standard languages for specifying systemand software requirements, 2) the lack of a development environment into which formal techniques can be integrated, and 3) a negative view of formal methods among software developers. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Is there a gap between RE research and RE practice ?

    Page(s): 73 - 74
    Save to Project icon | Request Permissions | PDF file iconPDF (70 KB)  
    Freely Available from IEEE
  • What do you mean I've been practicing without a license? Certification & licensing of requirements engineering professionals

    Page(s): 151
    Save to Project icon | Request Permissions | PDF file iconPDF (11 KB)  
    Freely Available from IEEE
  • What do you mean I'm practicing without a license? certification and licensing of requirements engineering professionals

    Page(s): 152
    Save to Project icon | Request Permissions | PDF file iconPDF (50 KB)  
    Freely Available from IEEE
  • Certitude and rectitude

    Page(s): 153
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (61 KB)  

    There is a fundamental difference between certification (which is intended to give you the feeling that someone or something is doing the right thing) and correctness (for which you hopefully have some well-founded reason to believe that someone or something is doing the right thing - with respect to appropriate definitions of what is right). Certification is typically nowhere near enough; correctness is somewhat closer to what is needed, although often unattainable in the large - that is, with respect to the entire system. However, formal demonstrations that something is correct are potentially much more valuable than loosely based certification. So, a challenge confronting us here is to endow certification - of people and of systems - with a greater sense of rigor and credibility. Overall, we urgently need to explore alternatives within the context of the entire process of development, maintenance, and continued evolution. Although lowest-common-denominator certification of conventional programmers and simplistic metrics for judging organizational competence are likely to be palliatives at best, sensible procedures for certifying requirements engineers, system engineers, software engineers, debuggers, etc., could be just one of many potentially useful steps toward instilling greater discipline into the development process - particularly for critical systems. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Two positions on licensing

    Page(s): 154 - 155
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (510 KB)  

    First Page of the Article
    View full abstract»

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

    Page(s): 197
    Save to Project icon | Request Permissions | PDF file iconPDF (42 KB)  
    Freely Available from IEEE
  • On the challenges of business modeling in large-scale reengineering projects

    Page(s): 17 - 26
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (312 KB)  

    Modeling existing and future business processes is crucial to the outcome of large-scale reengineering projects. The use of parameterized or standard components does not render business models redundant, but shifts the modeling focus even more from technical aspects to the real-world business processes. In current reengineering projects, however, there is often a lack of coordination of modeling activities and the consistency of conceptual models across project activities can be threatened. There are often several models of the same phenomenon that are used by different people, in different phases, or for different purposes. This paper discusses some of the challenges of business modeling and presents a three-tier model description that explains some of the model variants found in reengineering projects. The findings from a large-scale SAP project in Europe underline the importance of a balanced business model and show how individually tailored conceptual models may hamper the formation of a common understanding of the domain and badly affect the reengineering of the business processes View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Patterns and aspects for use cases: reuse techniques for use case descriptions

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (144 KB)  

    We discuss two types of reusable components for use case descriptions; use case patterns (templates) and aspect patterns. We investigate which parts of use case descriptions can be catalogued as reusable patterns and templates for requirements analysis processes: 1) use case templates for describing use cases; 2) use case patterns for providing the reusable and changeable structures of use cases; 3) use case frameworks that are the large-scale combinations of use case patterns for application domains; and 4) aspect patterns for weaving non-functional requirements with functional requirements. We describe functional requirements separating from nonfunctional requirements and after specifying them both, we weave them together into a final requirements specification written with use cases View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Full text access may be available. Click article title to sign in or learn about subscription options.
  • Scenario evolution: a closer view on relationships

    Page(s): 95 - 105
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (264 KB)  

    We show the results of an extensive research on scenario evolution. We investigated twelve case studies spanning over 200 scenarios that contained over 800 episodes. The research aimed at capturing data on scenario evolution in order to confirm previous results and to elicitate the requirements for a scenario evolution support environment. Our findings are organised in a three tier framework, that deals with scenario evolution in the process, product and instance levels. We concentrate on the product and instance levels showing scenario relationships. Scenarios do not exist in a vacuum, they are connected to other scenarios in an intricate and complex network of relationships. We provide a taxonomy for classification and heuristics for the identification of scenario relationships View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Full text access may be available. Click article title to sign in or learn about subscription options.
  • Scalable mechanisms for requirements interaction management

    Page(s): 119 - 129
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (552 KB)  

    Capturing requirements, and managing tradeoffs among them, are critical yet complex activities. Well-designed computerized tools can effectively support these activities. A key challenge in construction of these support tools is how to scale them to handle a large volume of information. Particularly crucial are the ways in which large numbers of requirements and their interrelationships are presented to users. They need to be able to zoom in and out through the space of information so as to be able to see the big picture, and to locate and focus on specific details when needed. This paper describes a harmonious combination of techniques that support such scalability. The techniques have been embodied in a NASA tool, DDP, for defect detection and prevention. They have been exercised in uses of this tool for requirements/risk tradeoffs, and the use of this tool to capture institutional knowledge-bases of information View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A framework for multi-notation requirements specification and analysis

    Page(s): 39 - 48
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (244 KB)  

    Many organizations desire the convenience of using multiple notations within a requirements specification. Rather than using separate tools for each notation, we advocate combining the parts semantically for tool-based analysis. We describe a framework for integrating notations from four distinct categories, namely “models”, “events”, “actions, and “expressions”. The categories allow us to view the notations independently but in a manner whereby they can be combined to create a specification. The categories are implemented as types in higher-order logic. Typechecking ensures conformance to the rules for combining notations. Our choice of higher-order logic as a base formalism allows the framework to support notations with uninterpreted constants. With our framework, it is possible to use new combinations of notations without changing existing notations or rebuilding formal analysis tools such as model checkers View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Establishing reuse measurement practices in SAP requirements engineering

    Page(s): 168 - 177
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (248 KB)  

    The paper reports on first attempts to define, apply and fully integrate some reuse measurement practices into the SAP requirements engineering activities. It addresses all the facets of the context for SAP requirements reuse measurement and indicates who reuse metrics data are collected for, where and when during the RE process reuse measurements are made, what counting standards are appropriate, and what action items can be taken based on the reuse measurements View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Enhancing requirements and change management through process modelling and measurement

    Page(s): 106 - 115
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (376 KB)  

    We present a methodology that aims at improving the effectiveness of requirements management in software development and maintenance. In particular, we address quantitative assessment of the impact of requirements changes, and quantitative estimation of costs of the development activities that must be carried out to accomplish those changes. Our approach is based on enhanced traceability and process measurement. Traceability relations are derived from an integrated view of the process and product models adopted within the software development organization. Hence, traceability spans over all the software life cycle and its products. Moreover, through proper measurement, the elements in the process and product models are quantitatively characterised, thus achieving a sound basis for different kinds of sophisticated analysis concerning the impact of requirements changes, their cost over the development process, and the sensitivity of the product to changes View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Essential and incidental complexity in requirements models

    Page(s): 130 - 139
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (376 KB)  

    A deep understanding of the complexity of the requirements model and its dynamics is critical in improving requirements engineering process management. Findings from an action research study an insightful explanation of how the complexity of the requirements model evolves over time. We argue that there are two different types of complexity of the model: the essential and incidental complexities. The essential complexity represents the inherent understanding of the problem space while the incidental complexity arises from the poor fit between the structure of the model and the structure of the world which the model aims to represent. We present a pattern for the dynamics of changes in the complexity of the requirements model. The evolution of the requirements model involves both the growth of the essential complexity throughout the discovery of the problem space and the growth and shrinkage of the incidental complexity, as the model undergoes a large number of changes. The new understanding of the complexity of the requirements model and its dynamics draws new directions for future research and forms a basis for a new approach to process management View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A lightweight approach to consistency of scenarios and class models

    Page(s): 49 - 58
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (176 KB)  

    Today, object-oriented requirements specifications typically combine a scenario (or use case) model and a class model for expressing functional requirements. With any such combination, the problem of consistency between these two models arises. We present a lightweight approach to consistency between a scenario model and a class model. We assume semi-formal, loosely coupled models that are complementary: scenarios model the external system behavior; the class model specifies the internal, state-dependent functionality, that cannot be expressed easily in a scenario (but is required to specify external behavior properly). We achieve consistency by minimizing overlap between the two models and by systematically cross-referencing corresponding information. We give a set of rules that can be used both for developing a consistent specification and for checking the consistency of a completed specification. Some rules can be checked automatically, the others are rules for manual inspection View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A process framework for requirements analysis and specification

    Page(s): 27 - 35
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (280 KB)  

    This paper presents a new approach for linking requirements engineering activities into a process framework that can be used as a reference for driving concrete requirements engineering processes. Special emphasis is placed on constructing problem domain models in order to build a common understanding of the problem context, to situate user requirements with reference to it, and as a technique for user requirements refinement. Another aspect highlighted by the process framework is the separation of the elicitation, analysis and refinement of user requirements from the construction of a system or software specification. Although the emphasis is placed on the process and the activities to be performed, the paper describes specific techniques that have been used successfully. The process framework is supported by a tool and has been tested in several projects from different organizations. This paper describes these experiences, draws conclusions and highlights future issues View full abstract»

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