Communication And Stakeholder Issues In Requirement Engineering Information Technology Essay

Requirements Engineering starts with requirements elicitation. Requirements elicitation is a process of discovering, obtaining and expanding requirements for adopting a computer-based system. Requirements Elicitation process is challenged by different factors. After our research, we found poor communication and stakeholder issues are the most common factors which results the blockage of user’s needs. It is one of the most critical issues in RE which causes the delay and failure of the software projects. [1]

Unsurprisingly, effective communication is very hard to achieve and is a repeating problem in the elicitation of requirements [2]. There are several reasons for less effective communication (i.e. different time zones, cultural differences, lack of awareness etc.)

Wahab Hussain (Author)

MS. Software Engineering (Reg. # 1071112)

Shaheed Zulfiqar Ali Bhutto Inst. of Science & Tech.

Karachi, Pakistan

The two major sections discussed in this research paper are:

Communication issues in Requirements Engineering – Section 4

Stakeholder issues in Requirements Engineering – Section 5

Later in Section 5, Conclusion is presented.

Why Requirements Gathering

We gather requirements to cut down the risk of common mistakes that grow from the lack of communication or understanding. We can discover real requirements if requirements gathering activity is approached in an organized way (we know who the stakeholders are likely to be and what kind of questions we need to ask from them). [3]

Developing software and constructing building sounds similar. Let’s take an example of constructing hotel instead of developing software. Don’t you think that before starting foundation, you should have the complete design and architecture of the hotel that how it’s interior and exterior looks like after completion? Of course you would. In the same way in developing software, you gather requirements before the start of the project and looks into the architecture (i.e. ERD, class diagram, state diagrams, component diagrams etc) in more detail. While building a hotel, you go into several inspections to make sure the work carrying forward in the right direction or not (like we have inspections in software projects to ensure the requirements). [4]

The other similarities between developing software and constructing hotel in terms of roles as listed in Table 1:

Developing Software

Constructing Hotel

Project Manager

Contractor/Builder

Resources

Developers

SQA/Test Engineering

Technical Writers

Resources

Electrician

Carpenter

Painter

Plumber

Problem Formulation:

Communication between the system analyst and stakeholders can be described in term of communication between two parties as shown in Figure 1. [1]

Four components are involved in this type of communication as shown in Table 2. [1]

Communication issues in Requirement Engineering

As discussed in previous sections that the major cause for the project failure is the lack of effective communication. Mostly errors in the software system are due to poor communication. There are several reasons; sometimes the customer is unable to communicate the proper application knowledge to the analyst, sometimes development is done on Ad hoc basis due to unavailability of requirement document, sometimes requirement document is too long that no one can be able to read it completely. These all causes conflicts, confusions, false impressions and inconsistency in work.

The main communication issues faced in Requirements Engineering are as follows:

Problems “within” User

The “within” roadblock is basically the individual culture limitation. It relates the behavioral boundaries within the individual users. In “within” problems, user fails as an information receiver, information processor and problem solver. [5]

Problems “Between” Users

The “between” roadblock is basically the organizational culture concerns with the interaction between customer and analyst. Every organizational culture is different from other organization (i.e. nature of work, organization hierarchy, management style and terminologies used within the organization) so confliction possibly will grow because business analyst perhaps may not familiar with the hierarchy of the organization and their operations. [5]

Problems “Among” the users

The “among” roadblock is basically the national culture limitations. In large complex system, people with different cultural backgrounds are involved having different languages, difference in attitudes and judgments and priorities. Problems occur when different users express their needs that are incompatible or invalid or conflicts either in contents or priority and they want a reviewer for resolution. [5]

Requirement conflicts increases when several users present the same information in different and inconsistent manner. It is the demanding situation for the development organization to resolve such issues. [5]

One Way Communication Channels

In one way communication, we used to express information within the development team and with different stakeholders. In this way, the channel of communication sounds effective because all knowledge is shared but it results expensive and time consuming to support wide range of communication between professions. As per research, it looks that requirement specification document is the only way of communication between the development team and stakeholder. [6]

The Notations War

It is often difficult for the customer and development team to understand each other terms/notations (i.e. Business analysts and software engineers prefer to talk about the system in terms of it procedures and data structures, end users prefer to talk about the system in terms of its general behavior and functionality of software system). This causes the unfamiliarity of various people with various notations. For example, a customer must not want to learn formal specification language, but the programmer may require these to obtain an appropriate level of detail. [6]

Organizational Barriers

Requirement Engineering activities and software design activities are carried out separately. Each activity is discussed and presented by different sets of people. Requirement Engineering meetings include business analyst, developers SQA engineers and end uses. While in design review activity, end users are not included. Only development team is limited in design review activity because no one from outside organization is allowed to attend this activity. [6]

Informal Communication

Informal communication is usually used when face to face conversation is required with a friend. It is based on common interests and combined relations creating channels through which information is collected easily. Informal communication channels can be destroyed by rivals who can discourage the joint action which affect the normal flow of information. Telephonic conversations are also a part of informal communication but it is the least used method in exchanging information between the two professions. Such informal communication proved to be expensive and results time consuming discussions and meetings. [6]

Nevertheless, there is no specific support for informal communication for software projects in the early phase of Requirement Engineering because in many cases business analysts and customers meet for the first time. [6]

Traceability Problem

Requirements Traceability is critical for all phases of SDLC to help concluding requirements and justify changes. The research shows that traceability problem is very serious in the later stages of RE (i.e. requirements review) when late requirements are brought in the project life cycle. Now it is necessary to re-establish communication with team mates in order to avoid conflicts with newly introduced requirements with existing one. This is very challenging and difficult because by this time business analyst may have halted or may have started working on any other project while programmers moved to later phases of the project. [6]

Communication challenges representing through Quadrant Model in RE

Refer Figure 2 which shows communication challenges taken from Davis et al. [14]

Quadrant (a) correspond common knowledge between analyst and user. Quadrant (b) correspond knowledge that the user has but the analyst does not. It looks that there is unique business model of the user business. Quadrant (c) correspond that the analyst has the knowledge but user does not yet. The analyst would be looking for to teach the user. Quadrant (d) correspond new knowledge that will be produced from the interaction between analyst and user. It looks that analyst asks questions and tries to dig more information from the user. [14]

Stakeholder issues in Requirement Engineering

Stakeholder plays the most important role in the acceptance of a software product. After having research, we found there are different observations of who the stakeholders are? [11] Stakeholders are individuals or organizations who affect or are affected by the software product. In other words, a stakeholder is a person who has a power to develop requirements. Identifying the stakeholders and getting them involved in the Requirements Engineering process helps to make complete set of requirements early in the software development life cycle. [7]

The stakeholders can be categorized in three main parts which are: [7]

The acquirers of the software product (who are customers and users/end-users)

The suppliers of the software product (includes individuals or teams that develop the software product or part of the organization who are business analysts, designers, developers, testers, documentation writers, project managers and technical support)

Other stakeholders (there are also other stakeholders who are interested in requirements are: Legal or contract management, Manufacturing or product release management, Sales and Marketing, Upper management and Government or regulator agencies)

Table 3 summarizes the different ambitions and interests to different stakeholders in a RE process. [8]

Stakeholder

Ambitions and Interests

Requirements Engineer

Wants a tool that makes their job easier, more satisfying and more productive.

Customer/User

Wants usable system, with fewer errors.

Project/Process Manager

Wants to deliver on time with the right specification quality

Quality Manager

Wants to ensure that the delivered system specification is error-free.

Senior Management

Wants to see a return on investment and increased productivity.

Requirements from all stakeholders are important; we can not ignore the requirement of any stakeholder but we can prioritize them.

There are many stakeholder issues in Requirement Engineering which cause the project failure: [9]

Stakeholders don’t know what they really want.

Stakeholders convey requirements in their own terms.

Requirements may conflict in case of different stakeholders.

Organisational and political factors may effect the system requirements.

The main stakeholder issues faced in Requirement Engineering are as follows:

The “Yes, But” Syndrome

The “Yes, But” syndrome is simply human nature and the user’s ability to experience the software. The “Yes, But” syndrome is the frustrating and the most occurring problem in all of application development. It is observed in user’s reactions for every piece of software developed. As per research, there are two immediate and different reactions when the users look the software functionality for the first time which are: [3]

“Wow, this is so cool; we can really use this, what a neat job,” and so on.

“Yes, but, hmmmm, now that I see it, what about this . . . ? Wouldn’t it be nice if . . . ? Whatever happened to . . . ?”

The “Undiscovered Ruins” Syndrome

In Undiscovered Ruins syndrome, “the more you find, the more you realize still remain”.

It seems that the search for requirements is similar to a search for undiscovered ruins. No one feels confident as he/she has done with all the requirements or not, and possibly you never will. Without a doubt, development teams always struggle to determine when they are in requirements elicitation process; the requirements which are available are enough; whether they have found all the requirements or when have they found at least enough? [3]

The “User and the Developer” Syndrome

Communication gap grows between the developer and the stakeholder. In many cases, developers and stakeholders are from different parts of world, may have different backgrounds and objectives and may even speak different languages. [3]

The problems are: [3]

Users do not know what they want, or they know what they want but they are unable to express to developers.

Analysts think they understand user problems better than users do.

Users have trust to themselves. They know what they want, and when functionality is handed over to them, they claim what they said they wanted?

The “Living with the Sins of your Predecessors” Syndrome

Stakeholder and developers remember what happened in the past. Issues appear every time after the end of release. And then the development team and stakeholders sit together and ensuring trust with each other and make sure that existing issues will not arise in next release. The team prioritize the requirements and cut down the features which are less important. Try to build trust slowly. But after sometime, there is a huge pressure from stakeholder that he wants i.e. XYZ features in upcoming release. And from here the problem starts, the release delivered consist unclear requirements and short of expectations. [10]

Introduced new stakeholders during analysis

Requirements change during the analysis process is very common. After requirements gathering, analysis phase starts. During analysis, new stakeholders may be introduced which results the change in the business environment.

Other challenges concerning stakeholders

There are some very common challenges. These challenges are faced by those stakeholders who are technically weak. The problems are: [12]

Users don’t have a clear vision of their requirements.

Different vision of the system under development [13].

Users are not very capable to participate in reviews.

Communication with users is slow.

Users don’t understand the development process.

Users don’t know about present technology.

Users are not wise in the ways of the world/unsophisticated. Too honest to promise more than he could deliver.

Different involvements of stakeholders. For example, some stakeholders are allowed to make decisions and others aren’t [13].

Conclusion:

The focus of this research paper was to find out the communication and stakeholder problems in requirement engineering. After having literature review and research, we have identified the most important communication and stakeholder problems faced in RE.

It is found that lack of understandability is the root cause of all other problems, and poor communication is the first step towards project failure. These problems are significant important because they are related to stakeholders and stakeholders have various other limitations while expressing their needs. Beyond all these issues, there are also applicable solutions presented to get over these problems.