by Anosh Wadia
Student
#1074977
Presented to Dr V. Sauter
IS6840 - Fall
2003
Many organizations today find themselves wanting to share software development efforts over several regions/countries. There are several reasons for their choosing to work this way:
When teams dispersed in different locations work on a project, it complicates the process of systems analysis. It also gives rise to a lot of issues, which if handled inappropriately, can lead to inefficiency and high costs. The challenge lies in monitoring the progress of each dispersed team or group and integrating the work done to successfully complete the project.
The objective of this paper is to analyze the phase of requirements gathering and management in a geographically distributed environment. It will identify the main challenges and issues in requirements gathering faced by globally dispersed teams in satisfying user expectations and will suggest how such problems can be effectively addressed.
Managing geographically dispersed teams is one of the biggest challenges faced by organizations that opt for Global Software Development (GSD). Companies today, find it cost effective to distribute their software development processes in countries such as India, Russia and Brazil. Organizations search for competitive advantages in terms of cost, quality and flexibility in the area of software development, looking for productivity increases as well as risk dilution. Often the search for these competitive advantages forces organizations to search for external solutions in other countries (offshore outsourcing). This epitomizes the traditional problems and existing challenges in GSD.
Requirements analysis is an important phase of systems analysis. It is the initial stage of the systems analysis process, and perhaps the most important. If the client's requirements are not gathered and defined accurately, the rest of the project becomes meaningless, since it does not reflect what the client actually wants. In geographically distributed environments, requirements management becomes even more difficult due to the characteristics of the distributed development environment such as physical distance, cultural differences, trust, communication, etc.
Software requirements represent the interests of customers and users and are the heart of any project. The quality and capacity to analyze and manage the requirements of software projects not only affects the final product quality, but also the time required to satisfy the objectives and meet the client's expectations. Badly managed requirements analysis could compromise the project's success, due to delays or even cancellation of the project.
Dispersed teams provide several benefits:
The first step in effective requirements gathering is engaging the right person/persons to meet with the client. In dispersed teams, either a person from the project headquarters who is an effective communicator can be assigned, or project leads from every team can be present with the client. The person/persons gathering requirements need to have the ability to distinguish 'stated' requirements from 'real' requirements and prioritize them accordingly.
One of the biggest problems that globally/nationally dispersed teams face in requirements gathering and systems analysis in general, is communication. Communication between parties in development teams or with customers/users becomes complex in such cases. Misunderstandings tend to take place due to contextual and linguistic differences.
Every discussion, decision and data needs to be clearly specified and documented at every stage. Project managers with geographically dispersed teams must give top priority to clear and effective communication. The project's communication plan should be created in the start-up phase and be completed by the planning phase. Other project management functions become easier because the communication process within the project team and with other stakeholders is effective and does not require the constant attention of the project manager.
Different parts of the analysis/development team may use different terminologies for the same concepts, which have the potential to snowball into huge communication problems, affecting the quality of the project. Globally dispersed teams usually use emails and faxes extensively to communicate with each other. The written word often tends to be perceived out of context. When all teams do not understand requirements as they are intended, they will all have a different understanding of what the client wants. The project starts going downhill from there since they will need to be told why each unit of the team is doing what they are doing. Further, cultural differences can also play havoc with communicating requirements effectively. They may use different contextual references and perceive terminologies and ideas differently. The constant clarifications and explanations result in waste of huge amounts of time and money. Therefore, normally, the requirements gathering process occurs in meetings with all the participants (project team, users and customers) in the same place. This facilitates communication, making any negotiation or existing conflict resolution easier.
Dispersed teams should take care to always work within the requirements stated by the client. For this, it is good practice to periodically go back to the requirements to make sure what you are doing and what the client wants are perfectly aligned.
A case study on Requirements Management in GSD and the difficulties in analyzing and managing the requirements of a software project in a dispersed environment was conducted by Rafael Prikladnicki, Jorge Audy and Roberto Evaristo at the School of Computer Science, Pontifical Catholic University of Rio Grande do Sul, Porto Alegre, Rio Grande do Sul, Brazil and University of Illinois, Chicago.
The case study was conducted in a multinational organization with software development centers in Brazil, India and Russia. The organization is a global software development center (GDC) located in Brazil, owned by a multinational organization with worldwide activities (one of the largest computer manufacturers in the world). The GDC aims to perform technological development for the organization in worldwide scope and since July of 2002, is located inside the technological park of a university in the South of Brazil.
The objective of this case study was to analyze a project developed in Brazil GDC, aiming at the identification of problems, advantages and disadvantages of requirements management in a geographically distributed context; at the same time that the organization was working to obtain the Capability Maturity Model for Software (CMM or SW-CMM) level 2 certification.
The SW-CMM is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes. The Software CMM has become a de facto standard for assessing and improving software processes.
Another objective of the organization's project was to develop a new version of a tool related to employee compensation for the human resources area of the worldwide organization. The three members of the project were located in different buildings of the Brazilian unit. The customers and users were located in the organization headquarters in the U.S., each one in its separate building.
Considering just the geographic team distribution, the following issues were found:
To counter these issues, the Brazil team spent six weeks in the U.S. for the knowledge transfer process and to start requirements gathering. The client also visited Brazil to get to know the team personally and to approve the requirements specification document. Social programs were also organized during these trips so that people could get to know their team members better.
The U.S. team, although not involved in the certification process, absorbed all the knowledge related to the process. Since the client was not American and was already having problems related to cultural differences, weekly meetings were held with them.
Beyond physical meetings conducted in a common place, the teams communicated through e-mails, teleconferences and net meetings. Issues that had risen due to communication gaps and misunderstandings were identified and addressed. Finally, the requirements gathering phase was performed to satisfaction. This was possible because of the work all team members did in order to minimize cultural differences, communication gaps and issues, with trust.
After the analysis of the case study, it was concluded that managing requirements in a global software development context can become an arduous task if the process is not well defined and if the teams are not prepared in advance to work in such a scenario.
Many lessons can be learned from the case study regarding the requirements management phase of dispersed teams:
Tools and technological environments have been developed over the last few years to help in the control and coordination of such teams. Many of these tools are focused on supporting procedures of formal communication, such as automated document elaboration, processes and other non-interactive communication channels.
Configuration management systems (CMS) and Defect Tracking Systems (DTS) help keep requirements management under control. When using CMS and DTS, it's important to make sure everyone uses them in the same way. Every member of the team needs to know where the source files are stored, what their state is and what can be done with them.
A software development company based in Boston had development teams in Boston, San Francisco, and Toronto. They all used the same CMS and DTS for controlling and managing client requirements, but in different ways. The Boston group used a nightly build and multiple promotion scheme for the sources (the first step was to successfully compile and build and the second step was to pass the minimum acceptance test, i.e. meet client requirements). The San Francisco group used a weekly build and single promotion scheme (it built once a week and fixed things until the build passed the minimum acceptance test, i.e.; met client requirements). The Toronto group used a scheme based on the review state, not the compile or build state.
This project got into trouble when the integration phase began. Since everyone had different ideas of how to use the CMS, the state of the sources was unclear to the project team. They solved this problem by understanding what each group did with their sources, and how that worked within the overall project. They then decided how they were going to use the source tree (complementary processes) so they could actually integrate the whole project and decide what the branch and label names meant within each branch and to each group.
All the teams agreeing on how to use the CMS and DTS at the beginning of the project can avoid such problems. Using an integrated CMS and DTS tool provides a number of benefits for the project team. For example, the defects and their effect on the sources are clearer to the whole team when they only have one way to look at them. Additionally, the whole workflow of the defect finding and source updating is made easier with an integrated tool.
However, not every team wants to use the same tools in the same way. Using the tools in an agreed-upon way is helpful in developing a complementary development process. Even if the processes are not exactly the same, they should accommodate each other.
The following are examples of requirements gathering techniques and how they can be adapted to a global analysis/development environment:
Interviews: Videoconferencing to discuss results of interviews with clients, or having a representative of each region, is an effective way to communicate requirements to each fragment of a team. Team members can also be provided with transcripts of the interviews.
Brainstorming: This involves identifying as many ideas as possible and ranking the ideas into those considered most useful by the group. Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Also, this technique encourages original thinking and unusual ideas. All team members should be involved to get as many ideas as possible. Since the teams are geographically distributed, video conferencing or conference calling is an effective way to hear everyone out. Written communication is not recommended for two reasons:
Requirements Workshops: This is a useful technique to prepare all team members to be effective in requirement gathering, analysis and management; provided it is time and cost effective. These workshops involve users and cut across organizational boundaries.
Use Cases: This is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques. Many developers believe that use cases and scenarios facilitate team communication, especially in dispersed teams. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team.
Another popular requirements management tool is Telelogic DOORSŪ. It is a multi-platform, enterprise-wide tool designed to capture, link, trace, analyze and manage a wide range of information to ensure a project's compliance to specified requirements and standards. DOORS' intuitive user interface makes access easy for large numbers of concurrent users on a network, and can maintain vast numbers of objects (requirements and associated information) and links. DOORS includes an Enterprise Change Proposal System that allows users to submit proposed changes to requirements on-line, including a written justification. Inter-project linking allows projects to share requirements, designs and tests, and promotes traceability to corporate or other standards. Discussion threads allow subject-oriented collaboration on ideas that increase creativity and deliver faster ideas, turnaround and results. Distributed Data Management (DDM) supports remote users who need temporary, remote access to all DOORS features. Working against a subset of the DOORS database off-line, remote users can incorporate their updates back into the master database - making it easy to team with other organizations to communicate with subcontractors and suppliers.
In conclusion, requirements gathering and managing are critical factors in the success of a software development project. For a globally dispersed team, it becomes even more complex since requirements need to be gathered from the client and translated to all the teams, taking into account cultural, linguistic and contextual differences between them. It is also crucial to establish a standard requirement management process so that every fragment of the development team works within the scope of the project, strictly adhering to the stated requirements. Getting the requirements phase right will pave the way for successfully performing the succeeding phases of the analysis and development process. Having an effective project leader who emphasizes open and effective communication, consistent documentation and cultural understanding are crucial to effective requirement gathering, analysis and management.
Non-Web Rerences:
Web References: