Introduction
Globalisation is about interconnection of economic, social, culture, technology, commercial among the organisations and peoples, which bring them together to form one interdependent community .The development made by human beings in the last century, is the greatest ever made in the history of mankind. This is mainly due to Globalisation and Information Technology. Globalisation enables us to exploit the vast natural and human resources of the world where as, information technology provides tools to help us achieve with progress. Due to Globalisation, software development units at Western is most shifted in the Eastern parts of the world, such as India, China and Pakistan, the reason mainly being inexpensive labour and recourses. This is because of rapid growth of IT education, due to which talented software developers and system analysis are easily available in eastern parts of world. This is also helpful for the developing countries in turn of employment generation and new review stream. Teams are working simultaneously from different parts of the world to develop software, resulting in satisfying the rapid demand of the software market in short time. “Reduce the development duration by 50% if there are two sites and by 67% if there are three sites” (Carmel E. at el, 2009).this is the main reason which compel western software industry to open development houses in the east.
Software is the essential part of Information systems, which help us to interact with IT infrastructure. Unlike other engineering fields, software engineering is not fully evolved. New methods and techniques of constructing software are introduced very frequently, but they still need lots of improvement and development. Requirement Analysis is the first and major process of Software Development, which help software developers to understand the real requirement and problem domain of the end user. This essay consist of two parts: first part explains the process of requirement engineering and the second describes the risk involved in requirement engineering due to by globalisation of software industry and finally the conclusion.
Requirement Engineering
Requirements are the needs of the user. In other words, these are the problems which need to be attended. In the software engineering context, it provides the justification of' “why” and “what” of software (Nuseibeh and Easterbrook, 2000) .The requirement engineering commences in the beginning of the software engineering process. If there are any mistakes or confusions in understanding the requirement, either by the software engineer or by the user, it is very difficult to resolve it after the development of the software. So it is suggested the requirement should be clearly communicated to both user and software developer so the end product will reflect the user needs.
Some examples of real systems which have failed due to poor requirement engineering are: (Bray, 2002)
• Performing Rights Society, PROMS project 1992
• London Stock Exchange TAURUS project
• London Ambulance Service Despatch system
The role of the Requirement Engineering in software engineering is very essential; it is like the foundation on which the software is built. According to Zave (1997):
“Requirements engineering is the branch of software engineering concerned with the real world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour and to their evolution over time and across software families.”
According to this definition, function and constraints of software should based on ‘real world goals’ and requirement engineering is used to translate these goal in to a software system.
A requirement engineer performs many tasks: first to identify the stakeholder/users as there could be many stakeholders and each with the different requirement: second to extract the tacit requirement of each of the stakeholder by close coordination and understanding of the work performed by each users effected by the new system, the third task is to list all the requirements for further examination and validation. It is necessary to confirm gathered requirement from the end user whether gathered information is actual account of stakeholder’s real requirement or not and finally negotiating the enlisted requirement with the stakeholder for further development of the software (Nuseibeh and Easterbrook, 2000)
Processes involved in Requirement Engineering
The input and output in requirement engineering process are “existing system requirement”, “stakeholder needs”, “organization standards” and “domain information”. As a result output are”agreed requirement”, “system specification”, “system models” (Kotonya and Sommerville, 1998) each of these outputs defines and states the user’s requirements, inform of a documents which helps software developers to understand who, what, how of problems faced by stakeholders.
The main actors involved in this process are domain experts often called End Users, System End User person who will administer the system after it is delivered, requirement engineer ,software engineer and project manager: each of them have specific role and deliverables. (Kotonya and Sommerville, 1998)
The processes involved in Requirement engineering are:
• Requirement Elicitation
• Requirement Analysis and Negotiation
• Requirement documentation
• Requirement validation
Requirement Elicitation
Requirement elicitation is the first step in requirement engineering. It is all about information gathering, identifying the correct source and method used to gather these requirements (Bray, 2002). The activities performed by the Requirement Engineer in requirement elicitation are
1. Establishes the objectives by identifying the business goals and understanding the problem to be solved.
2. Understands the background of the organization by analyzing the structure of the organisation, exploring the application domain and gathering knowledge about the existing system used in the organization
3. Gathers the knowledge about stake holder which includes the end user who will directly be affected by the system, customer or client “who pays for the system”, developer who will manage the system after deployment (Nuseibeh and Easterbrook, 2000) :
4. Extracts the “goal prioritisation” (Kotonya and Sommerville 1998).
5. Collects the stakeholder requirements because different stake holders may have different requirement.
6. Establishes the knowledge of domain in which system will work as no system works in vacuum, there must be other systems which will provide the inputs or extract output from this system.
7. Categorizes the organization requirement; this could be global policies of the organization. (Kotonya and Sommerville 1998).
There are many types of requirement which are necessary to collect during requirement elicitation process. Functional requirements are the ones which identify the core functionality of the system. Without them, the system will not complete or system will lose its basic needs. Performance requirements may be regarded as the “parameters” of the functionality which determine how fast or how reliable the system will work. Bray categorized it into “response times”, “quality of data”, “user friendly” (2002) .Design constraints are procured in requirement. It restricts the developer to perform the activities within limitation like system will only use client specified Object Oriented methodology, operation system, GUI or data base limitation.
Requirement Analysis and Notation
Requirements which are elicited earlier are analyzed and consensus of stakeholder on gathered requirement are required .This is performed because most of requirements may be ambiguous, incorrect, incomplete or might be incomparable with the budge allocated for development (Kotonya and Sommerville 1998). Requirement negotiation is vital because different stakeholders have different requirements and may disagree with requirement of different features of the system. Requirement negotiation is the process of discussing the conflict into the requirement and finding suitable consensus between stakeholders and developers .The main activity in Requirement Analysis is the analysis of check list which describes key feature such as “Premature design”,” combined requirement”,” unnecessary requirement” ,”non standard software and hardware”, “conformance with business goals”, “requirement ambiguity”, “requirement realism” and “requirement testability” (Kotonya and Sommerville 1998). Meeting is the most effective tool for requirement negations. Requirement analysis and negotiation is a time consuming task
Requirement documentation
Once the requirement is analyzed and all the ambiguities removed and all the stake holder are satisfied, then the gathered requirement are documented, as the standard defined in IEEE for further reference and traceability .This can used as a legal agreement of client and supplier about the characteristics and functionalities of developed software . The qualities of good requirement document as explain by IEEE are “Unambiguous”, “Complete”, “Verifiable”, “Consistent”, “Modifiable”, “Traceable”, “Usable during the Operation” and “Maintenance Phase” (IEEE Std 830-1984)
Requirement validation
Requirement validation is the last step in requirement engineering. As the name states, it is used to check the requirement document for any incomplete, ambiguous and inconsistent requirement in the document. The actors involved in the requirement validation are stakeholders, requirement engineer and system design engineer. The input required in the requirement process are “Requirement Document”, “Organization Knowledge “,”Organization standard” as the result of requirement validation output are “list of problem” and “agreed actions” (Kotonya and Sommerville 1998).Requirement Review is the technique used to validate the requirement. Prototyping is used to represent the gathered requirement in a small less function-able copy of the system required by the end user .It is another good technique to show the end-user how the system will work.
What is Globalisation?
Globalisation is the phenomena of making the world more connected interdependent, share the knowledge and resources. As definition suggests, it is a rapid increase in cross-border economic, social, technological exchange (globalisation guide, unknown). Globalisation started in the 19th century when the industries started producing commodities which were higher than the needs of local population and people started searching new markets to sell their products. The new ways of transportation aided globalisation to spread across the world. One of the reasons for globalisation is open, free markets. In the 80s “Structural Adjustment Programs” forced many third world countries to open their markets for foreign investors and trade. This encouraged them to spread their services and goods to developed countries. Free trade agreements like “North American Free Trade Agreement” and economic unions like the “European Union” led to higher rates of spread of money and ideas across the world. The growing cost of manufacture and labour in the industrialized nations compels them to seek other sources for cheap labour and resources. Developing countries give them perfect platform for both and help them to move the manufacturing plants to their countries. (SG Legal Solutions, 2008)
Information Technology and Globalisation
Information Technology (IT) is the driving from of globalisation. IT provides the communication and data services which help organizations to spread and connect their offices and peoples. In the context of the software industry, the most significant achievement of globalisation is Global Software work (GSW) (Shay at el, 2003) in other words distributed software development. In GWS software development team are collaborating with each other by using electronic collaboration site, email and video conferences to create the software collectively and development work follow the technique. called “Follow The Sun (FTS)” (Carmel E. at el, 2009) in with two or more team are situated at different geographic location and round the clock work is achieved by the difference of time zone between the two, when one team finishes one module at the end of the day it sends it to the other team in a region where the day has just started. Hence they just test the module and send it back for update. In this manner software are created in a much faster rate than before and this is all due to globalisation. (Shay at el, 2003)
These entire advances in the technology cannot help us to generate automated software like automobile industry where robots are used to manufacture automobile. We need human interactions in each process of software development from requirement to deployment, which leads us to failed software and cause disaster in financial, reputation and human life .There are many international standard which help us in maturing this process but error happen and mostly due to Human interaction.
It this section we are analyzing the effect of globalisation on one of the software engineering process i.e. Requirement Engineering which is elucidated briefly in previous section.
Requirement engineering in context of Distributed Software Development
Globalisation has change the nature of software development process ( Šmite , 2006), now teams which are located at vast geographical distance and different time zone can work on the same project ,this trend of developing software enable is resources “mobility “,knowledge sharing , “speeding time-to-market” , increase in “operational efficiency” (Smite, 2005).of software and this rapid development help the software industry to increase in production and effectively fulfil the requirement of customer. Many organizations from US and Europe form an alliance or partnership with software house in South Asia (India, Pakistan) and Far East to utilize the cheap resource and labour of these countries. The companies in US or Europe gather requirement by communicating with the customer and send the detail requirement document to the development in these countries .Some of these problem are explained by Berenbach (2006) the requirement engineer don’t have “time to read the requirement” from the customer and send the requirement document to developer, these types of problems are due to incompetence and are not analyse in this article. But according to some recent publications on effect of distributed requirement engineering we can categorize the effects of globalisation into three categories
Communication
Culture
Time
These categories are derived from the academic case studies performed by Edwards and Sridhar (2005) and real life projects and case studies described in articles by Damian and Zowghi (2003), Šmite, (2006), Berenbach (2006), Bhat, Gupta, Murthy (2006) and Hanisch & Corbitt (2004)
Communication
Communication is most important aspect in distributed requirement engineering (Hanisch & Corbitt, 2004), Success of any project depends on how the requirement is communicated to the developer and in the situation of distributed software engineering it becomes more difficult due to the geographical distant and mode of communication used (Gupta, Murthy 2006).Different formal and informal communication techniques are used in requirement engineering process (Hanisch & Corbitt, 2004),but major cause of project failure in Siemens Corporate are due to lack of communication Berenbach (2006) between the team members located in different offices of the company and even some fail due to movement of RE team of vendor from “onshore to offshore” and they reduce the communication between RE team of client (Bhat, Gupta, Murthy 2006). Electronic communication like Email is one of the most common asynchronous way to connect users with requirement engineers but it is found that email is less effective because email get lost or forgotten or misinterpret and end user may come up will same problem again, Damian and Zowghi (2003), so one of the most effective way to gather requirement in distributed environment is video conferences and live calibration software which enable you to interact with the end user directly and effectively (Damian and Zowghi, 2003).
Culture
Culture plays a critical role in any work and effect the requirement process in two ways, first differences in language of clients and development team can cause ambiguity in requirement and requirement document (Bhat, Gupta, Murthy, 2006). Language differences of client and vendor’s organization which is very common in outsourcing projects between Europe and India or Pakistan could lead to requirement document based on the “assumption derived from brief conversations” conducted between client and vendor .This can be overcome by using the standard language i.e. English throughout the project and define a glossary of terms used in that requirement document. Second most important aspect is Trust between the teams; this becomes more vital when the teams are distributed.”There is a wealth of research that systematically examines the effect of trust in the context of electronic commerce” (Cheung & Lee, 2001 cited in Edwards & Sridhar 2005) Virtual team project conducted by Edwards & Sridhar (2005) between student located in Canada and India clearly identify that trust level increase as the celebration between to team increase due to the use of synchronized method as Video conference Šmite, (2006)
Time
The differences in time zone is treated as a positive in the distributed requirement engineering because two teams located at different time zones can work for 24 hours a day on the project,since there is always a wide gap in the working hours of each team. This will increase the development and shorten the delivery time of the software. This time lapse gives extra time to both teams to utilize it in some useful way
On the other hand, there is a drawback is this, due to this difference in time the requirement engineer might not be in high spirits at dawn. According to Berenbach (2006) “if reviewers must be up at 3 am to conduct a Telco review, they may not be at their physical best, and might lack some enthusiasm.
Conclusion
Requirement engineering is all about understanding the right needs of right stockholders and translates them into system which will truly reflect the business value. In case of globalised distributed environment whether stakeholders or software developer are distributed on a geographical area, there are many obstacles in the requirement engineering process which need to addressed, for example one essential component of requirement elicitation is to identify the stakeholder, this process become difficult when the stakeholders are located in different geographical location and speak different language, to identify the correct stakeholder communication plays important role and project manager should use the standard language like English or some interpreter to identify or translator the real requirement . Difference of Time zone plays significant role in requirement negotiation with reference of both client and software developer because both have to either wake up or stay awake at wrong timings due to time zone different to negotiation and analysis the correct requirement.
Overall globalisation changes the conventional method of gathering requirement and new techniques are available which address communication, culture and time differences while gathering the requirement, but in overall globalisation increase the production of software and many developing countries are generating larger revenue due to shift in industry.
Reference List
Berenbach, B., 2006, Impact of Organizational Structure on Distributed Requirements Engineering Processes: Lessons Learned International Conference on Software Engineering 2006 international workshop on Global software development for the practitioner table of contents Shanghai, China Pages: 15 - 19 ISBN:1-59593-404-9
Bhat J. M., Gupta M, and. Murthy S. N, 2006 Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing, Software, IEEE Volume: 23, Issue: 5 On page(s): 38-44 ISSN: 0740-7459
Bray I.K. 2000, an Introduction to Requirements Engineering, Publisher by PEARSON EDUCATION (US) Date Published: 2002 ISBN-13: 9780201767926
Carmel E., Dubinsky Y., Espinosa A., (2009), Follow The Sun Software Development: New Perspectives, Conceptual Foundation, and Exploratory Field Study, International Conference on System Sciences, 2009. HICSS'09 42nd Hawaii
5-8 Jan. 2009
Damian D. E., Zowghi D.2003 Requirements Engineering challenges in multi-site software development Requirements Engineering Journal, 8, pp. 149-160, 2003
Edwards, H. K; Sridhar, V. 2005 Analysis of Software Requirements Engineering Exercises in a Global Virtual Team Setup Journal of Global Information Management, Vol. 13, Issue 2
Globalisation guide, Unknown viewed from http://www.globalisationguide.org/01.html on 25 February 2009
Globalization 2008 SG Legal Solutions viewed from http://sglegalsolutions.com/pdf/GLOBALIZATION.pdf on 25 February 2009
IEEE Guide to Software Requirements Specifications 1984 the Institute of Electrical and Electronics Engineers, Inc 345 East 47th Street, New York, NY 10017, USA -1984
Nuseibeh B. and Easterbrook S., 2000, Requirements Engineering: A Roadmap, ICSE 2000, 22nd International Conference on Software Engineering, June 4-11, 2000, Limerick Ireland.
Sahay S., Nicholson B., Krishna S., 2003, Global IT Outsourcing:Software Development across Borders Publisher: Cambridge University Press Pub. Date: December 2003 ISBN-13: 9780521816045
Šmite, D. 2006, Requirements Management in Distributed Projects, Journal of Universal Knowledge Management, vol. 1, no. 2 (2006), 69-76
Šmite, D., 2005 ,A Case Study: Coordination Practices in Global Software Development Product Focused Software Process Improvement, book series Lecture Notes in Computer Science Volume 3547/2005 Springer Berlin / Heidelberg 1611-3349
Sommerville I., Kontonya G., 1998 Requirements Engineering: Processes and Techniques Publisher: Wiley Chichester Date Published: 1998 ISBN-13: 9780471972082
Zave P. (1997). Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys, 29(4): 315-321.
No comments:
Post a Comment