Developing groupware for requirements negotiation: lessons learned

Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures. There is no complete and well-defined set of requirements waiting to be discovered in system development. Different stakeholders: users, customers, managers, domain experts, and developers, come to the project with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders. At the University of Southern California's Center for Software Engineering, we have developed a series of groupware implementations for the WinWin requirements negotiation approach. The WinWin approach involves having a system's success-critical stakeholders participate in a negotiation process so they can converge on a mutually satisfactory or win-win set of requirements. The WinWin groupware system, which has evolved over four generations, enables and facilitates heterogeneous stakeholder participation and collaboration. Each generation reflects an increase in our understanding of what is needed for successful WinWin groupware operations and technology support. The authors present the major lessons they learned during WinWin's development     

A requirements engineering framework for cross-organizational ERP systems

The development of cross-organizational enterprise resource planning (ERP) solutions is becoming increasingly critical to the business strategy of many networked companies. The major function of cross-organizational ERP solutions is to coordinate work in two or more organizations. However, how to align ERP application components and business requirements for coordination and cooperation is hardly known. This paper reports on the outcomes of applying a coordination theory perspective to an analysis of the ERP misalignment problem. We present a conceptual framework for analyzing coordination and cooperation requirements in inter-organizational ERP projects. The framework makes explicit the undocumented built-in assumptions for coordination and cooperation that may have significant implications for the ERP adopters and incorporates a library of existing coordination mechanisms supported by modern ERP systems. We use it to develop a proposal for how to achieve a better alignment between ERP implementations and supported business coordination processes in inter-organizational settings. We report on some early assessments of the implications of our framework for practicing requirements engineers. Both our framework and library rest on a literature survey and the first author’s experience with ERP implementation. In future empirical research, we will further validate and refine our framework.     

Requirements engineering within a large-scale security-oriented research project: lessons learned

Requirements engineering has been recognized as a fundamental phase of the software engineering process. Nevertheless, the elicitation and analysis of requirements are often left aside in favor of architecture-driven software development. This tendency, however, can lead to issues that may affect the success of a project. This paper presents our experience gained in the elicitation and analysis of requirements in a large-scale security-oriented European research project, which was originally conceived as an architecture-driven project. In particular, we illustrate the challenges that can be faced in large-scale research projects and consider the applicability of existing best practices and off-the-shelf methodologies with respect to the needs of such projects. We then discuss how those practices and methods can be integrated into the requirements engineering process and possibly improved to address the identified challenges. Finally, we summarize the lessons learned from our experience and the benefits that a proper requirements analysis can bring to a project.     

Applying empirical software engineering to software architecture: challenges and lessons learned

In the last 15 years, software architecture has emerged as an important software engineering field for managing the development and maintenance of large, software-intensive systems. Software architecture community has developed numerous methods, techniques, and tools to support the architecture process (analysis, design, and review). Historically, most advances in software architecture have been driven by talented people and industrial experience, but there is now a growing need to systematically gather empirical evidence about the advantages or otherwise of tools and methods rather than just rely on promotional anecdotes or rhetoric. The aim of this paper is to promote and facilitate the application of the empirical paradigm to software architecture. To this end, we describe the challenges and lessons learned when assessing software architecture research that used controlled experiments, replications, expert opinion, systematic literature reviews, observational studies, and surveys. Our research will support the emergence of a body of knowledge consisting of the more widely-accepted and well-formed software architecture theories.     

State of practice in requirements engineering: contemporary data

Little contemporary data exists that documents software requirements elicitation, requirements specification, document development, and specification validation practices. An exploratory survey of more than 3,000 software professionals was conducted and nearly 250 responses were obtained. Survey data obtained includes characteristics of projects, practices, organizations, and practitioners related to requirements engineering. Selected results are presented along with interpretations of this data.     

Rapid prototyping: lessons learned

Opinions on rapid prototyping as a practical development tool vary widely, with conventional wisdom seeing it more as a research topic than a workable method. The authors counter this notion with results from 39 case studies, most of which have used this approach successfully     

User Needs Analysis and requirements engineering: Theory and practice

Several comprehensive User Centred Design methodologies have been published in the last decade, but while they all focus on users, they disagree on exactly what activities should take place during the User Needs Analysis, what the end products of a User Needs Analysis should cover, how User Needs Analysis findings should be presented, and how these should be documented and communicated. This paper highlights issues in different stages of the User Needs Analysis that appear to cause considerable confusion among researchers and practitioners. It is our hope that the User-Centred Design community may begin to address these issues systematically. A case study is presented reporting a User Needs Analysis methodology and process as well as the user interface design of an application supporting communication among first responders in a major disaster. It illustrates some of the differences between the User-Centred Design and the Requirements Engineering communities and shows how and where User-Centred Design and Requirements Engineering methodologies should be integrated, or at least aligned, to avoid some of the problems practitioners face during the User Needs Analysis.     

Design measurement: some lessons learned

The author extracts from several measurement projects some of the important lessons he has learned about measurement in general and design measurement in particular. He synthesizes from these lessons a design-measurement framework in an attempt to communicate his personal measurement experience to other software engineers. The lessons he has learned fall into three areas: (1) how measurement must be applied in individual experiments or case studies; (2) how measurement can help continuously improve an organization's state of the practice; and (3) why measurement requires automated support.<>     

UML formal semantics: lessons learned

The article below presents the insights gained during a number of years of research dedicated to the formalisation of the Unified Modeling Language.     

Cognitive skills training: lessons learned

This paper describes lessons we have learned about presenting cognitive skills training. We have used ShadowBox as our training approach (Klein and Borders in J Cogn Eng Decis Mak 10:268–280, 2016), but the lessons apply regardless of specific techniques employed. We analyze key takeaways and lessons learned throughout the course of multiple ShadowBox projects. We explain how the original ShadowBox mission statement has evolved based on these lessons learned. Recommendations are offered for others who are engaged in cognitive skills training.     

Interactive remote instruction: lessons learned

This paper describes experiences with the use of the interactive remote instruction (IRI) system which was used to teach a computer science graduate course at Old Dominion University during the Fall 1995 semester. Through the use of high-speed networks and high performance workstations, IRI creates a virtual classroom so that geographically dispersed students can fully participate in a class. Central to this system is the availability of a personal workstation to each student through which the class is taken. Placing a workstation at each student's disposal opens the opportunity for student interaction and group collaboration. We compare this approach with other educational settings and describe lessons learned from instructor, student and technical perspectives. We also describe changes we are putting in place for an expanded usage in the coming fall semester using fiberoptic cable supporting a WAN internet protocol.     

Restoring a legacy: lessons learned

Rebuilding a legacy system has some parallels to the restoration of a work of art. The authors draw upon this comparison to illustrate the challenges they faced in redesigning a telephony system. The restoration involved far more than updating the code, the development team also had to understand the existing architecture, add new functionality, and develop a long-term hardware migration plan. The technical and managerial lessons learned should prove valuable to those involved in similar projects     

Intelligent lessons learned systems

Lessons learned processes have been deployed in commercial, government, and military organizations since the late 1980s to capture, store, disseminate, and share experiential working knowledge. However, recent studies have shown that software systems for supporting lesson dissemination do not effectively promote knowledge sharing. We found that the problems with these systems are related to their textual representation for lessons and that they are not incorporated into the processes they are intended to support. In this article, we survey lessons learned processes and systems, detail their capabilities and limitations, examine lessons learned system design issues, and identify how artificial intelligence technologies can contribute to knowledge management solutions for these systems.     

Handhelds go to school: lessons learned

Working in conjunction with teachers, researchers have developed a series of projects exploring the potential for using wireless handheld devices to enhance K-12 classroom instruction.     

Ada and real-time robotics: lessons learned

The Supervisory Telerobotics Laboratory (Steler) at the Jet Propulsion Laboratory (JPL) has developed a prototype telerobotic system to demonstrate the type of technology that will be used aboard Space Station Freedom Although the concept of telerobotics for space exploration is not new, the Steler system broke new ground in its demonstration of the feasibility of a local-remote architecture, including ground-remote control, for space applications. A remote space environment poses some interesting computational challenges to ground-remote control of space applications. A remote site has limited computation facilities, is burdened by minimal bandwidth and by round-trip communication delays of as much as 8 seconds, and yet is expected to respond quickly, predictably, and with recoverability to any anomalous situation. Additional design constraints are imposed by NASA's limitations on software, including on-board programs for the robot, being uploaded to the remote site without prior flight qualification. The authors discuss the use of Ada to meet the computational requirements of this project     

Teaching PSP: challenges and lessons learned

Software engineering educators need to provide environments where students learn about the size and complexity of modern software systems and the techniques available for managing these difficulties. Five universities used the personal software process to teach software engineering concepts in a variety of contexts.     

Using hypertext for semiformal representation in requirements engineering practice

Abstract

Requirements engineering is insufficiently supported in practice, especially the issue of appropriate formality of the requirements’ representation during their definition is yet unsolved. Since informal natural language has its disadvantages and immediate formal representation is very difficult, a mediating representation is needed. Therefore, we developed a novel approach to requirements engineering — with tool support — that is based on hypertext. We utilize hypertext primarily for semiformal representation, that can help to bridge the informality/formality gap between human and computer. We have applied our approach in real-world projects, and our experience suggests its usefulness. As a consequence, we recommend the use of hypertext for the specification of requirements in practice.     

Viewpoint: effectiveness of focused mentoring to improve requirements engineering industrial practice

Requirements engineering practice in industry is often encumbered by practical limits of time, resource, and attention. In our environment, most requirements authors have had no formal training in the practice, yet are expected to produce high-quality specifications that drive subsequent work. Authors are often unaware of different techniques for requirements specification and are rarely equipped to navigate all of the techniques and tools that are potentially available to them, to the extent that they are even aware of the various options. A small cadre of coaches, providing focused, just-in-time mentoring of authors in a handful of basic techniques can increase the proficiency of these authors, who in turn produce higher-quality requirements specifications. From this foundation, authors may be able to later adopt additional techniques to further improve the quality and maturity of their work, thus resulting in improved work products built on the basis of those specifications.     

Introducing XP into Greenfield Projects: lessons learned

ThoughtWorks introduced XP into an organization and successfully completed a bleeding-edge technology project with client staff that had no previous experience using an agile development approach. This article illustrates not only how XP helped make the project a success, but also gives other lessons learned regarding the introduction of XP at client sites.