Our goal is to identify and understand issues that arise in the development and evolution processes for securing open architecture (OA) software systems. OA software systems are those developed with a mix of closed source and open source software components that are configured via an explicit system architectural specification. Such a specification may serve as a reference model or product line model for a family of concurrently sustained OA system versions/variants. We employ a case study focusing on an OA software system whose security must be continually sustained throughout its ongoing development and evolution. We limit our focus to software processes surrounding the architectural design, continuous integration, release deployment, and evolution found in the OA system case study. We also focus on the role automated tools, software development support mechanisms, and development practices play in facilitating or constraining these processes through the case study. Our purpose is to identify issues that impinge on modeling (specification) and integration of these processes, and how automated tools mediate these processes, as emerging research problems areas for the software process research community. Finally, our study is informed by related research found in the prescriptive versus descriptive practice of these processes and tool usage in studies of conventional and open source software development projects.

Many prominent open source software (OSS) development projects produce systems without overt requirements artifacts or processes, contrary to expectations resulting from classical software development experience and research, and a growing number of critical software systems are evolved and sustained in this way yet provide quality and rich functional capabilities to users and integrators that accept them without question. We examine data from several OSS projects to investigate this conundrum, and discuss the results of research into OSS outcomes that sheds light on the consequences of this approach to software requirements in terms of risk of development failure and quality of the resulting system.

When analyzing data elicited using the “war stories” technique, previously introduced by Lutters and Seaman (Inf Softw Technol 49(6):576–587, 2007 ), we encountered unexpected challenges in applying standard qualitative analysis techniques. After reviewing the literature on stories and storytelling, we realized that a richer analysis would be possible if we accorded more respect to the data’s structure and nature as stories, rather than treating our participants’ utterances simply as textual data. We report on five lessons learned regarding how we can better analyze war stories as stories: 1) war stories tend to be about exceptional situations; 2) war stories tend to be diverse and resistant to being combined into a single grand narrative; 3) the humanities can be a valuable resource for analyzing war stories; 4) war stories are not just text, they are also performances; and 5) war stories are not just data, they are also instructive and evocative.

Heterogeneously-licensed systems pose new challenges to analysts and system architects. Appropriate intellectual property rights must be available for the installed system, but without unnecessarily restricting other requirements, the system architecture, and the choice of components both initially and as it evolves. Such systems are increasingly common and important in e-business, game development, and other domains. Our semantic parameterization analysis of open-source licenses confirms that while most licenses present few roadblocks, reciprocal licenses such as the GNU General Public License produce knotty constraints that cannot be effectively managed without analysis of the system's license architecture. Our automated tool supports intellectual property requirements management and license architecture evolution. We validate our approach on an existing heterogeneously-licensed system.

Requirements engineers with many years of experience have a distinct perspective on the field. To sample this knowledge, we interviewed 34 requirements researchers and practitioners, each with up to 42 years of experience. We used open-ended, structured interviews in which we asked them to reflect on their experiences and professional development as requirements engineers over their careers. Several themes emerged: requirements engineers act as bridges between different worlds, good communication is key, good process can help but isn't everything, shorter requirements documents can be better, and good requirements are driven by customer value not technical elegance. All of these pertain to amethodical requirements engineering. Amethodical concepts are not rejections of method, but rather those concepts that are marginalized and left out of prescriptive methods for carrying out a procedure. We discuss these results and their implications.

This paper presents a specification-based approach that addresses several known challenges including false positives and domain knowledge errors. Our approach begins with a goal graph and plans. Source code is annotated with goals and events and precompiled to emit those at run time. Plans are automatically translated into a rule-based recognizer. An oracle is produced from the pre- and postconditions associated with the plan's goals. When the program is executed, goals and events are emitted and automatically tested against plans and oracles. The concept is demonstrated on a small example and a larger publicly available case study

In this research, we compare three related requirements engineering efforts: an industrial effort based on use cases; a case study analyzing these use cases by means of goal analysis; and a case study analyzing the same use cases with an integrated scenario analysis approach.

We demonstrate the scenario management and requirements tool (SMaRT). It provides an intuitive Web-based interface that supports analysts as they input, manage, view, analyze, and work with scenarios and their associated episodes, requirements, goals, obstacles, and pre- and post-conditions. The tool also supports project management functions. It encompasses greater functionality through the implementation of: similarity measures to aid in the automatic identification of probable duplication, syntactic indicators of scenario dependencies, notifiers of probable coverage gaps, procedural guidance for analysts, as well as revision and evolution tracking mechanisms. We exhibit the various features of SMaRT to the requirements engineering community through live access to actual SMaRT-generated data as well as by providing hands-on access to the tool.

Diverse uses of information technology (IT) in organizations affect privacy. Developers of electronic commerce, database management, security mechanisms, telecommunication and collaborative systems should be aware of these effects and acknowledge the need for early privacy planning during the requirements definition activity. Public concerns about the collection of personal information by consumer-based Web sites have led most organizations running such sites to establish and publish privacy policies. However, these policies often fail to align with prevalent societal values on one hand and the operational functioning of Web-based applications on the other. Assuming that such misalignments stem from imperfect appreciation of consequences and not an intent to deceive, we discuss concepts, tools and techniques to help requirements engineers and IT policy makers bring policies and system requirements into better alignment. Our objective is to encourage RE researchers and practitioners to adopt a more holistic view of application and system specification, in which a system or application is seen as an engine of policy enforcement and values attainment.

Scenarios have proven effective for eliciting, describing and validating software requirements; however, scenario management continues to be a significant challenge to practitioners. One reason for this difficulty is that the number of possible relations among scenarios grows exponentially with the number of scenarios. If these relations are formalized, they can be more easily identified and supported. To provide this support, we extend the benefits of project-wide glossaries with two complementary approaches. The first approach employs shared scenario elements to identify and maintain common episodes among scenarios. The resulting episodes impose consistency across related scenarios and provide a way to visualize their interdependencies. The second approach quantifies similarity between scenarios. The resulting similarity measures serve as heuristics for finding duplicate scenarios, scenarios needing further elaboration, and scenarios which have not yet been identified yielding valuable information about how well the scenarios provide coverage of the requirements. These two approaches, integrated with a scenario database, project glossaries, configuration management, and coverage analysis, form the basis of a useful and effective strategy for scenario management and evolution.