Nancy R. Mead

Requirements engineering paper classification and evaluation criteria: a proposal and a discussion

In recent years, members of the steering committee of the IEEE Requirements Engineering (RE) Conference have discussed paper classification and evaluation criteria for RE papers. The immediate trigger for this discussion was our concern about differences in opinion that sometimes arise in program committees about the criteria to be used in evaluating papers. If program committee members do not all use the same criteria, or if they use criteria different from those used by authors, then papers might be rejected or accepted for the wrong reasons. Surely not all papers should be evaluated according to the same criteria. Some papers describe new techniques but do not report on empirical research; others describe new conceptual frameworks for investigating certain RE problems; others report on industrial experience with existing RE techniques. Other kinds of papers can also be easily recognized. All of these types of papers should be evaluated according to different criteria. But we are far from a consensus about what classes of paper we should distinguish, and what the criteria are for each of these classes.

Security quality requirements engineering (SQUARE) methodology

Requirements engineering, a vital component in successful project development, often neglects sufficient attention to security concerns. Further, industry lacks a useful model for incorporating security requirements into project development. Studies show that upfront attention to security saves the economy billions of dollars. Industry is thus in need of a model to examine security and quality requirements in the development stages of the production lifecycle.In this paper, we examine a methodology for both eliciting and prioritizing security requirements on a development project within an organization. We present a model developed by the Software Engineering Institutes Networked Systems Survivability (NSS) Program, and then examine two case studies where the model was applied to a client system. The NSS Program continues to develop this useful model, which has proven effective in helping an organization understand its security posture.

Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda

For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements Engineering (ICRE’00).

Survivability: protecting your critical systems

Society is increasingly dependent upon large-scale, distributed systems that operate in unbounded network environments. Survivability helps ensure that such systems deliver essential services and maintain essential properties in the face of attacks, failures, and accidents.

Survivable network system analysis: a case study

The Survivable Network Analysis method permits assessment of survivability at the architecture level. Steps include system mission and architecture definition, essential capability definition, compromisable capability definition, and survivability analysis of architectural soft-spots that are both essential and compromisable. The article summarizes application of the method to a subsystem of a large-scale, distributed health care system.

Requirements definition for survivable network systems

Pervasive societal dependency on large scale, unbounded network systems, the substantial risks of such dependency, and the growing sophistication of system intruders, have focused increased attention on how to ensure network system survivability. Survivability is the capacity of a system to provide essential services even after successful intrusion and compromise, and to recover full services in a timely manner. Requirements for survivable systems must include definitions of essential and non essential services, plus definitions of new survivability services for intrusion resistance, recognition, and recovery. Survivable system requirements must also specify both legitimate and intruder usage scenarios, and survivability practices for system development, operation, and evolution. The paper defines a framework for survivable systems requirements definition and discusses requirements for several emerging survivability strategies. Survivability must be designed into network systems, beginning with effective survivability requirements analysis and definition.

Collaborations: closing the industry-academia gap

When it comes to software engineering education, there is a gap between what industry needs and what universities offer. To close this gap, the authors propose a comprehensive collaboration between academic software engineering programs and industry. They offer a model for this collaboration and highlight three real-world ventures.

Industry/university collaborations: different perspectives heighten mutual opportunities

Abstract In this paper, we present the results of a survey of formal industry/university collaborations. The purpose of these collaborations is to meet the software engineering education and training needs of adult learners through joint ventures such as graduate programs (degree and certificate) and professional development activities (customized classes, seminars, forums, and conferences). Members of the Software Engineering Institute (SEI) working group on software engineering education and training conducted the survey in 1997–1998. The working group drew on the extensive experience of industry and university collaboration participants to help answer practical questions about the benefits of collaboration, the collaboration process itself, successful collaboration administration and programming, and lessons learned. Survey results are being published as a service to the software engineering education and training community to assist organizations interested in forming a new collaboration or improving an existing collaboration.

Software engineering education: How far we've come and how far we have to go

In this paper I trace the history of software engineering education and focus on some of the key players. I highlight what has been accomplished in degree programs and curricula, conferences and working groups, professionalism, certification, and industry-university collaboration. I also look at the challenges that lie ahead-the global reach of education, new delivery mechanisms, new professional efforts, and the need to engage in leadership in software engineering education. What new approaches should be considered? How can we educators maintain our vitality? How can we best nurture new educators and encourage others to join our profession?

A portal for software security

One of the real challenges facing the emerging field of software security is the lack of an easily accessible common body of knowledge. We describe a software security portal that the USA Department of Homeland Security (DHS) National Cyber Security Division (NCSD) is developing (along with the Carnegie Mellon Software Engineering Institute (SEI) and Cigital). The launch of this portal is scheduled for October 2005 as part of the US-CERT Web site. The portal aims to provide a common, accessible, well-organized set of information for practitioners wishing to do software security.