Communication in Requirement Acquisition of Software Development

About me

INTRODUCTION

The software industry is one of the fastest growing industries around the world today and there has been much research carried out in order to cope with the complications resulting from the abstract nature of software. Increasingly, the term 'Software Development Lifecycle' (SDL) is becoming very popular in the computing world. According to Maciaszek and Liong (2005, p.5), SDL refers to the alterations that occur in the life of the software. It consists of five main phases. They are requirements analysis, system design, implementation, integration and maintenance (Maciaszek & Liong 2005, p.5). Each phase has its own complexity and discipline. However, it is commonly believed that the first phase, requirements analysis, is extremely critical to the development of a project because it provides input to the subsequent phases.

Sommerville (2007, p.118) defines the word 'requirements' as the description of the system-provided services and its operational constraints. From that, he identifies that requirements analysis encompasses the activities of eliciting, analyzing, documenting and validating the services and constraints. The first activity is more user-oriented but the others are more skill-oriented. It means that communicating with users is dominant in the elicitation activity and the other activities mainly focus on the skills of software developers (SDs).

There have been a great number of engineering books written and much research carried out on the methodologies for SDs to improve their technical skills. In contrast, there is only a small amount of research on the methods to improve SD's communication skills. Generally, it might be believed that the success and failure of a certain project is the responsibility of the Software Company. Yet, to a certain extent, it is also the responsibility of the customers who order the software. The reasons are that SDs cannot presume what the customers need and they cannot develop a complete system without knowing the customers' expectations. Hence, the communication between customers and SDs is very important. However, this factor is often ignored and left for SDs to deal with. Therefore, it is worth considering this aspect in SDL. The scope of this paper does not allow for discussing regarding the techniques to elicit users' requirements. Rather, this research will focus on addressing the following questions:

1. What are the common problems that lead to a low level of SD's communication skills?
2. What are the possible solutions for those problems?

With the combination in comprehending the common problems and the possible solutions, a better skill in dealing with the customer in order to deeply understand the software requirements can be achieved.

LITERATURE REVIEW

There is a very strong connection between requirements elicitation and communication. Sommerville and Sawyer (1997, p.63) state that the process of using communication with software-involved users such as customers to identify requirements for software is referred as 'requirements elicitation'. Therefore, communication seems to play a very important role in the whole process of SDL. According to Sommerville and Sawyer (1997, p.2), most of the problems that can lead to the decline or failure of a system are associated with identifying software requirements. They also suggest some of the common problems: (1) the real needs of the customers are sometimes ignored, (2) the inconsistency and incompleteness of requirements can occur, (3) changes to requirements would be very expensive after they have been agreed and (4) misunderstandings between customers and SD can happen. It is likely that all the problems mentioned above are caused by the lack of communication or communication breakdown. In some cases, the impacts of the problems can be so significant that the whole project might collapse. Hence, it is almost certain that finding solutions for those problems is of importance.

Communication can improve the quality of software. Strano, Mohan and McGregor (1989, p.6) define communication as 'the sharing of information, ideas or attitudes between or among people' and it is obvious that the software requirements are the 'information, ideas or attitudes' that SD must obtain from the customers. Hence, if SDs can communicate effectively, the objectives for the software being developed can be fulfilled. In addition, Christensen and Thayer (2001, p.406) claim that 'Communication is the key to keeping the project moving in the right direction'. In other words, effective communication is the most important factor that can ensure the success of a project. The reason for this could be that it ensures the clarification of what is expected by the customers.

SD's PROBLEMS IN COMMUNICATION

In discussing 'Overcoming Communication Barriers Between People', Hahn (2005) suggests the common barriers in communication are different points of view, background differences, poor listening, distorting filters, language problems and differing emotional states. However, the suggestions for the communication barriers (CBs) are mentioned in normal daily circumstances. It is advantageous to study to what extend the barriers can influence the development of a software. In addition, at the time this paper is conducted, there might be no books or research that addresses these suggestions in the software industry so the following ideas related to these CBs will be presented from a personal view.

First, differences in viewpoints can be detrimental to software development and this problem is becoming more serious as the trend of outsourcing continues to flourish. Customers would have different perceptions if they come from different cultures. Hence, SDs should take this into account; otherwise software cannot be implemented properly. Furthermore the background differences between SDs and customers also attribute to the difficulties in communication. For instance, a stock trading company can demand stock software that requires SDs to have certain levels of relevant knowledge in order to develop it. When SDs are trying to interview the user from the company, they can misunderstand what the user require because the language they use is different from the language of the user. Moreover poor listening can result in CBs. It might be known that SDs usually pride themselves on their high technical knowledge and this is really an impediment to any conversations between SDs and normal users. As can be seen, this factor can lead to the SD's presumption of the user's expectation. However, the fact that SDs might not have enough knowledge will cause many misconceptions in developing the software. Another CB is twisting filters. This barrier might be created when indirect communications occur. For example, when the information from customers is reported by secretaries to the project manager, the differences in viewpoints or the insufficiency in the understanding of the software being developed of the secretaries can distort the information regardless of their efforts to present it correctly. Besides the CBs mentioned above, it is also important to consider the problem of using language. Given the same word, different regions can have different meanings, especially for those who do not speak the same language. It would raise serious misunderstandings between SDs and their customers. Finally, the effectiveness of communication can be affected by emotional states. Strano, Mohan and McGregor (1989, p.10) state that provoking unfriendliness in the other participants of a conversation can be the cause of distorting messages. Another example is dealing with upset people. They tend to ignore or distort what the other person is expressing and is usually unable to present feelings and ideas properly. It does not mean that all of the communication should be abandoned when the emotional state of the customers or SDs is not appropriate but it does mean SDs have to be aware of what is behind the conversation between them and the customers.

SOLUTIONS

Right People

Selecting right people is very crucial to the success of any communication. The reason could be the credibility of each participant. For example, when developing stock software, obtaining the software requirements from a user with more than ten years of work experience is more reliable than from a user with no work experience. The degree and the specific factors attributed to the required credibility vary depending on the software being developed. Because the aim of this paper is not to improve the technical skills of SDs, the methods to identify right people will not be addressed. However, there are many books written to address this aspect; for instance, Thayer and Dorfman (1990, p.489) suggest a list of criteria for selecting right people depending on the context and the functions of the software. In discussing how to improve the quality of software, Barkley and Saylor (2001, p.276) mention if the sender is not credible, regardless of the information, communication will be ineffective. It is likely that the users chosen to obtain the software requirements have a significant impact on the communication. Because of their credibility, the SDs would feel encouraged to absorb more information. Hence, this solution seems to be able to resolve all the indicated problems.

Listening and Empathizing

Listening is critical in eliciting the user's requirements. However, it might be the least developed skill for SDs. The reason could be the high esteem of SDs. The real expectations of the user can be ignored if the SDs assume that they know all the concepts of the software. The fact that SDs assume that they know all the concepts of the software can lead to the ignorance of the real expectations from the user. Barkley and Saylor (2001, p.277) suggest the requirements of effective listening can be letting others convey their ideas without interrupting and empathizing with their point of view. The second requirement 'empathizing' could also be a solution to the differences in background between SDs and normal customers because it helps SDs try their best to understand customers' viewpoints from different perspectives.

Two-way mode for sharing knowledge

As indicated, one of the common problems in communication is the barriers in language and background of SDs and the customer. It seems, therefore, reasonable to encourage SDs to have two-way communication with the customer. In other words, the process of finding requirements  is not only asking the customer for information but also a real conversation where SDs and the customer exchange their knowledge in order to have a common understanding of the software. In discussing 'Communication on Agile Software Projects', Ambler also agrees on the idea to have 'two-way street' for sharing information to have effective communication. Hence, this way of sharing knowledge is not a new idea but it might be often misconceived by SDs that finding the user's requirements is only asking questions to the user. In addition, this method can also be a solution to the differences in viewpoints because it assists SDs in finding the gaps in understanding between them and the user, especially when the differences in cultures can become an issue in communicating.

Constant review

Misunderstandings always occur no matter how SDs try to overcome. It is applied to not only software development but also normal daily conversations. With regard to this fact, constantly reviewing and clarifying what has been communicated appear to be one of the best solutions to improve the process of eliciting the user's requirements. By identifying the discrepancies between the SD's understanding and the user's expectation, it seems to be able to solve all the common problems discussed above. Kishore and Naik (2001, p.114) cite in the Walkthrough method, one of the review methods, SDs 'walk' the user through the software's prototype and explain each requirement. From the explanation, it appears to be possible for both SDs and the user to discover any differences in the expected system. Kishore and Naik (2001, p.114) also encourage SDs to review the requirements obtained from the user constantly.

CONCLUSION

Communication plays an important role in software development, especially in the requirements elicitation phase. Indeed, the improvement in communication skills can assist SDs in understanding the system requirements from the user. However, due to the barriers discussed in this paper, it is a difficult mission to be accomplished. There are four possible solutions for those barriers. They are selecting right people, listening and empathizing, sharing knowledge in a two-way mode and constant review. The implementation of these solutions can lead to the improvement of the communication between SDs and the customer, thereby improving the quality of the software being developed.

FURTHER RESEARCH

Communication comes in many different forms. It includes verbal and nonverbal forms such as speaking, writing, reading, listening and body language. Because of this complexity, it is very difficult to cover all the possible solutions to improve communication in this paper. Further research can investigate into the solutions for the situations in which misconceptions have happened. In other words, it is important to find a way that can assist SDs in preventing further misconceptions to recur.

REFERENCES

Ambler, SW 2009, Communication on Agile Software Projects, viewed 15 December 2009, <http://www.agilemodeling.com/essays/communication.htm#EffectiveCommunication>

Barkley, BT and Saylor, JH 2001,Customer-Driven Project Management: Building Quality into Project Processes, McGraw-Hill, USA.

Christensen, MJ & Thayer, RH 1947, The Project Manager's Guide to Software Engineering's Best Practices, Angela Burgess, USA.

Hahn, M 2005, Overcoming Communication Barriers Between People, viewed 15 December 2009, <http://ezinearticles.com/?Overcoming-Communication-Barriers-Between-People&id=119628>.

Kishore, S & Naik, R 2001, Software requirements and estimation, Tata McGraw-Hill, New Delhi.

Maciaszek, LA & Liong, BL 2005, PRACTICAL SOFTWARE ENGINEERING : A Case Study Approach, PEARSON Education, US.

Sommerville, I 2007, Software Engineering, 8^th edn, Addison – Wesley, USA.

Sommerville, I and Sawyer, P 1997, Requirements Engineering: A good practice guide, John Wiley & Sons Ltd, England.

Strano, Z, Mohan T & McGregor, H 1989, Communicating, Harcourt Brace Jovanovich Group, Australia.

Thayer, RH & Dorfman, M 1990, System and software requirements engineering, IEEE Computer Society.