Lack Of Effective Communication And Its Impact

Published Date: 02 Nov 2017

Abstract

Delivering the systems that meet all the stakeholder’s need with resource constraints has been one of the challenges in current scenario of software development. Ensuring effective communication between requirement engineers is one of the challenging issues. Poor communication between stakeholders leads to errors in the systems. In order words, lack of effective communication between stakeholders can lead to complexities during software development process. With the growth of organization and the concept of collaboration engineering, the effective communication between distributed groups has been one of the main challenges for the organization.

There are many reasons behind futile communication and many researchers are still interested to figure out the factors that affect the communication between the stakeholders.

The main motifs of this paper are: i) To categorize all the sectors that affect communication ii) To use the categorization for developing Communication Impact Score for an organization, iii) To introduce a relationship between trust and requirement engineering, and iv) To clarify the relationship between emotion and communication.

Keywords: Requirements Engineering, Communication, Categorization, Impact Score, Trust

Introduction

Requirements engineering is a crucial part of software development process. It is a systematic approach of eliciting, understanding, analyzing and documenting requirements gathered from stakeholders. Communication between stakeholders plays a vital role during requirement engineering process. Failing to correctly address the requirements of stakeholders leads to high software development cost. Software requirement errors can lead to additional cost up to 70-85% in an average software project [1]. Lack of proper Requirement Specification during initial phase of the software development cycle makes the later stages of the project more vulnerable to the change in requirements [2].

With the growth of organizations, the concept of globalization, collaboration and outsourcing arises, which eventually leads to widely distributed working groups with a common goal. Nowadays, many multimedia systems are available to support sophisticated communication between stakeholders. Multimedia systems include video conferencing, electronic mailing systems, teleconferencing, and social networks. These types of urbane technology have made the world narrow and globalization of organizations made possible. Despite use of such technologies for communications, there are many other factors that influence the overall communication activities leading to poor requirements.

Problem Statement

Requirement engineering is an important phase in software development process. Poor communication leads to missing, ambiguous and unnecessary requirements which mislead the overall objective of a project. There are many factors that affect the communication between stakeholders.

How can we categorize communication related problems in requirement engineering and help organizations to find the communication related problems? Is there any relationship between trust and requirements engineering? The research has been inspired from above two questions. Many researchers have addressed the communication problems that have impact on requirements engineering. The main concern of the paper is to help an organization to figure out the communication related factors affecting the crucial requirements engineering phase. Besides that, there are many other factors obscured and waiting to be revealed. As emotion has a unique relationship between requirements engineering [3], trust between stakeholders can also be another reason that affects communication and ultimately the requirements engineering process.

Definition and Validity of Scope

The more effective the communication, the better the exchange of ideas between all the parties involved in the development of the system henceforth, customer satisfaction. For establishing this ideology we have tried to communicate ideas around the given requirements for designing a Gas Station Control System, from the given set of requirements we tried to discuss in detail about the requirements we felt that were not clear and included few other requirements to the set of requirements we already have. Most of the requirements that got added to the system were concerned with security and safety, the initial requirement we had was the system should be able to provide reasonable security. The requirement itself was not communicated clearly as it was just stating reasonable security and not indicating if it was related to the Fuel Filling Station security to be integrated into the system or the general employee login credentials security any specific expectations the customer has about the security features of the system. Once the ideas were communicated around that specific requirement then it was evident that the gas station security has to be integrated into the system to monitor customers coming into fill the gas. So this kind of enhancements to requirements can be done without affecting the project at later stages if ideas are communicated around the requirements that are not clearly stated.

This scenario will be valid only if the customer is completely aware of what he exactly wants out of the system, which again creates confusion as a customer is never completely aware of his complete set of expectations during the early or initial stages of the project. For effective communication during RE process stage it is always better to present the customer with working prototype of the deliverable and then actually start working on designing the actual system to implement it.

Literature Review

Impact of Poor Requirement Engineering in Software Outsourcing

Requirement Engineering is one of the key processes in the software development cycle. In most cases, requirement engineering phase decides the success and failure of the project [2]. This research primarily focuses on the problems that software developers face during their project activities, due to the poor software requirement practices.

The paper [2] introduces number of hours spent during requirement meetings, methods used for communication between clients and the demerits of communication techniques used which lead to poor requirements.

Email messages, Instant messaging, voice conference and video conferences are most widely used techniques in the company selected by authors to do research.

From the survey, it is found that, requirements that are expressed in natural languages were difficult to express and ambiguous. Also, the accents of foreigners were reported as a barrier to understand the requirements from clients.

According to the paper, during requirement gathering process, the most obvious scenario will be to have a non technical client at one end and developers at another end. Due to the non-technical managerial person at the client end, the developers have to work more on requirements modification and error fixing during the development phase.

The time zone difference for the widely distributed company is also considered as a factor that affects the work pattern ultimately affecting the communication between stakeholders.

4.2 Paper Prototype for Requirement Elicitation

According to the paper [4], due to poor and ineffective communication between stakeholders, the system becomes vulnerable to errors and the authors have proposed an enhanced approach of using papers for prototyping during requirements elicitation process.

The authors of the paper have suggested using throwaway paper prototype instead of other expensive prototypes. Authors of the paper [4] have suggested the paper prototype concept because the papers can be trashed after the completion of task; moreover, this the author believes that this type of prototyping method is user friendly and has no technical hurdle. The authors are not sure about effectiveness of this type of prototyping techniques in huge projects but ensure that this will definitely works for small and medium projects.

4.3 Communication Problems in Requirement Engineering

According to paper [5], most users express their requirements in natural language and analyst translates requirements statements into representational objects in a domain model. After the modeling of requirements, they are presented to end users for validation.

Then it is the job of the analyst to translate requirements statements into some kind of representing objects in a domain model. Once the requirements are modeled, they are presented to end users for validation and during this phase, the analysts face the communication problem because of lack of familiarity of end users with the notations used while modeling their requirements. Although face to face communications cost higher, it is more preferred than that of telephone conversation for exchanging information [5]. According to paper, if client’s manager is given authority to choose the client members for collecting requirements, the choice of the manager will be based on many factors; most of them will be focused on commercial interest of the clients’ business not in the software project. This shows that the social and organizational issues have great impact on the effectiveness of communication leading towards success or failure of the requirement engineering process.

According to authors, there are three major communication barriers and they are uselessness of the current communication channels used, restrictions imposed by annotations, and social/organizational barriers. The paper concludes that the social and organizational issues have great influence on effectiveness of communication.

4.4 A Study of Emotions in Requirements Engineering

Requirement Engineering is one of the key processes in the software development cycle. In most cases, requirement engineering phase decides the success and failure of the project. The requirements might not be communicated properly due to several reasons and according to the paper [16], emotions of the stakeholder’s play a significant role in requirements being communicated effectively, as during the requirements gathering phase human dimension that is the state of the human emotions will play a significant role compared to the technical role.

Human behavior is influenced by "other cognition "errors [16], specifically emotions. Affect Grid, single item scale of pleasure and arousal designed by Russell et.al [17] has been used to characterize the impact of emotions of stakeholder’s on the requirements throughout the development process.

4.5 Using the Affect Grid to Measure Emotions in Software Requirements Engineering [11]

Emotional expressions have a pivotal role in social interaction. Experiments have been conducted to prove that high stimulation and low pleasure levels in the requirements engineering process present with a scenario of conflictive requirements [11]. Affect grid measures impact of emotions on different each requirement and its different versions on a scale intended to assess the affect along pleasure-displeasure and arousal-sleepiness dimensions on a 1-9 scale. Software requirements are dynamic and grow with time so the chance of gathering wrong requirements is very high as the emotional state of stakeholder will not be the same all the time and there by having an impact on the requirements elucidated and documented.

4.6 How to Overcome Communication Barriers in Global Software Development?

According to the paper [9] when teams dispersed in different locations work on a project, the co-ordination between all the teams working on a project is important and it complicates the process of systems analysis giving 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 effectively complete the project. Requirements analysis is an important phase of systems analysis, if the client's requirements are not gathered and defined accurately; the rest of the project turns out to be hollow, since it does not reflect what the client actually wants. Geographically distributed environments, requirements management becomes even more difficult due to the characteristics of the distributed teams working on the project and they represent the interests of customers and users and are the heart of any project. The quality to 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 affect the project's success, due to delays or even cancellation of the project development environment such as physical distance, cultural differences, trust, and communication.

Different teams globally working on the development of same project may use different terminologies for the same concepts, which will have the potential to cause communication problems, affecting the quality of the project. Globally dispersed teams usually use emails and faxes extensively to communicate, sometimes 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 effortless 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 create confusion with communicating requirements effectively. Different teams may use different contextual references and distinguish terminologies and ideas differently.

4.7 Computer-mediated communication to support distributed requirements elicitations and negotiations tasks [7]

Requirements engineering is one of the most communication-intensive activities in software development, greatly affected by project stakeholder geographical distribution. Despite advances in collaboration technologies, global software teams continue to experience significant challenges in the elicitation and negotiation of requirements. Deciding which communication technologies to deploy to achieve effective communication in distributed requirements engineering activities is not a trivial task. Is face-to-face or text based communication more appropriate for requirements elicitations and negotiations? In teams that do not have access to face-to-face communication, is text-based communication more useful in requirements elicitations than in requirements negotiations? Here, we report an empirical study that analyzes the effectiveness of synchronous computer-mediated communication in requirements elicitations and negotiations. Our investigation is guided by a theoretical framework that we developed from theories of computer-mediated communication, common ground, and media selection for group tasks; a framework that considers the effectiveness of a communication medium in relation to the information richness needs of requirements elicitation and negotiation tasks. Our findings bring forward empirical evidence about the perceived as well as objective fit between synchronous communication technology and requirements tasks. First, face-to-face is not always the most preferred medium for requirements tasks, and we reveal a number of conditions in which, in contrast

Research Methodology

This section outlines the procedures that we have followed to understand the reasons for communication problems in Requirement Engineering (RE) process.

This research was conducted in order to study causes and impact of poor communication on Requirement Engineering process. In order to get an insight into the study we have opted to Analyse the papers published along the similar lines, Group Discussion among our team and communication of ideas cantered around the requirements of the system.

We have used descriptive research which is mainly concerned with describing the nature or condition and the degree in detail of the present situation.  The aim of descriptive research is to obtain an accurate understanding of the current problem and recommended solutions. In this type of research, the researchers should have overview and domain knowledge to understand the current trends and situation. In this study, the descriptive research method has been used to highlight the importance of communication during the Requirement Engineering process.

The research also involved Group Discussion, including our team and selected students who had the domain knowledge to talk, discuss, and outlay the importance of communication during RE process to achieve best results with high quality and user satisfaction. All the people involved in the research talked about the best practices followed in the industry, various sophisticated tools that can be used to overcome the problem to certain extent. It was clear from our discussions after all the participants agreed that with effective communication any project can be completed within the allocated budget, time and delivered with highest quality which guarantees user satisfaction .

We incorporated an experimental process of communication of ideas cantered around the requirements of the system to see how effective communication of ideas of customer/ user that actually get transformed to requirements of the software will cut down the cost both in terms of finance and resource time. From the research we found that it is important that the customer articulates his idea clearly and states down all his expectations so that the idea can be converted to requirement based on the boundary constraints and functioning environment after discussing with domain experts. If the idea is not clear or vague there will always be confusion on what kind of services is this system supposed to deliver, usability concerns, performance issues. With communication of ideas centred on the requirements it is always possible that the customer will have a chance to remember the requirements that he might have forgot to put down. In all with this kind of communication focussed around requirements we have been convinced that it saves time and cost by reducing the loop of requirement enhancement by at least 50%.

With the analysis of papers published discussing the importance of effective communication during Requirement Engineering process we have come with better ideas to minimize the problem by using the best practices suggested like comparing Problem solving and Problem finding techniques to improve the quality.

Findings and recommendations

From our study, communication problems in requirement engineering can be categorized as follow:

Social and Organizational Issues

Cultural Issues

Emotion and Trust

Computer Aided Communications

Language and Technology Barriers

Geographical Issues

Domain Knowledge

6.1 Social and Organizational Issues

In an organization, different stakeholders come from different backgrounds and have different knowledge, views, concerns and priorities. Different views from different stakeholders lead to conflictive requirements, so, negotiation is a part of requirement engineering process in order to solve conflicting requirements issues [8].

In an organization, the different types of stakeholders will participate in requirement elicitation process and they will have different positions in an organization. Some of the stakeholders might have political influence in other stakeholders, which suppresses other stakeholders’ view. These kinds of political influence of some stakeholders can lead to missing requirements or addition of unnecessary requirements proposed by the powerful stakeholders. The social and organizational issues have impact on effective communication between stakeholders and ultimately to the requirement engineering process.

Cultural Issues

Stakeholders come from different cultural backgrounds and it has also impact on communication during requirements engineering process. Some people are influenced by their cultures and they exhibit their emotions openly. They even express their fear, frustration and sadness during meetings [10]. Other people who are from different cultural backgrounds do not express their feelings unless they are motivated or forced to do so. Those people will be reticent and they feel uncomfortable to express their emotions.

The stakeholders from those cultural backgrounds who openly express their emotions will effectively communicate where as those people from cultural backgrounds who can’t express their emotions openly won’t be able to communicate effectively. Those people might use nonverbal communications (like eye contact, gestures, facial expressions etc.) but those people will always be dominated by those who express their feelings openly during requirement engineering process. In other words, different culture has different ways of verbal and non-verbal communications, and stakeholders must be aware of this to avoid possible potential problems [10].

If the stakeholders who have higher influence on other stakeholders couldn’t figure out this problem, then the requirement gathering will end up with missing or incomplete requirements.

Emotions and Trust

Humans have emotions and these emotions have impact on our mundane activities. Requirement engineering includes interaction with stakeholders and negotiations. The emotions of the stakeholders participating in requirement engineering process also have a vital role in requirement agreement and negotiation [3]. According to paper [3], low pleasure and high arousal are the negative signs which lead to conflictive requirements. So, the emotions have a unique relationship with requirement engineering.

Emotion has also impact on communication between stakeholders. If the stakeholders are under high stress, they might not be able to express their feelings effectively and also they may not hear others as well [10]. Considering this psychological phenomenon, the emotion has direct impact on stakeholder’s communication. In other words, if the stakeholders are going through high level of stress, the communication can’t be effective which ultimately lead to poor requirement engineering.

If the end users do not trust developers or requirement engineers, then the communication between them can’t be effective. The trust can be developed by avoiding the things that is affecting the communication.

For an instance, while working with customers, not listening to them and showing signs that makes them believe that the requirement engineers are not interested may lead to ineffective communication [5].

To avoid this problem, the requirement engineers can improve relationship with customers through eye contact, body posture and facial expressions. In order to draw customer’s attention, different techniques like asking questions, re-stating what we have heard, and taking notes can be applied in order to demonstrate that developers have trust with customers and developers are listening to them [5]. If the customers doubts the ability of the developers to change their requirements in to a reality then the effective communication cannot be established.

In order to determine whether or not stakeholders participating in the meeting have trust with the developers, many non-verbal communications can be used. Vocal pitch can also be one of the parameters to decide the trust level. Trust level has a unique relationship with the vocal pitch of human [12]. If the stakeholders do not trust the developers or requirement engineers then their vocal pitch will be higher than before. Other factors beside the vocal pitch can also be used as supporting parameters to decide the trust level. If we are able to figure out the other stakeholder’s emotional states and their trust level relevant actions can be taken in order to maintain effectiveness of the communication between stakeholders.

To maintain the emotional states of the stakeholders, the requirement engineers are responsible to create a favorable environment in order to cope with negative emotions impact, and requirement engineers can be trained for stress management in order to make them ready to handle stressful environment that might arise during requirement negotiation [3]. In order to maintain both emotions and trust level, requirement engineers should be trained to develop skills in order to develop trust between stakeholders and requirement engineers which ultimately direct to effective communication between them.

Computer Aided Communications

The communication media used during requirement elicitation also have impact on communication between stakeholders. Face to face communication is assumed to be the best way of communication, but previous study [6] shows that, for the requirement negotiation process, video conferencing was found to be more effective than face to face communication. Similarly, text based communication found to be more effective than face to face communication [7]. In an organization, due to globally or locally distributed teams, the requirement engineering process will only be successful with the use of computer and wireless technology. Some of the most widely used computer aided communication methods are e-mails, web chats, teleconferencing, and video conferencing. Requirement engineers should be aware of merits and demerits of using such technology and they should ensure that the communications have not been affected by external constraints like network bandwidth, language issues, etc. If organizations are cognizant of the relationship between computer aided communications with the requirements then preventive actions can be taken in order to maintain the quality of requirements engineering process.

Language and Technology Barrier

The user might be from different geographical location and the language used by developer may not be the primary language for that user; in this scenario, the user may not express the requirements correctly.

Most users express their requirements in natural language and analyst translates requirements statements into representational objects in a domain model [5]. There might be a case where developer misinterprets the customer’s requirement leading to the problems in future.

Beside this, the customers might not be aware of the notations used by developers for modeling the requirements [5]. In this case, the developers are responsible to make the customers understand how the system actually works and developers have to show, how their requirements have been portrayed in the system. Beside this, the customers or requirement engineers might use the terminology or notations that they are not familiar with. In this case, the communication can lead to conflictive or wrong requirements.

It is not necessary that the end users and customers will be aware of technology and may propose unrealistic requirements. Using prototype, the customers can be familiarized with the system.

Geographical Issues

The concepts of collaboration and out sourcing have been emerged due to globalization of organizations and companies. To maintain the effectual communication between the distributed team have been one of the main challenging issues. Time zone issues because of geographically distributed teams can also be another factor affecting communication [15]. The research study [9] proves that in the globally distributed teams, the team with priority skills will be dominant to other teams lacking priority skills which lead to low coordination between those teams.

The requirement engineers should also be aware of the impact of geographical issues on communication using computer aided tools.

6.7 Domain Knowledge

The requirement engineers who collect requirement information from customers should have domain knowledge of the system they are developing. Lack of domain knowledge can lead to collect wrong requirements or even end up choosing unnecessary requirements. With domain knowledge, the requirement engineers can help customers to portray their requirements.

An extremely useful model of user-developer communication has to be followed to bridge the gap of requirement being communicated effectively during the Requirement Engineering phase. User- Developer idea stands in conflict to traditional models, which does not involve the developers and designers in requirement gathering making the interaction between user and designer seems to exist only as a way of obtaining information that is to be passed on to the next stage of design. The user will only have vague idea about the requirements but he will have a clear understanding of what he expects from the system. With designer-user interaction it will be easy for the designer to understand what exactly the user is expecting his system to deliver and alter the requirements to meet the needs and explain the user clearly if any requirement cannot be feasible under the given constraints so that the requirement can be revised. Once the user-designer interaction is done, the designer will have clear understanding of Problem Specification (Technical specification of the system in terms understood by the developer) and Problem Description (Definition of the system in terms understood by the customer). During the user- designer interaction the user can be made a part of formal requirement validation by giving examples of the use of the system in terms of a series of interactions between the user and the system and classify functional and non-functional requirements. The user- designer interaction is very important as it emphases on the target environment in which the system will be expected to function. So, the system can be developed, tested effectively and thoroughly during the developmental phases of the product. Once the system is ready to be delivered, each system function can be traced to a corresponding set of functional requirements elicited during the user- designer interaction.

Designing a working prototype of the system before the actual system is developed is a very good idea as it highlights the features of the system specified in the requirements and the usability can be improved based on the feedback got for the prototype or few requirements can get added if the customer feels the communication is an important aspect to eliminate misunderstandings or misconceptions which arise during requirement engineering phase. During our research we outlined the importance of peer-peer communication which involves the developers and analysts who design the system so that all of them will have clear understanding of the working of the system and the developers can contradict any requirement if it’s not possible to implement it under the given set.

Communication Impact Score Template

In order to help and organization to figure out possible communication problems that might lead to poor requirements, we have proposed a Communication Impact Score Template (CIST). This template includes categories in first column (the categories we have talked about in previous sections), questions that are relevant to the organization and category, and finally the impact score which can be distributed to all categories with priority.

For an instance, If a category have high impact score, then the developer who will be filling this template have clear understanding that the problems defined in that category is negatively affecting the overall requirement engineering process. This is also a sign that, he/she thinks the communication problems linked with this category must be improved in order to maintain the quality of gathered requirements.

Figure 6.1, is a sample template assumed to be filled by an anonymous developer of an organization. He has allocated more points to Social and Organizational Issues which might be an indication that the developer is having problem with communicating with managers or colleagues and he also feels political influence is affecting the requirement engineering process.

Similarly, Figure 6.2 is the sample of Average Communication Impact Score Template, in which first column defines the category and remaining columns except the last column signifies the respective scores collected from different stakeholders within an organization. The last column gives the average score of the category assigned by stakeholders. Using this column, the organization can get knowledge about the prevalent communication related issues during requirement engineering process.

For an instance, Figure 6.2 shows that the Social and Organizational issues, Emotion and Trust issues and Language and Technology issues are communication related issues that is possibly affecting the requirement engineering process. Using this template the organization can take relevant actions based on impact scores. The communication issues related with the categories having high scores must be resolved in order to assure quality requirements engineering process.

Category Name

Questions

Impact Score (100)

Social and Organizational Issues

Were you able to communicate with your managers and other colleagues properly? Did you feel political influence inside organization?

40

Cultural Issues

Were you comfortable during meetings? If not is it affecting the RE process?

20

Emotions and Trust in Communication

Did you find lack of trust or emotional problems in stakeholders?

20

Computer Aided Communication

Did you feel use of Video Conferencing affecting the Requirements gathering?

0

Language and Technological Barrier

Did you feel uncomfortable dealing with customers because of their language and lack of technological skills?

10

Geographical Issues

Do you think that teams are unable to develop trust because they are geographically/globally distributed?

5

Domain Knowledge

Do you think lack of domain knowledge affecting current RE process?

5

Total Score

100

Figure 6.1 Sample Communication Impact Score

Category

Stakeholders in an Organization

D1

D2

D3

TL1

TL2

PM1

PM2

QA1

QA2

BM

Total

Social and Organizational Issues

40

50

50

40

40

0

20

10

50

0

30

Cultural Issues

20

10

0

10

0

10

10

0

0

30

9

Emotions and Trust in Communication

20

20

10

20

10

30

20

10

30

40

21

Computer Aided Communication

0

0

10

0

10

10

10

10

0

20

7

Language and Technological Barrier

10

10

20

15

20

30

30

50

10

10

20.5

Geographical Issues

5

0

0

0

10

20

0

20

0

0

5.5

Domain Knowledge

5

10

10

15

0

0

0

20

10

0

7

Total Score

100

Figure 6.2 Sample Average Communication Impact Score

Note: D1: Developer 1, TL1: Team Leader 1, PM1: Project Manager 1, QA1: Quality Analyst1, and BM: Business Manager

Conclusion and Future Work

In this paper, we have gathered all the issues that have impact on effective communication between stakeholders. We have tried to answer the following questions:

How can we develop a mechanism in order to help and organization to find communication related problems? How trust can be developed in order to improve communication between stakeholders and in between distributed teams?

Lack of effective communication between stakeholders lead to wrong, unnecessary and ambiguous requirements, may also lead to misinterpretation of requirements and redundant requirements and ultimately leads to high cost in the later phases of the software development cycle. This is how lack of effective communication impacts the requirement engineering process. As success and failure of the project depends on requirements, it is crucial task of requirement engineers to trace out problems which are affecting the effective communications between stakeholders accepting that communication is also a crucial part of requirement engineering process.

This paper contains categorization of all the problems regarding communication and listed them in section 6 and we have also introduced the templates that might be used in order to help an organization to find possible communication related problems within the organization. Besides that, we have also added a trust factor which affects the effective communication between stakeholders. Sometimes, the important requirements of stakeholders might not be exposed because of lacking trust between stakeholders. For instance, the end user lacking trust with developers might think that the developer won’t be able to understand and reflect his/her requirements into a real system. Similarly, for the developers or requirement engineers who do not have interest and trust in customers may think that the customers or end users do not know what they want from the system and eventually end up with wrong, unnecessary and ambiguous requirements. If the project manager or a domain expert is able to establish a trust between the end users and the developers, the effective communication is possible.

By collecting and categorizing all the issues addressed from many papers regarding effective communication, the readers or researchers can have a brief insight of the overall issues that is being addressed by the papers we have referenced so far. Categorizing the different issues can help the developers to figure out what are the problems that might hamper the overall requirement engineering process and be aware of those issues and take relevant actions.

By collecting real survey data from stakeholders of different existing organizations, we can further analyze the issues we have discussed so far. There might be other issues related to communication that is obscured and need to be addressed in order to solve the current communication problem in requirement engineering process.

The proposed Communication Impact Score Template and Average Communication Impact Score Template can be improved in order to increase efficiency of this new technique.

As we know that, software has become a part of everybody’s life. Software development is having a great evolution over time and no one knows how to write efficient software in a given time as the requirements keep changing very frequently. The traditional way of gathering requirements by the business side and working on them to develop the software is good as long as the customer is completely aware of the outlook of the system performance. If the customer is not completely aware of the system then a domain expert and developer must be part of the team that interacts with the customer to gather requirements to make the requirements clear to everyone and thereby have minimal problems in transforming them to functional requirements by incorporating to the system. If domain experts are not involved in requirement gathering then there will not be a clear idea of what to expect from the system in terms of performance, security or how the system needs to be tested to sustain the real-world performance issues.