Impact of Organizational Structure on Distributed Requirements Engineering Processes: Lessons Learned Brian Berenbach
Siemens Corporate Research, Inc. 755 College Road East Princeton, New Jersey 08820 +1 609-734-6500
The requirements engineering program at Siemens Corporate Research has been involved with process improvement, training and project execution across many of the Siemens operating companies. We have been able to observe and assist with process improvement in mainly global software development efforts. Other researchers have reported extensively on various aspects of distributed requirements engineering, but issues specific to organizational structure have not been well categorized. Our experience has been that organizational and other management issues can overshadow technical problems caused by globalization. This paper describes some of the different organizational structures we have encountered, the problems introduced into requirements engineering processes by these structures, and techniques that were effective in mitigating some of the negative effects of global software development. projects in the large, and specifically distributed requirements engineering efforts. The requirements engineering (RE) competency center at Siemens Corporate Research in Princeton has had the unique opportunity to participate in large, global projects with different organizational structures. Each structure brought different challenges, benefits and issues. In the following sections, I will describe some of the structures we encountered, problems caused by the organizational structures, and, finally, I will suggest techniques for mitigating the problems encountered.
2. ORGANIZATIONAL STRUCTURES
Organization in this paper has a very specific meaning. It refers to the leadership and/or management of a specific area. If for example, there are analysts at a remote site but they all report to and are managed by one organization, then the requirements elicitation may be distributed but the organization is not. Figure 1 shows some of the more common arrangements in global software development efforts. “A”, “D”, and “I” represent analysis, high level design, and implementation (including low level design) respectively. Where the boxes touch it means that the processes are co-located (at the same site and organizationally integrated). Note that integration testing has been left out (It is not the focus of this report). Project management structure also varied on observed projects, and given any of the sample structures shown, management might have been co-located with any of the other development process sites or spread over several. Where management organization is relevant, it will be mentioned in the narrative.
Categories and Subject Descriptors
D.2.1 [Software Engineering]:Requirements/Specifications – elicitation methods, methodology, tools.
Management, Measurement, Documentation, Verification.
Requirements Engineering, organization, analysis.
Prior research in distributed requirements engineering has tended to focus on facilitation techniques   . Others have researched the nature of asynchronicity in distributed environments . There has also been research into the impact of culture on facilitation and negotiation . The use of enabling tools has also been reported in . Of necessity, many studies on distributed requirements engineering have used collaborative student projects to obtain information . Siemens Corporate Research, in collaboration with several universities is conducting such a study . However, very little has been reported on organizational issues and their impact on the effectiveness of Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial...
Please join StudyMode to read the full document