DPP Assignment 1

DPP ASSIGNMENT 1: PROJECT PROPOSAL
Overcoming the communication barriers affecting
Software requirements elicitation.
SUBMITTED BY:
ALBERTO TELLEZ-PICON
STUDENT ID13162420
FOR:
MANCHESTER METROPOLITAN UNIVERSITY
FACULTY OF BUSINESS AND LAW
DEVELOPING PROFESSIONAL PRACTICE
January 2015

Alberto Tellez-Picon Student ID 13162420
2 of 12
1. Dissertation Title.
The proposed title for this project will be:
- Overcoming the communication barriers affecting software requirements elicitation.
2. General Purpose of the study:
It has been recognised by the literature that the success of software projects is heavily dependant on
how the end product fulfils the customer needs. (Nuseibeh, B. and Easterbrook, S. 2000). In order
to provide software that meets the user requirements, digital Project Managers have to master
software requirements engineering, which can be defined as the action of assessing the needs that a
software has to fulfil. (Ross and Schoman’s 1977). These researchers argued that the software
requirements analysis must cover: “why a system is needed, based on current or foreseen
conditions, which may be internal operations or an external market. It must say what system
features will serve and satisfy this context. And it must say how the system is to be constructed.”
Amongst others that will be analysed in the proposed project, communication has been found to be
one of the most critical factors when carrying software requirements engineering, (Coughlan, J., &
Macredie, R. D. 2002), but yet just a few researches have attempted to provide an approach to
overcome the communication barriers found on the different stages of this process, this is why the
general purpose of the study will be:
1. To analyse state of the art on software engineering.
2. To investigate how communication affects software requirements elicitation.
3. To provide a communicational approach to software elicitation techniques.
2. Literature Review and Rationale for research in this area:
Software development is a task naturally complicated and arduous given its aim, which is to made
an environment where both human and technology behaviours will have to interact (Curtis, B. et al.
1988; Yu, Eric SK 1997). As Nuseibeh, B., & Easterbrook, S. (2000:38) expressed it: “The context
in which RE takes place is usually a human activity system, and the problem owners are people.”. It
is crucial, thus, to create systems that empower the human behaviours and provide solutions to their
processes rather than making these more complex.

3 of 12
It has been said that the success of every software depends heavily on how it fulfils the needs of the
end users (Boehm, B. W. 1981; Nuseibeh, B., & Easterbrook, S. 2000). Furthermore, in order to
have a methodology to elicit, define and negotiate these specific user needs with the aim to develop
a working solution tailored to their specifications, the so called requirements engineering was born.
So it can be said that requirements engineering is the process through which the software
requirements are defined, negotiated and agreed in order to develop a software tailored to the
requestor’s needs.
Given its same nature, requirements engineering is a highly communicative process holding tasks
such as “idea generation, decision-making, and requirements conflict resolution” (Calefato, F., et al.
2012:642). All of this tasks take place between users and designers, so the process becomes even
more complicated by the fact that on one side, a high level of domain knowledge transfer has to
take place between these two groups, and second because this knowledge fluxes have to be between
people that do not know each other and come from different backgrounds, knowledge areas, and
levels; all this makes communication to be even more important on the first stages of requirements
engineering (Curtis, et al. 1988). Because of this interaction between really different individuals, it
is crucial to acknowledge that misunderstandings will be really difficult to avoid and that these will
lead to conflict. (Coughlan, J., & Macredie, R. D. 2002; Curtis, B. et al. 1988).
Furthermore, as Easterbrook, S. (1994) pointed out, when carrying the task of RE, conflict
management will have to be provided given that by the same nature of this task, the different
individuals will find many disagreements among the requirements, specifications and goals of each
software to be developed. They argue that the methodologies provided by the literature in order to
capture and negotiate software requirements take a conflict avoidance approach, let alone use
conflict as a constructive path to better understand the different points of view, requirements and
goals. They finally provide a methodology to use conflict resolution as a tool to empower relations
between the actors on RE while improving the quality of the end software specifications. This
research will follow the same approach taken by Easterbrook (1994), embracing conflict as a
positive way of improving user-developer relations while requirement engineering tasks are being
carried.
Following B.W. Boehm (1981), another characteristic that makes requirements engineering to be
one of the most critical tasks of software development is the fact that if correction of the
misunderstanding errors is done in later stages, the cost grows up to 200 times more than if found
and sorted in the first stages of requirements engineering.

4 of 12
In order to analyse the information being transferred through the mentioned individuals, it is really
interesting the approach provided by Curtis, B. et al. (1988). The different layers through which this
information has to iterate are well shown in his early study using the figure 1, with the aim on
explaining the whole communicative process:
In their study, the researchers argued that provided the requirements engineering tasks are
performed by the interaction of individuals with their teams, the project, the company, and the
software supplier, all this processes can be
considered as communication layers or barriers and,
the more people and groups involved on them, the
more complicated these communication tasks
become . These conclusions still hold valid nowadays
and will be used as a starting point for this research.
Jane Coughlan and Robert D. Macredie 2002.
Figure 1. The layered behavioural model of softwaredevelopment. Curtis, B. et al. (1988)
It is also crucial to understand the differentiation that some researchers have done on the approaches
taken on RE, depending on whether the technique is product centred or human centred, which can
also be expressed by the so called rationalistic against the user-centred perspectives; Coughlan, J.,
& Macredie, R. D. (2002). The former implies that the specifications are somehow in the
customer’s mind and the designers have to work out in order to extract them, and the latest implies
that the problem area to resolve is ambiguous and has to be defined with the joint collaboration of
user and designers. The implications of this differentiation will drive the approach taken on the
objectives, derivations of specifications, and user-designer communications, as can be seen in the
following table:
Assumptions Product Human
Goals Completed system Customer
Satisfaction
Derivation of
Specifications
Given/extracted by
the customer/user
User-designer
collaboration
Nature of user-
designer
communication
Contractual Continual
Figure 2. Differences in assumptions on product and human entered approaches. Coughlan, J., & Macredie, R. D. (2002).

5 of 12
In the same direction, research carried by Curtis, B. et al. (1988) proves that given software is
developed by and for humans, its building has to be analysed as a behavioural process. Other
studies, as an example Christel, M. G., & Kang, K. C. (1992), provide a lists of factors that
influence the process of capturing software specifications as both human and product process, such
as social constraints, architectural constraints, organisational constraints and problem-specific
factors. This literature inconsistency provides enough reasons to approach the dissertation literature
research and data analysis from a holistic perspective in order to include all possible factors
influencing the communication processes.
In order to make RE manageable the majority of the researchers have broken down this processes
into different stages: elicitation, specification, and validation. (Christel, M. G., & Kang, K. C. 1992;
Nuseibeh, B., & Easterbrook, S. 2000). Elicitation has been defined as the process that takes place
to gain an understanding of the end software goals, objectives, and scope as well as “identifying the
requirements that the it must satisfy in order to achieve these goals.” (Cheng, B. H., and Atlee, J. M.
2007:2). System specifications will be used in this research as the iterative process of defining the
details of the system requirements in order to achieve what has been agreed in the elicitation
process, which is normally captured in the specifications document; and validation can be defined
as the phase in which the stakeholders accept and formalise the systems requirements, clarify the
unclear specifications, and identify the unknown ideas. (Christel, M. G., & Kang, K. C. 1992)
Other studies have widen this list to include analysis of the existing system in which the software
will be build, (Van Lamsweerde, A. (2000, June) or to include modelling, requirements analysis,
and requirements management. (Cheng, B. H., and Atlee, J. M. 2007). Although, this processes will
be considered included in the three mentioned above.
Even though RE tasks will usually be iterative in regards of the knowledge transfer between users
and developers (Nuseibeh, B., & Easterbrook, S. 2000), their purpose is to serve as a reference
point for researchers in order to narrow the studies to be carried, and to practitioners, in order to
clearly understand which characteristics and success factors each stage has. This research will focus
in the first of this stages, elicitation, which is believed to be the most affected by the environmental
conditions and where the more volatile ideas have to be captured, hence the one where the
communication requirements are higher. (Curtis, B. et al. 1988).

6 of 12
With reference to the tools and channels used in the communication of software requirements, i.e.
whether it is done through formal or informal specifications documents, formal or informal
meetings, amongst others, there has been a fierce debate on which one is more efficient. Some
authors have said that meetings are more cost effective, (Al-Rawas, A., & Easterbrook, S. M. 1996),
others have suggested that the more complex the task becomes, the richer the communication media
has to be. (Calefato, F., et al. 2012). and that depending on whether the task is elicitation or
negotiation text or F2F communication improves. Other studies propose a more wider approach by
adding introspection, interviews, questionnaires, and protocol, conversation, interaction, and
discourse analyses methods. (Goguen, J. A. and Linde, C. 1993). Thus, there will be an attempt to
clarify which tools and channels do contribute to requirements elicitation in a more efficient way,
by comparing the literature to date, starting with the foundation on avoiding one size fits all
methodology approaches, as Benyon and Skidmore (1987) clarified in their research.
This literature review could not end without providing an overall view of the common techniques
used on requirements elicitation. Following Jane Coughlan and Robert D. Macredie (2002), these
are: MUST techniques, Joint Application Design (JAD), User-Led Requirements Construction
(ULRC) and Soft Systems Methodology (SSM). In order to understand how these are differenced,
this authors presented the following figure:
The differentiations are based on whether the
elicitation process is human centred (Used of
System) or product centred (System in use),
and whether the control of the
communications resides with the designers
or the users.
Figure 3.A classification framework for the methodologies under analysis. Jane Coughlan and Robert D. Macredie (2002)
Following a comparison between these techniques, based on parameters such as user participation
and selection, user–designer interaction or communication activities, the authors proved that “none
of the approaches make a clear statement of stakeholder participation” as well as proving that there
is a lack on field research of real life situations with the aim on analysing the user-developer or
user-analyst communication and relationship. It will serve as a ground to clarify and understand the
most used methodologies in requirements elicitation tasks and to study the communication between
these two really different groups.

7 of 12
4. Specific Objectives.
Having done the initial research of the literature, we are now in a position to say that the
dissertation principal objectives are to explore the following research questions:
- To identify and evaluate the critical factors in requirements elicitation. This will be done by
analysing the literature to date and comparing it with the results obtained in the following
objective.
- To critically analyse the communication difficulties and its causes on requirements
elicitation. This objective will be accomplished using empirical study (Interviews and
participant observation as will be explained below)
- To identify and explore a new communicational approach to requirements elicitation.
5. Limitations
As argued by Zave, P. (1997) “The subject of requirements engineering is inherently broad,
interdisciplinary, and open-ended.”. As will be shown in this study, one of the main reasons making
RE being a broad subject is that it involves people from many different backgrounds, levels and
disciplines; it is interdisciplinary because is based on the communication in-between these
members, area studied by sociology and anthropology, it is based in understanding which
difficulties these members may have in describing their own needs, which is informed by
psychology, and has many different communication channels, which is defined by linguistics.
(Bashar Nuseibeh & Steve Easterbrook 2000). It is also an open-ended discipline as technology is
ever changing so its methods to capture the requirements and specifications to be developed.
As a consequence of this, the literature research will have the following limitations:
- The amount of articles in the literature is broad. This will be overcome by limiting the research
keywords to three: requirements elicitation, communication, software development.
- Given the research is about communication, the research can become too broad, this is why the
researcher will narrow it to requirements elicitation, which, as has been explained is the first
stage of RE.

8 of 12
- The approach for data collection will be a qualitative method, through interviews and participant
observation. Given it will be done with as maximum as 5 projects the study will have the
following limitations:
- The time frame to undertake the study is limited so a detailed planning will have to be provided
and agreed with the subjects involved in the study.
- The rigour of the research will be compromised by the small sample size as well as by the fact
that the points of view of the subjects to be interviewed on it may be biased being these in the
same project under study. As Bell, T. E., & Thayer, T. A. (1976) expressed: “Memories are biased
by personal conflicts and occurrences from long after the software is implemented.” In order to
overcome this threat, an empirical study of requirements will be based on data collected during
the project through observation, so the points of view of these subjects can be compared with the
less biased point of view of the researcher; provided that in management disciplines “all research
must be biased to some degree” in order to provide good theory. Bell, E. and Thorpe, R.
(2013;25)
- Having the key subjects acceptance to be interviewed will also pose a severe risk into this
research, hence why the possibility of stoping the recording at any time during the interviews and
group observation will be offered, as well as allowing the participants to ask at any time that their
contribution to the date is erased from the study.
- In regards of the external validity of the study, which is the possibility to use its results outside
the scope of the same study, there is also a challenge provided the sample may not be
representative of the population of software professionals, (Calefato, F.,et. all 2012). But, given
the aim of this study will be to analyse individual and group interactions, it is not the intention of
the researcher to provide a whole methodology for RE but to find the critical success factors on
communication as well as providing a research directions guide.
As already mentioned, there are no current papers that describe and analyse software requirements
elicitation from a communicational perspective and neither provide recommendations for future
research and techniques to do so, although being found as one of the most critical factors when
carrying software requirements elicitation, (Coughlan, J., & Macredie, R. D. 2002). This is why the
aim of this paper will be to gather the critical factors in requirements elicitation communications in
order to contribute to the existing literature providing a qualitative approach as will be explained in
the following section.

9 of 12
6. Research Methodology
In order to achieve the proposed objectives and conclusions, a literature research will be carried
using secondary data obtained from the main databases provided on the University library, with the
aim on gaining an understanding on the common mentioned critical success factors on requirements
elicitation.
Once above information is gathered, the researcher’s aim is to do a participant observation by being
present in the meetings to elicit software specifications of each of the projects under analysis, which
will be at the beginning of each project, and at the final meeting with the customer representative.
Also, 15 interviews of one hour each will be carried with the Project Manager in charge of each
project under analysis, the developers team leader, and the user representative, with the aim of
collecting the data. All this field research will be carried at the company the researcher works for,
rentalcars.com.
As argued by Runeson, P., & Höst, M. (2009), while there are many systematic reviews and
guidelines for experiments’ conduct and reporting, only little is written on case studies and
qualitative methods in software engineering, which is one of the main reasons that this research will
use these methods, with the intention to be innovative.
Another main reason for adopting a qualitative approach is the chosen topic nature. Since the
objective of the research will be studying the communication between individuals, which is a
human way of transferring information through many channels, cues and signals, the methodology
has to allow all this information to be captured and analysed; in other words, “The analytical
research paradigm is not sufficient for investigating complex real life issues, involving humans and
their interactions with technology.”, Runeson, P., & Höst, M. (2009), hence the best way to capture
this information is by providing an ethnological attitude by carrying a field study of 5 projects.
The interviews will be semistructured or open ended. The main reason for using this type of
interviews is to allow participants to provide their own insight on the project, approaching it with a
holistic perspective, in order to collect all possible details, providing though a guideline of the
interview and specific time to answer each of the questions; some questions included in these
interviews may follow this approach:

10 of 12
Project Manager and Developer Team Leader Interviews:
1. What are the main issues you have come across when eliciting software requirements in your
last three projects?
2. Which would you say are the most critical success factors when carrying requirements
elicitation tasks? What do you consider about communication?
3. Do you approach elicitation requirements from a product or human point of view?
4. What channels do you normally use on requirements elicitation?
5. Do you use any specific technique?
6. Do you consider conflict to be a challenge or an opportunity? How do you manage software
requirements conflict between developers and customer?
User Representative Interviews:
1. Which were the main issues you came across when capturing and agreeing software
requirements in the project?
2. Which would you say are the most critical success factors when carrying requirements
elicitation tasks? What do you consider about communication?
3. Did you consider your requirements where delivered?
4. How the end product satisfied your expectations?
5. Did you feel the channel used for requirements elicitation was the correct one?
6. Did you have any conflict during requirements elicitation?
Once the data is collected by carrying the field study, and the literature research is performed, an
existing requirements elicitation methodology will be picked among the ones mentioned above;
MUST techniques, Joint Application Design (JAD), User-Led Requirements Construction (ULRC)
or Soft Systems Methodology (SSM). Once the communication critical factors on software
elicitation have been collected also using the literature, these will be compared with the chosen
methodology. The aim of this practice will be to have a framework/benchmark with which to
compare the results obtained in the field study, with the aim on the third objective of this
dissertation: identify and explore a new approach to requirements elicitation, alongside providing
recommendations for future research, which will have to take place in order to prove the efficiency
of these.

11 of 12
7. Bibliography.
- Achimugu, P., Selamat, A., Ibrahim, R., & Mahrin, M. N. R. (2014). A systematic literature
review of software requirements prioritization research. Information and Software Technology,
56(6), 568-585.
- Al-Rawas, A., & Easterbrook, S. M. (1996). Communication problems in requirements
engineering: a field study. National Aeronautics and Space Administration.
- Benyon, D., & Skidmore, S. (1987). Towards a tool kit for the systems analyst. The Computer
Journal, 30(1), 2-7.
- Brynjolfsson, E., & Hitt, L. M. (2000). Beyond computation: Information technology,
organizational transformation and business performance. The Journal of Economic Perspectives,
23-48.
- Calefato, F., Damian, D., & Lanubile, F. (2012). Computer-mediated communication to support
distributed requirements elicitations and negotiations tasks. Empirical Software Engineering,
17(6), 640-674.
- Cheng, B. H., & Atlee, J. M. (2007, May). Research directions in requirements engineering. In
2007 Future of Software Engineering (pp. 285-303). IEEE Computer Society.
- Christel, M. G., & Kang, K. C. (1992). Issues in requirements elicitation (No. CMU/SEI-92-TR-
12). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.
- Coughlan, J., & Macredie, R. D. (2002). Effective communication in requirements elicitation: a
comparison of methodologies. Requirements Engineering, 7(2), 47-60.
- Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large
systems. Communications of the ACM, 31(11), 1268-1287.
- Damian, D. E. H., Eberlein, A., Shaw, M. L., & Gaines, B. R. (2000). Using different
communication media in requirements negotiation. IEEE Software, 17(3), 28-36.
- Easterbrook, S. (1994). Resolving requirements conflicts with computer-supported negotiation.
Requirements engineering: social and technical issues, 1, 41-65.
- Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. RE, 93, 152-164.
- Nuseibeh, B., & Easterbrook, S. (2000, May). Requirements engineering: a roadmap. In
Proceedings of the Conference on the Future of Software Engineering (pp. 35-46). ACM.
- Ross, D. T., & Schoman Jr, K. E. (1977). Structured analysis for requirements definition.
Software Engineering, IEEE Transactions on, (1), 6-15.

12 of 12
- Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in
software engineering. Empirical software engineering, 14(2), 131-164.
- Van Lamsweerde, A. (2000, June). Requirements engineering in the year 00: A research
perspective. In Proceedings of the 22nd international conference on Software engineering (pp. 5-
19). ACM.
- Verburg, R.M., Bosch-Sijtsema, P. and Vartiainen, M. (2013). “Getting it done: Critical success
factors for project managers in virtual work settings” International Journal of Project
Management 31 (2013) 68–79.
- Yu, E. S. (1997, January). Towards modelling and reasoning support for early-phase
requirements engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE
International Symposium on (pp. 226-235). IEEE.
- Zave, P. (1997). Classification of research efforts in requirements engineering. ACM Computing
Surveys (CSUR), 29(4), 315-321.

DPP Assignment 1

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (7)

Similar to DPP Assignment 1

Similar to DPP Assignment 1 (20)

DPP Assignment 1