By Topic

Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on

Date 27-31 Aug. 2001

Filter Results

Displaying Results 1 - 25 of 70
  • Proceedings Fifth IEEE International Symposium on Requirements Engineering

    Publication Year: 2001
    Save to Project icon | Request Permissions | PDF file iconPDF (284 KB)  
    Freely Available from IEEE
  • Where are we on the "fend off the alligators - drain the swamp" continuum?

    Publication Year: 2001 , Page(s): 266
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (88 KB)  

    Summary form only given, as follows. Over the past ten years, we have seen many useful developments in software specification tools, languages, processes, and practices as well as the creation of a number of excellent requirements management tools. Numerous books and articles have been produced on requirements elicitation and development. We have leamed to explicitly specify complex synchronous and asynchronous processes using Petri nets, state diagrams, and structured decision tables. We are exploring the use of fuzzy logic and imprecise probabilities to improve our management of uncertainty in the design process. But, WAIT JUST A MINUTE! Where is the industry with respect to all of this? In spite of this dramatic progress, are there remaining holes and/or opportunities in our practice of Requirements Engineering? We find the industry to be all over the map as the answer to the former and an emphatic YES as an answer to the latter. We take a friendly look at the industry in terms of 1) requirements practices already in place - from none to some to plenty, 2) what the industry means by "requirements," and 3) what companies say to their stockholders and customers versus what their end products reflect. We will suggest a few simple ideas for enhancing the value of requirements over the full life cycle of the product. We will propose a more moderate strategy for realizing, in a practical way, greater opportunity through requirements engineering. We feel that, with modest but consistent effort, we can experience relatively large benefits. We suggest charming the alligators. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • What happens with good requirements practices

    Publication Year: 2001 , Page(s): 268
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (45 KB)  

    Summary form only given, as follows. We??ve heard of the problems with bad requirements. We all have horror stories about the things that go wrong, the cost overruns, the schedule slips, the lost opportunities. What happens when you do it right. Some companies and government organizations are making requirement process changes and seeing some wonderful results. We will look at what has been done and what has resulted from several real programs. We??ll talk about the things that have worked best, things that did not get the expected results and things that have yet to be tried. View full abstract»

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

    Publication Year: 2001 , Page(s): 275
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (56 KB)  

    Summary form only given, as follows. Requirements have always been acknowledged as the backbone of any system. However, in many past development efforts, requirements were paid little heed. At NASA, in recent years, the hue and cry for project development has been "Faster, Better, Cheaper and Safer." This has impacted the way we develop software; it has increased the risks to quality, safety and reliability. At NASA, the Software Assurance Technology Center (SATC) is working with projects to emphasize the criticality of requirements throughout development, not just in the initial phases. This emphasis is on requirements relationship to all aspects of quality, including reliability and safety. In this presentation, we will look at some of these relationships through the eyes of quality. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Systems engineering at the enterprise level

    Publication Year: 2001 , Page(s): 276
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (80 KB)  

    Summary form only given, as follows. The principles of systems and software engineering can be re-applied beyond the range of the individual project. Traditional enterprise-wide tasks such as technology management, decision-making, organizational objectives, reuse, innovation and outsourcing are amenable to systems engineering. Examples of all of these areas will be presented. The rewards from a disciplined approach are clearly higher when applied at this level. Indeed some aspects (such as re-use) are only possible across projects. The problem of introducing this change is primarily cultural, because of the wide range of skills (including non-technical areas) involved in this coordination. Moreover the time-scales and commitment needed are higher than for individual projects. Shaping systems processes around traditional tasks and terminology helps convince management of the need for system engineering. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Discovering unanticipated software output modes

    Publication Year: 2001 , Page(s): 277
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (68 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

    Publication Year: 2001 , Page(s): 320 - 321
    Save to Project icon | Request Permissions | PDF file iconPDF (84 KB)  
    Freely Available from IEEE
  • A unified approach to systems and software requirements

    Publication Year: 2001 , Page(s): 267
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (64 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.
  • Evolving beyond requirements creep: a risk-based evolutionary prototyping model

    Publication Year: 2001 , Page(s): 94 - 101
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (736 KB) |  | HTML iconHTML  

    Evolutionary prototyping focuses on gathering a correct and consistent set of requirements. The process lends particular strength to building quality software by means of the ongoing clarification of existing requirements and the discovery of previously missing or unknown requirements. Traditionally, the iterative reexamination of a systems requirements has not been the panacea that practitioners sought, due to the predisposition for requirements creep and the difficulty in managing it. The paper proposes the combination of evolutionary prototyping and an aggressive risk mitigation strategy. Together, these techniques support successful requirements discovery and clarification, and they guard against the negative effects of requirements creep. We embody these techniques in a comprehensive software development model, which we call the EPRAM (Evolutionary Prototyping with Risk Analysis and Mitigation) model. The model was intentionally designed to comply with the Level 2 Key Process Area of the Software Engineering Institute's Capability Maturity Model. Validation is currently underway on several software development efforts that employ the model to support the rapid development of electronic commerce applications View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Integrating informal and formal approaches to requirements modeling and analysis

    Publication Year: 2001 , Page(s): 294 - 295
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (176 KB) |  | HTML iconHTML  

    The Unified Modeling Language (UML) comprises several different notations for object-oriented modeling with no formal semantics attached to the individual diagrams. We have developed a generic framework for formalizing a subset of UML diagrams in terms of various formal languages, with a focus on embedded systems. We have formalized UML in terms of Promela, thus enabling analysis of the UML diagrams by the SPIN model checker and simulator. We have also developed a number of visualizations to assist in the interpretation of the analysis results. This paper presents a case study of the UML design and automated analysis of an industrial automotive embedded system using our formalization techniques, supporting tools and existing analysis View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Extending the product family approach to support n-dimensional and hierarchical product lines

    Publication Year: 2001 , Page(s): 56 - 64
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (760 KB) |  | HTML iconHTML  

    The software product-line approach (for software product families) is one of the success stories of software reuse. When applied, it can result in cost savings and increases in productivity. In addition, in safety-critical systems the approach has the potential for reuse of analysis and testing results, which can lead to safer systems. Nevertheless, there are times when it seems like a product family approach should work when, in fact, there are difficulties in properly defining the boundaries of the product family. The authors draw on their experiences in applying the software product-line approach to a family of mobile robots as well as case studies done by others to: (1) illustrate how domain structure can currently limit applicability of product-line approaches to certain domains, and (2) demonstrate our initial progress towards a solution using a set-theoretic approach to reason about domains of what we call n-dimensional and hierarchical product families View full abstract»

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

    Publication Year: 2001 , Page(s): 269
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (37 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.
  • Evolving system architecture to meet changing business goals: an agent and goal-oriented approach

    Publication Year: 2001 , Page(s): 316 - 317
    Cited by:  Papers (8)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (192 KB) |  | HTML iconHTML  

    Today's requirements engineering approaches focus on notation and techniques for modeling the intended functionality and qualities of a software system. Little attention has been given to systematically understanding and modeling the relationships between business goals and system qualities, and how these goals are met during architectural design. In particular, modeling must encompass changes to business goals over time and their effects upon a system's architecture. This paper reports on a case study, performed at a telecommunication company, that illustrates the decision-making process regarding architectural changes introduced into an existing switching system product. A notation including goals, strategic agents and intentional dependency relationships is used to support the architectural modeling and reasoning View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Matching ERP system functionality to customer requirements

    Publication Year: 2001 , Page(s): 66 - 75
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (848 KB) |  | HTML iconHTML  

    Although procuring enterprise resource planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. The authors propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates a set of requirements that are worth eliciting from the ERP documentation as abstractions of the ERP system functionality. Then, the requirements engineering process is a process that matches the ERP set of requirements against organisational requirements. Those requirements that match, perhaps after adaptation, identify the ERP system features and their adaptations, that must be included in the ERP installation. To facilitate the matching process, the ERP requirements and the organisational requirements are both expressed using the same representation system, that of a map. The paper presents the map representation system and the matching process. The process is illustrated by considering the Treasury module of SAP and its installation in the financial management of a cultural exchanges unit View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Adoption of requirements engineering: conditions for success

    Publication Year: 2001 , Page(s): 270
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (51 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.
  • Discovering unanticipated software output modes

    Publication Year: 2001 , Page(s): 277
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (48 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.
  • Domain independent regularities in scenarios

    Publication Year: 2001 , Page(s): 120 - 127
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (616 KB) |  | HTML iconHTML  

    Scenario is a description technique which has attracted much attention not only from practitioners but also from researchers. Literature on this topic shows the possibilities that this description technique provides to enhance the understanding of task-related descriptions and the communication among stakeholders. On the other hand, the idea of pattern, as a description of a problem which occurs over and over again in our environment and its solution, has also attracted lots of attention, especially in software design. The paper describes an initial taxonomy of domain-independent-scenario patterns and proposes a preliminary process to use this taxonomy for scenario construction View full abstract»

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

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

    Beginning in the late 1980s, a small cohort of anthropologists and computer scientists at Xerox Palo Alto Research Center developed an interdisciplinary research programme concerned with the design and use of information technologies. Our projects over the years joined ethnographies of work and technologies-in-use with design interventions. This paper briefly reviews this program of research, illustrated with specific examples. Our ethnographic approach is exemplified in an early research project on information and communications technologies-in-use within a particular workplace. This project led, among other things, to a reconceptualization of what makes up an "information system" that informed all of our subsequent work. The latter turned increasingly to interventions aimed at exploring what I characterize as practice-based design, combining elements of workplace ethnography and cooperative prototyping. These efforts are illustrated by a collaborative research and development project involving the transformation of a particular collection of documents - the project files of a civil engineering team engaged in designing a bridge - from paper to digital media View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An algorithm for strengthening state invariants generated from requirements specifications

    Publication Year: 2001 , Page(s): 182 - 191
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (872 KB) |  | HTML iconHTML  

    In earlier work (Jeffords and Heitmeyer, 1998) we developed a fixpoint algorithm for automatically generating state invariants, properties that hold in each reachable state of a state machine model, from state-based requirements specifications. Such invariants are useful both in validating requirements specifications and as auxiliary lemmas in proofs that a requirements specification satisfies other invariant properties. This paper describes a new related algorithm that strengthens state invariants generated by our initial algorithm and demonstrates the new algorithm on a simplified version of an automobile cruise control system. The paper concludes by describing how the two algorithms were used to generate state invariants from a requirements specification of a cryptographic device and how the invariants in conjunction with a theorem prover were used to prove formally that the device satisfies a set of critical security properties View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Product-line requirements specification (PRS): an approach and case study

    Publication Year: 2001 , Page(s): 48 - 55
    Cited by:  Papers (8)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (720 KB) |  | HTML iconHTML  

    Software product-line engineering can provide significant gains in quality and productivity through systematic reuse of software's conceptual structures. For embedded safety- or mission-critical systems, much of the development effort goes into understanding, specifying, and validating the requirements. If developers can reuse rather than re-do requirements for families of similar systems, we can improve productivity while significantly reducing the opportunity for requirements errors. The paper describes a systematic approach to developing a Product-line Requirements Specification (PRS) for such systems. The PRS explicitly represents the family's common requirements as well as the allowed variations that distinguish family members. When completed, the PRS definition also supports generation of well-formed software requirements specifications (SRS) for members of the product line. We describe a process for developing a PRS starting from an analysis of a program family's commonalities and variabilities. The approach is illustrated with examples from a case study of a real family of systems, the Rockwell Collins Commercial Flight Control System product-line View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Scenario-based systems architecting

    Publication Year: 2001 , Page(s): 318 - 319
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (136 KB) |  | HTML iconHTML  

    We sketch work-in-progress in the area of systems architecting, which we regard as a fundamental element of system-level requirements engineering. We present our ideas on systems architecting, and relate them to the field of Architecture proper (as in buildings). We present our notion of system-wide scenarios and how these can be derived from contextual analysis of information systems, using a well-established qualitative data analysis methodology from the social sciences View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Extreme re: what if there is no time for requirements engineering?

    Publication Year: 2001 , Page(s): 282 - 284
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (168 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.
  • Software acquisition: a business strategy analysis

    Publication Year: 2001 , Page(s): 76 - 83
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (656 KB) |  | HTML iconHTML  

    The paper argues that there are new insights to be gained from a strategic analysis of requirements engineering. The paper is motivated by a simple question: what does it take to be a world class software acquirer? The question has relevance for requirements engineers because for many organisations market pressures mean that software is commonly acquired rather than developed from scratch. The paper builds on the work of C. H. Fine (1998) who suggests that product, process and supply chain should be designed together, i.e., 3D concurrent engineering. Using a number of reference theories, it proposes a systematic way of carrying out 3D concurrent engineering. The paper concludes that the critical activity in supply chain design is the design of the distribution of skills and the nature of contracts View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Reconciling software requirements and architectures: the CBSP approach

    Publication Year: 2001 , Page(s): 202 - 211
    Cited by:  Papers (14)  |  Patents (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (928 KB) |  | HTML iconHTML  

    Little guidance and few methods are available to refine a set of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures leverage different terms and concepts to capture the artifacts relevant to each. We present CBSP (Component-Bus-System- Property), a lightweight approach intended to provide a systematic way of reconciling requirements and architectures. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast the requirements in a way that facilitates their straightforward mapping to architectures. Furthermore, the approach allows us to capture and maintain arbitrarily complex relationships between requirements and architectural artifacts, as well as across different CBSP artifacts. We have extensively applied CBSP within the context of particular requirements and architecture definition techniques, EasyWinWin and C2. We leverage that experience to demonstrate the CBSP method and tool support using a large-scale example that highlights the transition from an EasyWinWin requirements negotiation into a C2-style architectural model View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Empowering requirements for a product family

    Publication Year: 2001 , Page(s): 302 - 303
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (152 KB) |  | HTML iconHTML  

    Document-based management of requirements can be effective for single-site, narrowly-scoped projects. However, we firmly believe that it is essential to move to a database-centred way of managing requirements if platform-based product development and enterprise-wide requirements management is to be fully supported. This paper introduces an approach to the specification of system families that is database-centred. It outlines the experience of producing a database of requirements for a TV product. The schema was built using RTM (Requirements Management Tool) supplied by Integrated Chipware. It constitutes a practical example of the advantages that can be gained by changing from the conventional document-based requirements management process. It also shows the difficulties that need to be dealt with when mapping from a document-based to a database-centred product specification View full abstract»

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