Looking for Reasons behind Success in Dealing with Requirements Change

During development, requirements of software systems are subject to change. Unfortunately, managing changing requirements can take a lot of time and effort. Yet some companies show a better management of changes in requirements than others. Why? What is it that makes some projects deal with changing requirements better than others? We pursue the long term goal of understanding the mechanisms used to successfully deal with change in requirements. In this paper we gather knowledge about the state-of-the-art and the state-of-practice. We studied eight software development projects in four different companies --large and small, inclined toward structured and toward agile principles of development--, interviewing their project managers and analyzing their answers. Our findings include a list of practical (rather than theoretical) factors affecting the ability to cope with small changes in requirements. Results suggest a central role of size as a factor determining the flexibility showed either by the organization or by the software development team. We report the research method used and validate our results via expert interviews, who could relate to our findings

USEFUL MEASURES OF COMPLEXITY: A MODEL OF ASSESSING DEGREE OF COMPLEXITY IN ENGINEERED SYSTEMS AND ENGINEERING PROJECTS

Many modern systems are very complex, a reality which can affect their safety and reliability of operations. Systems engineers need new ways to measure problem complexity. This research lays the groundwork for measuring the complexity of systems engineering (SE) projects. This research proposes a project complexity measurement model (PCMM) and associated methods to measure complexity. To develop the PCMM, we analyze four major types of complexity (structural complexity, temporal complexity, organizational complexity, and technological complexity) and define a set of complexity metrics. Through a survey of engineering projects, we also develop project profiles for three types of software projects typically used in the U.S. Navy to provide empirical evidence for the PCMM. The results of our work on these projects show that as a project increases in complexity, the more difficult and expensive it is for a project to meet all requirements and schedules because of changing interactions and dynamics among the project participants and stakeholders. The three projects reveal reduction of project complexity by setting a priority and a baseline in requirements and project scope, concentrating on the expected deliverable, strengthening familiarity of the systems engineering process, eliminating redundant processes, and clarifying organizational roles and decision-making processes to best serve the project teams while also streamlining on business processes and information systems.Civilian, Department of the NavyApproved for public release. Distribution is unlimited

Fabrication of high-quality-factor photonic crystal microcavities in InAsP/InGaAsP membranes

Optical fiber taper waveguides are used to improve the efficiency of room temperature photoluminescence measurements of AlGaAs microdisk resonant cavities with embedded self-assembled InAs quantum dots. As a near-field collection optic, the fiber taper improves the collection efficiency from microdisk lasers by a factor of ∼15–100 times in comparison to conventional normal incidence free-space collection techniques. In addition, the fiber taper can serve as an efficient means for pumping these devices, and initial measurements employing fiber pumping and collection are presented. Implications of this work towards chip-based cavity quantum electrodynamics experiments are discussed

Requirements change: What's the alternative?

Numerous studies have shown that a software project's cost, schedule and defect density escalate as the rate of requirements change increases. Yet none of these studies have explored the effects of not making requirements changes in response to changes in user needs. This paper explains why a project incurs just as much, if not more, risk when requirements changes are suppressed. © 2008 IEEE