Stakeholders in Global Requirements Engineering: Lessons Learned from Practice

1. Stakeholders in Global Requirements Engineering:Lessons Learned from Practice by Daniela Damien IEEE Software March/April 2007 pp 21-27

2. Global Software Engineering (GSE) • Global and distributed projects: • Cross cultural boundaries • Cross geographic & time-zone boundaries • Cross organizational boundaries • Note that marketing organizations, not the end users, have often been the main source of inputs for requirements for software vendors such as Microsoft and IBM who build “universal” software such as database, operating system, office suite, etc. • People in different places need similar, but different items (e.g. native language differences) • In building customer specific applications(my comment) • The differences in people across the globe in global enterprises such as pharmaceutical companies, oil companies, financial companies, etc. adds another level of complexities Although this article deals with “international” and global issues --- it applies just as well within US where merger & acquisition is now a normal event among companies

3. Driving forces for GSE • Proximity to clients: • Global enterprises have customers around the globe • Global enterprises are set up around the globe • - - - - causing “offshore in-sourcing” • Cost-effective software development • People with different skills and different costs are spread around the globe - - - causing the “offshore outsourcing” phenomenon to seek out best cost/performance ratios • Around the clock production • Ever increasing demand on productivity and speed drives towards “24 by 7 production” These are the drivers for the distance and separation between the (a) software providers and (b) those the software is to serve.

4. GSE Increases Stakeholders • Additional stakeholders with globally distributed sitesaddsmore work for Requirements Engineers: • Managing requirements and coordination around the globe • Managing changes to requirements around the globe • We need to achieve a “shared” understanding through more collaboration: • More interactive ways of communications • Fast establishment of relationships (trust, appreciation, understanding, etc.) in a “multi-cultural” and “possibly high turnover” environments

5. Major Challenges of Requirements Engineers’ Interactions in GSE • Knowledge Acquisition and Sharing is More Difficult • More layers of and diverse stakeholders in global setting makes information seeking more difficult - - - causing potential misinterpretation of information due to indirect sources of information. • Knowledge sharing may be inhibited due to lack of trust which originates from different culture and faster turnovers in business everywhere • Getting to Common Process Understanding and Performance is Difficult • The process and maturity differences inherent in global organizations makes requirements management and coordination difficult among diverse groups • The increased physical distance makes managing requirements changes and managing iterative process more difficult • Effective Communications is More Difficult • Informal communications are difficult due to distance and diversity causing relationship and understanding building difficult ---- in turn causing difficulty in requirements negotiation. (people tend to resort to “formal status meeting” communications even though we have tools that allow both asynchronous and synchronous communications - - - )

6. Alleviate the “challenges” • Define clear organization structure with communicating responsibilities • Identification of the roles allow requirements gathering, understanding, and negotiation to be done in a more “trusted” environment because the “communicating group,” although still diverse, is smaller and can establish some bonding • Establish peer-peer links at all project management level across distributed sites • Because requirements gathering and changes require coordination and management, the linking of peer-peer facilitates easier and faster communications • Synchronize inter-organizational processes and perform frequent iterations and deliveries • Establishing common notation and common process minimizes misunderstanding • Frequent and smaller iterations allows quicker validation of the requirements and changes to requirements • Establish cultural liaisons • Ensures the cross-cultural understanding

7. Your thoughts • Is this discussion applicable to your class exercise? • Do you need to establish “communications linkage” with whom you are going to elicit/analyze/negotiate requirements? • How much work do you think that is --- hours - - days - - small chunks of continuous effort?