SOURCES OF SYSTEM REQUIREMENTS IN IT OUTSOURCING PROJECTS

Transcription

1 SOURCES OF SYSTEM REQUIREMENTS IN IT OUTSOURCING PROJECTS Jagna Anna Kluk 1, Piotr Kluk 2 1 University of Gdansk, Department of Business Informatic, ul.piaskowa 9, Sopot, Poland, klukj@op.pl 2 OPeGieKa, Department of Informatic, ul.tysiaclecia 11, Elblag, Poland, piotr.kluk@opegieka.pl Abstract. Article focuses on the analysis of system requirements sources used in IT outsourcing projects. Authors of books dedicated to software engineering write that the major and most important requirement sources are stakeholders. However analysts in IT outsourcing projects frequently have limited contact with clients and system users. They are often faced with problems of communication and information transfer. Projects, in which contact between outsourcing partners is limited are exposed to the risk of reliability and availability of requirements. Research presented in this article is intended to verify how engineers deal with these threats, i.e., which alternative sources are used when the access to stakeholders is limited. Theoretical part of the study focuses on identifying which requirements sources are recommended by the authors of literature. The empirical part focuses on identifying sources that are most frequently used by engineers and are most useful in outsourcing projects to fill the gap caused by insufficient cooperation between partners. An additional aim of the research is to verify, how the requirements in the projects of providing software as a service (SaaS) are specified. It is very interesting issue because in this form of outsourcing analysts do not know their future customers and system users, so they must use other alternative requirements sources. Keywords: requirements engineering, sources of requirements, IT outsourcing, SaaS. 1 Introduction One of the main challenges, the analysts have to face in IT projects, is how to obtain a complete set of requirements, which form the basis for the design and implementation of the IT system. This process is complicated both by the variety of requirements types that must be identified, and the variety of their sources. Problem of getting the complete set of requirements is additionally complicated in outsourcing projects, in which analysts frequently have the limited access to the customers and users. In projects realized by internal IT departments analysts usually have extensive domain knowledge and they are well aware of the organization in which the system will be used.. They often have informal meetings with users, at which they can obtain necessary information and clarify requirements.[3] In outsourcing projects contact between analysts and the customer is usually limited to several meetings in the initial phases of the project and therefore in the later phases obtaining additional requirements is difficult. While analyzing the requirements management in outsourcing projects in the context of risk, it should be noted, that the lack of cooperation between outsourcing partners, insufficient communication, and transfer of information are still listed among the risk factors threatening the success of projects.[5] It can mean, that providers have serious problems in obtaining requirements from the main source, which is the customer. Summarizing the above considerations, we try to analyze sources of requirements used in the IT outsourcing projects. Purpose of presented survey is identification of a set of requirement sources, which are the most useful in the projects realized by external provider. To achieve this goal the examination of literature dedicated to software engineering and empirical survey among software providers were conducted. Purpose of theoretical survey was identification which of requirements sources indicated in literature is the most important. Purpose of empirical examination was verification, whether the engineers use the same set of requirements sources, and depending on it, defining optimal set of requirements sources that is the most useful in case of IT outsourcing projects. The additional part of this survey presents analysis of the way the requirements in SaaS projects are specified. Process of requirements elicitation in SaaS model projects is conducted differently than in other forms of outsourcing. Therefore it is described in a separate chapter. The course and results of conducted survey are presented in the next paragraphs. The methods and techniques used to conduct this survey are presented in chapter 2. In chapter 3, due to the limited size of the article, the most essential elements of the theory concerning IT outsourcing are chosen. Chapter 4 features software engineering. And chapter 5 presents the results of the study of literature. In chapter 6 are conducted discussions about the sources of requirements used in IT outsourcing projects. The 7 and 8 chapters

2 are dedicated to empirical study. Chapter 9 includes case of project realized in SaaS model, and the last, 10th chapter presents conclusions from conducted survey. 2 How the study was conducted Theoretical examination was based on literature dedicated to software engineering and IT outsourcing. For survey books on software engineering, published in Poland after year 2000 and articles on the risks in IT outsourcing projects were selected, especially those emphasizing risks associated with requirements management in outsourcing projects. Empirical examination was conducted in sixteen outsourcing projects of software production. In order to identify requirements sources used in examined projects the case study analysis was conducted. Data were collected during interviews, using a standardized questionnaire. Respondents were analysts and designers, who were involved in process of requirements elicitation. Data collected during the interviews were used to determine universal set of requirements sources, which are the most useful in outsourcing projects. 3 Context of IT outsourcing projects IT outsourcing is a long-term transfer to an external supplier, who delivers and manages operations associated with using IT technology in the customer organization.[9] IT outsourcing includes such processes as software development, delivering software as a service (SaaS), management and maintenance of applications, integration services, hardware infrastructure management, data security management, availabling data centers that offer hardware platform and provide services to processing, archivization and storage of data. This survey focuses on software production projects. A very common practice in IT outsourcing projects is allocating the phase of identification and specification of requirements to one supplier, and design phase and implementation of the system to another. This results in reduction of contact between the team producing the software, stakeholders responsible for specifying system requirements, and future system's users.[2] In IT outsourcing projects subcontractors are very often involved.[5] Recently it is also a very common practice to transfer developing the organization business models to a consulting company. Consulting companies help clients in determining their requirements for ordered systems. They usually take part in negotiations and specification of requirements, but they do not participate in the further production process. In such projects, one of the major problems is the contact between developers and customer, who is the main source of requirements. It is especially problematic in situations, when clarifying requirements or confirming additional requirements identified in development process is necessary. 4 Review of requirements sources used in software production process Software production is the process of developing vision into the IT product or services. The vision of ordered product is based on the needs of organization of using IT technology. S.Wrycza writes that the system analysis is the study of problems and situations occurring in the organization. This is the basis for defining the IT needs for the future system.[16] These needs constitute system requirements. In the further transformations, other requirements, and restrictions appear, which do not derive directly from the customer's needs. However, they must be identified and included in the process of production. It ensures that the system will be a useful tool meeting the customer s needs.[16] The issue of identifying requirements sources in IT projects is described in almost every book dedicated to software engineering. However, this topic is always discussed very briefly. There is a lack of literature, presenting detailed analysis of requirements sources and indicating situations where other sources should be used. Most positions indicate customer or end-users as a requirements source. The process of obtaining requirements is described as the process of examining, and elicitating requirements directly from the owners of business processes, which will be supported by the future system.[12] Researchers also indicate the need of using another requirements sources and system constraints. P. Sawyer and G. Kotonya write that process of requirements elicitation includes discussion with customer, but also analysis of business processes in customer s organization, and analysis of another systems used by them.[12] Wirdrig and Leffingwell add to requirements sources domain knowledge, and operational environment, in which the system will work.[10] List of requirements sources identified in the literature study is presented below. Each of these sources is briefly described. Stakeholders, in researchers opinion, constitute the largest and most important source of requirements. [4][8][10][11][12][13] According to the definition of D.Leffingwell and D.Widriga a system stakeholder is everyone, who is affected by the new system.[10] In group of stakeholders we can distinguish, for example, customers, system users and organizations cooperating with the customer. During requirements analysis it is

3 necessary to identify all the stakeholders who are responsible for defining and accepting requirements, and will cooperate with analysts.[15] Domain knowledge it is expert knowledge about the area, in which the software will be working.[16] It is the main source of domain requirements and constraints. This group should also include norms, and standards, that must be applied in this field. Norm is a set of regulations, and their formal specifications. The aim of development, and implementation of norms and standards is facilitating the implementation of tasks, resulting from the economic needs, through the creation of the best practice. Their task is to harmonize the regulatory requirements in various fields of human activity: business, industry, commerce, transportation, etc. Popular norms and standards widely used in the software production are, i.e., the standards for ISO quality or International Accounting Standards (IAS). This is also very often indicated by researchers as a requirements source. [10][11][12][13] Using domain knowledge in IT outsourcing project is relatively easy, because there is no need to contact with customer to acquire the information, or to understand it. Operational environment, i.e., an environment, in which software will operate, indicates the number of functional and non-functional requirements.[10][11][12] They may cover for e.g. working in a real-time system, integration with other applications[12], or the efficiency, and system reliability.[13] According to R. Pressman, this source of requirements is defined, as technical environment, that includes also hardware, and telecommunication needs.[11] In IT outsourcing projects there may be problems with determining requirements, may occur, resulting from operational environment, because the external suppliers usually do not have sufficient knowledge about it. This information must be transferred from customer to supplier. Organizational environment is a source of requirements arising from the operation, culture, and politics of customer s organization.[8][10][12] These requirements are important because implementation of the system should not obligate the client to reorganize, if it is not the purpose of the project. Organizational environment as the source of requirements, also includes knowledge about the organization of work, procedures, used documents, and tasks performed in the organization.[8] The requirements arising from the organizational environment are better understood in the in-sourcing projects because engineers in these projects are fully acquainted with the specificities of their own company s functioning. Similar IT systems, that provide functionality similar to the designer, are sometimes mentioned as a source of requirements.[4][10][12] This group consists of similar systems to those used earlier by customer, previously produced by the provider, and similar systems operated in other organizations.[4] In outsourcing projects providers are often faced with ability, or necessity of using currently operating application as a prototype of future software. It s caused by dynamic development of IT technologies, need for system upgrades, creating integrated and centralized systems, and also need to provide users with access to system via the Internet. Strategic objectives are essential part of organizational strategy, which determines the main direction of the organization, in accordance with its role, mission, and tasks. The strategy of organization shows its intentions, action plans, and responses to changes occurring in environment.[14] The firm s objectives of computerization determine the main reasons of system implementation. They result from the company's IT needs. These objectives, typically specify the areas of the organization, which will benefit from computerization, the overall functionality of systems, and executed by their tasks.[12] Because they result from organization s strategy they can be a source of organizational, technological, or financial requirements.[8][12] Legal regulation is the set of laws and regulations of the Polish legislation, and EU directives, that is used to achieve specified desired state. These instruments are the source of functional and non-functional requirements such as, e.g. laws protecting the privacy.[13] One of the laws, which is requirements source for almost all systems gathering, and processing personal data, is Personal Data Protection Act. However in literature this source is rather hardly mentioned. In this survey, it was identified only in two positions. [10][13] In practice, the requirements arising from the laws, are often ignored during the analytical sessions with clients. Customers focus on communicating their needs and expectations, related to the areas, for which the system is created. Issues related with, e.g. protection of personal data, are usually ignored in meetings. Mostly there is only brief information in the contract, that system must meet the law, without further clarification of these issues. This usually results from lack of the awareness of importance of these issues. The purpose of presented survey is to identificate the set of requirements sources, which are the most useful in projects, realized by external IT services provider. At the beginning of this considerations, we discuss the need of a slightly different approach to analyzing the requirements in outsourcing projects, than in projects realized by internal IT department of customer's organizations. This discussion is presented in the next paragraph. 5 Requirements elicitation in IT outsourcing projects Although outsourcing strategy is widely used in software production process for many years, current question is still if is there a need to different approach to requirements engineering in IT outsourcing project. Transfer of software production process to external organization, causes increase of physical, conceptual and

4 also cultural distance between provider and future system users.[2] The contact between customers and developers is often formally limited by the contract. Problems with communication and information transfer are compounded in implementation phase. Designers and developers spend much time on requirements specification analyzing and system designing. Both of these activities require contact between customers and engineers in order to make design decisions.[7] Problems with communication are visible in incomplete and untimely information flow, and in the extension of the time needed to clarify doubts. It leads to exceed the schedule and project budget. Another very important issue, is relationships management. Many studies show, that IT outsourcing projects are threatened by problems with work coordination, and relationships management.[5] It can be associated with communication problems,[1] and it generates necessity to use another knowledge sources apart from customers. The need for searching additional requirements sources also confirms the risk factors that threaten the success of outsourcing projects.[5] Factors such as poor cooperation, insufficient communication and knowledge transfer between partners[1] increases the risk arising from using only stakeholders as sources of requirements. Risk factors such as lack of domain knowledge on the provider side, or low quality of requirements may indicate a need for looking the requirements in domain knowledge, and relevant legal regulations. It should also be noted that after the Polish accession to the European Union IT systems must be compatible, not only with Polish legislation, but also with EU directives. The next argument that forces the providers to search alternative sources is lack of detailed requirements specification in the beginning of the project. In the studies dedicated to risk in IT outsourcing projects, this factor is mentioned among the main factors threatening projects realization.[5] Problems arising from the lack of detailed requirements specification further compounded by the short terms of projects and limited access to the shareholders responsible for the requirements defining. Another risk factor is the large number of stakeholders involved in the project, such as consulting companies and subcontractors. E. Yourdon says, that in such situations may occur a lot of misunderstandings. Real needs of customers may not be properly communicated to analysts, users receive incorrect information about what engineers are going to design, and misunderstanding of the requirements is usually detected after system delivering.[17] Therefore, to avoid the errors resulting from the requirements management it is necessary to clarify doubts and to obtain information from sources such as similar IT systems, legislation, norms and standards. Therefore the purpose of survey presented in this article is verification, if in IT outsourcing projects engineers focus more on another requirement sources than stakeholder. In the next parts of this paper, there re presented results from conducted survey which confirm above considerations. 6 Case presentation Empirical examination was conducted in 16 IT outsourcing software production projects. In four of those projects subcontractors in implementation phases were involved. Providers in these projects were IT firms that specialize in outsourcing IT services. In 12 of tested projects providers had experience in IT outsourcing, and in 11 projects they had enough knowledge, necessary to work. Only in one case team had insufficient competences. So it can be assumed that providers had adequate skills to do the projects implementation. In 11 of the projects specification of requirements was detailed at the beginning of the work, but only 7 contracts contained criteria of product acceptance. In 9 of 16 projects providers had formally limited contact with customer. Respondents reported that in 10 of examined projects the problems with communication and information transfer occurred. Probably it is all contributed to the fact that only 7 of the examined projects were finished according to schedule. In 8 of the projects acceptance of software required modification and improve errors due to poor requirements management. One of these project ended with failure and provided software wasn t used by the customer. 7 Analysis of collected data Purpose of survey was identification of requirements sources, which are the most often used in IT outsourcing projects, and which are the most useful in provider s opinion. Respondents were asked, which of the indicated sources they used in software production process, and which of them were most useful. Results of this survey are presented below in figure 1. While analyzing obtained results, it should be noted, that respondents indicated as the most useful requirement sources at the first position Similar IT systems, and at the second, indicated legal regulation. The most important result of this study is placing Stakeholders at the third position. Hardly over half of the

5 respondents (9 out of 16) pointed a Stakeholder as the source which they used. It s quite different than researchers and specialists write in books. It is probably a result of the limited contact between outsourcing partners in the software development process. Lack of face-to-face meetings with customer, and problems with communication, caused that engineers were forced to explore other sources. Figure 1. Number of projects, in which particular requirements sources were used. Practically in all surveyed projects, where problems with communication occurred, similar IT systems were used at the acquisition stage and requirements analysis. In the group of similar IT systems respondents indicated similar systems, which operate at the customer firm (10 projects), similar systems previously produced by the supplier (8 projects) and similar systems used on the market (2 projects). In several cases it was necessary to use previous system as a prototype. In many projects providers had to rely only on their experience with previous production of similar systems, because they had no other sources of requirements. In two cases the reference visits, in other organizations using similar software, took place. Presentation of functionality of the similar system is very useful because it helps customers to imagine how such system might work and how it can be used in their own organization. It facilitates specification of requirements. Legal regulations are ranked at second position probably also due to the limited contact between outsourcing partners, and due to problems with communication, and transfer of information. Respondents, asked about the reason of using legal regulations, indicated the necessity of obtaining information, which wasn't given by the client, but was needed during requirements clarification stage. As an example, may be given the situation in which the project s contract was so constructed, that the provider was forced to adapt software to changing of legislation, without requests from the client. In such situation analysts were required, to track changes in the legislation, and to initiate themselves systems changes. Another example when usage of legal regulation as requirements source in outsourcing projects, turns to be necessary is the project, in which customer reports the need to adapt the system to changes in the law. Moreover, the project was implemented by the subcontractor, who had no direct access to the client and was obligated to contact with customer through the consultant. On the other hand, due to the long legislative process and short time to make changes, subcontractor was forced to use the legal regulations as main requirements sources. The use of domain knowledge, as significant source of demands, in 56% of the surveyed projects is also associated with the lack of meetings, or problems with communication, and transfer of information among outsourcing partners. To produce good software that will be useful for the customer, it is necessary to design it according to the demands, standards and norms suitable in the field of system application. If providers are unable to obtain necessary information directly from the client, analysts must acquire the domain knowledge from other sources. Results of presented survey show, that in only one project respondent indicated strategic objectives as requirements source. Purposes of informatization of organization are very useful at the planning stage, when the vision of using IT technology is being elaborated and during contract negotiations. But during software production phases they aren t used, because they are too general to be useful for designers and developers. In one of the projects main sources appeared errors and mistakes that were detected during acceptance tests. Such source as mistakes couldn t be used as the main source of requirements. Such way of software production proves the existence of serious problems with project. and production cycle management. In the examined case, provider received the old system as the prototype. In over process of production contact with customer was largely limited. At the stage of acceptance, it turned out that the provider's version of the system,

6 which was built basing on the prototype, was quite different from the customer's vision. However, this is an example of bad practice, that should not occur in software development. Further, it is noteworthy, that in each of the projects, various requirements sources were used. The number of sources varied between 2 and 6, with the average number of 3.6. Thus, it can be said that suppliers were trying to use diverse available information sources to identify the complete set of system requirements. 8 OMNIGIS system case presentation In outsourcing projects providing software as a service (SaaS), the requirements analysis is carried out in a slightly different way. In this paragraph we present the way it is made in project of providing software in SaaS model. It will be shown in case of OMNIGIS system. In this case it is described how systems requirements were obtained by analysts in SaaS project, in which providers had no contact with really future customer. INSPIRE Directive (Infrastructure for Spatial Information in the European Community) obligates EU members to implement spatial information systems infrastructure on their territories. Systems built by individual countries should be integrated. Information systems are based on network services compliant with standard OGC (Open Geospatial Consortium), and as a minimum, they should allow: searching, viewing, providing and processing spatial information. Network services should work in accordance with commonly agreed specifications. Access to infrastructure should be enabled through geoportals. The Directive obliges public institutions, that store spatial data, to share them within the framework of INSPIRE. This requires the implementation of appropriate solutions of sharing spatial data via network services according to INSPIRE directive and OGC standards in these organizations. Such project would incur costs to purchase software, hardware, employment specialists, and system maintenance. For smaller institutions costs are significant, and they may be a barrier in implementing these solutions [6]. For these institutions the best solution would be using SaaS (Software as a Service). This way of acquiring IT system, eliminates momentaneous high costs associated with the purchase of software and hardware. It also allows to transfer problems associated with system maintenance, and employment of specialists, to external provider [6]. OMNIGIS is system that is produced by OPeGieKa in response to necessity of implementation the INSPIRE directive. This system will be provided in SaaS model soon. Process of requirement acquiring in this project is carried out without participation of customers or users. This process is rather similar to requirements identification in on-the-shelf projects. Main knowledge sources in requirements elaborating are: experience in using technology, that was demanded in INSPIRE directive and network services OGC, experience in realizing projects associated with implementing INSPIRE directive, substantive knowledge of the requirements, which results from INSPIRE directive and OGC standards, experience in producing other systems of spatial information, extensive domain knowledge and experience in realizing various projects associated with geodesy, technical requirements resulting from the sharing software in the cloud computing model. In reference to previously conducted considerations we can say that in SaaS project, set of requirements sources includes such element, as similar systems previously produced by the organization, domain knowledge, legal regulation, operational and technological environment. 9 Conclusions Requirements specification is the basis for agreement between the customer and provider, and is the basis for determining the schedule and project budget. Delivering product which meets customers requirements very often determines the success or failure of the project. In order to achieve success it is necessary that the provider's team has access to the complete set of requirements. The most important conclusion from this study is that the use of only one source in isolation from another is insufficient. Current systems are very complex and more than one requirements source is needed to obtain full set of requirements. The second conclusion is that using similar IT systems as requirements source is good in case of SaaS projects. In another kind of outsourcing projects it can be more problematic. It is important to facilitate understanding customer's needs and to shorten time of clarification doubts. It can also help the customer to imagine what kind of functionality the system can provide. But using Similar IT systems as a main requirements source can lead to misunderstanding of current requirements or to duplication of bad solutions in new system. The third conclusion is that legal regulation constitutes more important sources than is apparent from the analysis of the literature. As the empirical examination shows it is a very important information and

7 knowledge source, particularly in process of clarification and confirmation of requirements. It is very useful in situations when the provider has limited contact with another stakeholder and also in case of SaaS projects. Legal regulation, directives, norms and standards are objective sources. In each project it s important to produce systems that operate in accordance with law. Results of presented study indicate that despite the huge popularity of IT outsourcing clients involvement in software development process is far from the satisfaction. In theory customer should be the main source of requirements and knowledge necessary to produce software, but the practice is different. In fact, the software providers take numerous actions to mitigate the negative impact of limitation the contact with the stakeholders and more often use other requirements sources than customer. This frequently results in the necessity of making additional software modification that conditioned acceptance of product. It leads to the most important conclusion that still there is a need to improve communication among outsourcing partners. 10 Acknowledgements This research work was supported by the European Social Fund, the State Budget and the Pomorskie Voivodeship Budget according to the Operational Programme Human Capital, Priority VIII, Action 8.2, Underaction 8.2.2: Regional Innovation Strategy within the system project of the Pomorskie Voivodeship Innodoktorant Scholarships for PhD students, III edition HUMAN CAPITAL NATIONAL COHESION STRATEGY References [1] Aron R., Clemons E.K., Reddi S. Just Right Outsourcing: Understanding and Managing Risk, Journal of Management Information Systems, 2005 nr 22/2, [2] Aubert B.A., Patry M., Rivard S. Assessing the Risk of IT Outsourcing. CIRANO Scientific Series, Montreal 1998, [3] Booch G., Brown A.W. Collaborative Development Environments. Advances in Computers Vol. 59, Academic Press, 2002, [4] Hamlet D., Maybee J. Podstawy techniczne inżynierii oprogramowania. Wydawnictwa Naukowo-Techniczne, Warszawa, 2003, [5] Kluk J. Changes of the profile of risk factors associated with requirements management in outsourcing projects. Proceedings of the 16th International Conference on Information and Software Technologies IT 2010, Kaunas 2010, [6] Kluk J. Strategic analysis of the SaaS model. The Eight International Conference on Perspectives in Business Informatics Research. Kristianstad Academic Press, 2009, [7] Kluk J. Zarządzanie wymaganiami na systemy informatyczne w projektach outsourcingowych. In Współczesne aspekty informacji T.III, red. Goliński J i in., Szkoła Główna Handlowa, Warszawa, 2010, [8] Kruchten P. Rational Unified Process od strony teoretycznej. Wydawnictwa Naukowo-Techniczne, Warszawa 2007, [9] Lacity, M., Willcocks, L., Feeny, D. The value of selective IT sourcing. Sloan Management Review, 1996, 37(3), [10] Leffingwell D., Widrig D. Zarządzanie wymaganiami. Wydawnictwa Naukowo-Techniczne, Warszawa, 2003, [11] Pressman R.S., Praktyczne podejście do inżynierii oprogramowania. Wydawnictwa Naukowo-Techniczne (IO), Warszawa, 2004, [12] Sawyer P., Kotonya G. Software Requirements Engineering Knowledge Area Description, v0.5, 2001, [13] Sommerville I. Inżynieria oprogramowania. Wydawnictwa Naukowo-Techniczne, Warszawa 2003, [14] Stoner J.A.F., Wankel Ch. Kierowanie. Polskie Wydawnictwo Ekonomiczne, Warszawa, 1996, [15] Vries H.d., Verheul H., Willemese H. Stakeholder identification in IT standarization process. In: MIS Quartely Special Issue Workshop on Standard Making: a Critical Research Frontier for Information Systems, Seattle, 2003, [16] Wrycza S. Informatyka ekonomiczna. Polskie Wydawnictwo Ekonomiczne, Warszawa 2010, [17] Yourdon E. Współczesna analiza strukturalna. Wydawnictwa Naukowo-Techniczne, Warszawa, 1996.