=Paper=
{{Paper
|id=Vol-1374/paper1
|storemode=property
|title=Teaching an Ethnographic Approach to Requirements Elicitation in an Enterprise Architecture Course
|pdfUrl=https://ceur-ws.org/Vol-1374/paper1.pdf
|volume=Vol-1374
|dblpUrl=https://dblp.org/rec/conf/caise/RegevRNLW15
}}
==Teaching an Ethnographic Approach to Requirements Elicitation in an Enterprise Architecture Course==
https://ceur-ws.org/Vol-1374/paper1.pdf
Proceedings of STPIS'15
Teaching an Ethnographic Approach to Requirements
Elicitation in an Enterprise Architecture Course
Gil Regev1, Laura Regev2, Yasmina Naïm2, Julie Lang2, Alain Wegmann1
1
Ecole Polytechnique Fédérale de Lausanne (EPFL),
School of Computer and Communication Sciences
CH-1015 Lausanne, Switzerland
{gil.regev, alain.wegmann}@epfl.ch
2
Student at University of Lausanne,
Faculty of Social and Political Sciences
CH-1015 Lausanne, Switzerland
{laura.regev, yasmina.naim, Julie.lang}@unil.ch
Abstract. Requirements elicitation is an important part of information systems
development. It is often performed as a technical task, but from a close look it
is mainly a social activity. The main work consists of interacting with stake-
holders in order to understand their work practices and how these would change
with the introduction of a new IT system. Engineers are often not trained in the
necessary social skills. Most elicitation techniques focus on the technical issues
rather than the social issues. In this paper we describe a trans-disciplinary col-
laboration in which students of social sciences help to explain the ethnographic
approach to Master’s students in an Enterprise Architecture course taught in an
engineering school.
1 Introduction
Requirements elicitation for the purpose of introducing a new IT system in an organi-
zation requires a detailed understanding of existing work practices, how these practic-
es will change with the new system and what features the system must exhibit to
support the new practices. Researchers who have studied elicitation techniques have
concluded that observation of work practices is the best way to uncover these details
[3, 21]. Despite this knowledge, IT engineers mostly rely on interviews and work-
shops, elicitation techniques that are known to produce abstract, superficial under-
standing. They are seldom trained in observation. Despite the early use of Ethnogra-
phy techniques in Requirements Engineering as reported in [8, 9, 21] and their early
consideration as basic elicitation techniques [6, 15], they are hardly known by IT
engineers. They are mostly confined to usability studies and Human Computer Inter-
action (HCI) research, with some work still being done for elicitation, e.g. [18].
We believe that IT engineers can greatly benefit from techniques that have been
developed in the social sciences. In this paper, we describe our experience in inviting
students of social sciences to teach ethnography techniques to IT engineering students
at Ecole Polytechnique Fédérale de Lausanne (EPFL). This was done in the require-
ments elicitation part of an enterprise architecture course called Enterprise and Ser-
vice Oriented Architecture (ESOA) [16, 17]. In Section 2 we give a quick overview of
©Copyright held by the author(s) 5
Socio-Technical Perspective in IS Development
the ESOA course. In Section 3 we describe the ethnographic techniques we used. In
Section 4 we explain the lessons we learned from this experience. In Section 5 we
reflect a bit on the possible use of ethnographic techniques in IS development. In
Section 6 we conclude the paper and formulate future actions we believe need to be
taken.
2 The ESOA Course
The first and last authors of this paper (whom we call the teachers) joined academia in
the 1996-1997 academic year after spending many years in industry. One of their first
preoccupations was to design a course that would give the engineering students a feel
of what it would be to do an IT project in a real company. Back in 1997, the teachers
have embarked on a first attempt to teach the messy aspects of IT system develop-
ment in a course called “Information Systems” [16, 17]. Sensing that it is impossible
to teach these kind of aspects using the traditional lecture style, they began experi-
menting with a business game and role-play as pedagogical devices. Both business
game and role-play were centered on the case of a fictitious airplane engine manufac-
turer. The role-play was designed to attract the students’ attention to observation as
the best way to elicit requirements from stakeholders [17]. A new course was offered
in 2007 as a full enterprise architecture course. Today, the course is made of three
distinct modules: (1) Business game; (2) Requirements elicitation; (3) Architecture
and prototyping, see Figure 1. This has changed from the structure we had in 2007
and 2008 as described in [17]. The course lasts for one semester, 14 weeks, each aca-
demic year with 6 hours in two separate sessions each week.
Figure 1 The ESOA course structure
The pedagogical method used in the course is experiential learning as proposed by
Kolb [12, 17]. Kolb’s experiential cycle has 4 dimensions Concrete Experience, Re-
flective Observation, Abstract Conceptualization and Active Experimentation. In the
ESOA course we call these dimensions role-play, Debrief, Theory and Preparation for
next role-play. We use this pedagogy mostly in modules one (business game) and two
(requirements elicitation). In module two, the engineering students must define the
requirements for an IT system that the company they work for (the fictitious airplane
engine manufacturer) desperately needs to get out of deep financial troubles. The
teachers and several teaching assistants play roles in the simulated company such as
Investor in the company, CEO, CIO, COO, airplane repair mechanic, shipping clerk,
sales representative, air club president and pilot from whom the engineering students
must elicit the requirements for this IT system.
Edited by S. Kowalski, P. Bednar and I. Bider 6
Proceedings of STPIS'15
It is in this module two that we teach the ethnography techniques. Until 2013 the
teachers used Contextual Inquiry [3, 8] as a set of observation techniques. Contextual
Inquiry is a well-known method for eliciting requirements by observing users in their
context of work, doing what is called contextual interviews. It is based on ethnograph-
ic observation techniques. It can be seen as light ethnography for engineers.
In 2013 the teachers invited students of social sciences to present an ethnography
method to the engineering students. In-line with the experiential pedagogy, this
presentation is given after the students have done their contextual interviews, so that
the students can better understand the theory after having practiced it. The presence of
the social sciences students inspired us to change the requirements elicitation part of
the course so that the social sciences students now coach the engineering students
when they redo the contextual interviews.
The teachers set up the role-play so that initially the students do normal interviews
of the company’s top management (CEO, CIO, COO), collecting some information
about the problem the company is facing. They then have to formulate a solution in a
hurry and present it to an investor. The investor asks them for more concrete exam-
ples, the root cause of the problem, and a description of the complete process. After
debrief of this session, the students understand that they need to do observation in the
field to really understand the problem and formulate a relevant solution. The teachers
then present them with the Contextual Inquiry method [3, 8] that they put into practice
during the next session of the course. In this session they do observation of the com-
plete process, as proposed by the investor. The observation brings together people
who are directly involved in the maintenance of the airplane engines, which is where
the company loses most of its business.
The role-play is done to be as close as possible to what happens in practice in a
normal repair process, albeit a dysfunctional one. As we described in [17], the process
is played-out in real-time. Each role played by one of the teachers or a teaching assis-
tant resides in a different room. The students must split their groups so that they have
at least one person observing each role. Each teacher or teaching assistant playing a
role is dressed for that role and has a surrounding that fits the role. The pilot has a
pilot hat and comes frequently to the air club president asking for the airplane. The
president responds by frequently calling the repair shop to inquire about her airplane.
The mechanic attempts to diagnose the problem with the engine and to obtain a spare
part from the manufacturer. The repair shop is simulated with LEGO bricks showing
airplanes, cars, motorcycles and other vehicles in different states of repair, much like
you would see in any shop (see Figure 2). Everybody is frustrated by the delay in the
repair. A very general script was written for each role so that much room exists for
improvisation. In this way, the role-play is somewhat different each year and much
unexpected things happen.
©Copyright held by the author(s) 7
Socio-Technical Perspective in IS Development
Figure 2 The simulated mechanic in his simulated shop
Through the years of teaching this course and interacting with numerous students,
the teachers have identified several beliefs that are shared amongst most engineering
students: All problems have a technical solution; Stakeholders know what the prob-
lems are, they need us to identify the solution; Stakeholders give us facts about a
situation; There is no need to take notes during interviews, we will remember every-
thing later.
Inviting the social sciences students to the course was a major part of our on-going
preoccupation with addressing these issues. In the following section we describe the
ethnographic techniques that were explained in the course to enrich Contextual In-
quiry from the point of view of the social sciences students.
3 Ethnographic techniques
Ethnography, as practiced today, was, partly, conceptualized by Bronislaw Malinow-
ski [13]. According to him, useful data could only be acquired in the field, and not in
secondhand accounts. For Malinowski, interpretations must be “informed” by “actual
experiences” [13 p. 3]. It is also important to specify how this information has been
collected. Moreover, the reader has to be able to “draw the line between, on the one
hand, the results of observation and of native statements and interpretations, and on
the other, the inferences of the author…” [13 p. 3].
The methodological tools that have been developed in ethnography enable their us-
ers to understand specific social phenomena. A substantial part of the theoretical
material described here and in the ESOA course were taken from a Bachelor course
taught at the University of Lausanne (UNIL) on ethnography methods1. This course
taught a sociological approach to ethnography, which includes the writing of synthe-
sis and the search for patterns.
The ethnographical method is, originally, based on observation and the description
of social interactions and discourse. During the ethnography course taken by the so-
1
This course is called “Approches ethnographiques de la culture et des médias” and is taught
by Philippe Gonzalez at the University of Lausanne.
Edited by S. Kowalski, P. Bednar and I. Bider 8
Proceedings of STPIS'15
cial sciences students, they experimented with what engineers would call long-term
observation of social phenomena that funnily enough is called a short-term fieldwork
(about 2 months). This short-term study helped them to better coach the engineering
students in the ESOA course.
3.1 The reflexive position of the ethnographer
To accurately observe and describe social situations, the ethnographer must pay atten-
tion to her position in the field. This analysis is called the reflexive position of the
ethnographer. The way the ethnographer is introduced in the field, the way she talks
and behaves have significant effect on her relationship towards the people in the field
and the data the ethnographer will be able to have access to. For example, Lila Abu
Lughod, in a study of a Bedouin society in Egypt, was introduced as the “daughter of
an Arab and a Muslim” [1 p. 140], and not as an American woman, though both were
true. This had much influence on the way she was perceived by her neighbors in the
village: she was considered as an insider to the group, which came with advantages
and disadvantages, as she had access to information that ethnographers considered as
‘outsiders’ could not have, but also left her with a sense of awkwardness as she had to
‘hide’ a part of her identity to her interlocutors.
This example shows that the ethnographer has to reflect upon his status in the field,
as it gives her indications about the way she was considered, which says something
important about the people she is studying, but also says something about the kind of
data the ethnographers has had access to. This is important to avoid bias concerning
the type of data that was gathered and the way it was gathered. Another element that
is important to take into account about the ethnographer’s status is the positions she
held during her field study.
Figure 3 Ethnographer's position in the group
According to Gold [7], the ethnographer can hold four different positions in the
field (see Figure 3). The pure observer is the position in which the ethnographer does
nothing else but to observe what is going on in front of her. This position excludes all
contact with the informants, as well as all risks of “going native”2 [7 p. 344]. At the
2
The expression “to go native” expresses the risk of “becoming the other”, that is to say to take
up the group’s discourse and implicit norms without questioning them.
©Copyright held by the author(s) 9
Socio-Technical Perspective in IS Development
same time, it can result in misunderstandings that would lead to ethnocentrism3 if
taken to its extreme. The observer-as-participant is less risky in terms of “going na-
tive” than the two next positions. The contacts with the informants are brief and often
happen once. However, this position can be the source of misunderstandings, which
can also result in ethnocentrism, in the analysis that the ethnographer makes of what
she sees. The participant-as-observer is the position in which the ethnographer partic-
ipates in the various activities of the group she studies and spends a considerable
amount of time with them. The group knows who the ethnographer is and why she is
there. This implies that the ethnographer establishes friendly relationships with the
people she lives with. However, neither the ethnographer nor the informants forget
the distance between them, as the ethnographer is still an ‘outsider’. Finally, the pure
participant is part of the group she is studying and imitates the habits and behavior of
her comrades. The most important thing to keep in mind when one takes this position
is to remember that one is simulating a role without letting the other ones know. This
position enables the ethnographer to grasp every aspect of the group’s social behavior.
However, it also demands a clear distinguishing between the identity in the group and
the identity as an ethnographer. Moreover, this position contains a strong risk of “go-
ing native”.
Often, the ethnographer takes the position in which she feels the most comfortable
but also in which she can understand the informants and put herself in their shoes.
However, the ethnographer’s position also depends on the field and the kind of data
that she wants to gather. She also has to find a balance between “going native” and
ethnocentrism. In practice, in the field, the ethnographer mostly goes from one posi-
tion to another depending on the circumstances. However, she needs to be aware of it
in order to know how she had access to the information.
3.2 Transforming observations into syntheses
During the fieldwork, the ethnographer takes notes while observing. This is then
transformed into reports which detail the interactions, often described by keywords in
the field notes. The next step is the commentaries, in which we come back on the
reports and synthesize them. This is where the analysis appears. Finally, the memos
are the final step before writing the paper. The commentaries, when taken as a whole,
make a series of analyses, which answer or contradict one another. This is where we
see different recurrent themes appearing, which will be the focus of the study. This
process enables the ethnographer to select the elements of her observations that will
be representative of her analysis4, as well as helping her see what themes appear and
are problematic. These different themes and elements come from the realization that a
3
Ethnocentrism consists in placing one’s own culture as comparative reference, in which the
other is compared to the ethnographer’s own values and norms. This places the other in a po-
sition of inferiority, which is extremely dangerous for ethical and scientifical issues [5 p. 83].
4
These elements are pertinent and exemplify the argument. They are what Katz calls “luminous
descriptions” [11], this article was translated in [4], which was one of the key references for
the course taught by Mr. Gonzalez.
Edited by S. Kowalski, P. Bednar and I. Bider 10
Proceedings of STPIS'15
certain pattern emerges in the field notes. This is when it is possible to see the main
dimensions of the phenomenon we are studying.
3.3 Understanding the informant’s language
Thus, the necessity of understanding the point of view of the informants, the social
group that the ethnographer studies, is extremely important. According to Smith [19],
there are three levels in language and writing. The first level is the kind of talk we
hear in the course of observation [19 p. 323]. Thus, it is the language that the ethnog-
rapher’s informants use in everyday life. The second level of language is the talk that
is used when the ethnographer and her informants speak together, either when the
ethnographer asks questions during observation or during interviews. The third and
final level of talk is the one that is part of the ethnographer’s own language. It is part
of the ‘academic’ discourse.
In other words, the ethnographer should be able to speak of what she has studied to
her peers In order to do this, she has to start from the observations, mediate them with
what the informants say about their actions and translate this into her study.
It is necessary to look at the matter from the informants’ point of view in order to
understand it better. Numbers and theories do not suffice. In order to grasp the full
phenomenon, we need to set ourselves at the social actors’ level. The social phenom-
ena we study have a multitude of dimensions that are necessary for understanding
them. Moreover, not taking into account the informant’s point of view can result in
forcing elements to fit in categories that the ethnographer invented and not the in-
formant, and therefore, can result in a biased analysis.
3.4 Summary
The theory we presented in this chapter is part of what was given to the engineering
students. For future presentations, we would like to add some more references like
Abu Lughod’s example. We would also like to show the students how they can solve
a problem by using ethnography, mainly by using a particular vision of the field in
which it is said that the solution and the problem comes from the field and the people
who evolve within it.
4 Lessons Learned
Over the years of giving this course, we (the teachers and students of social sciences)
have made the following casual observations about the Engineering students and
ourselves.
4.1 The tools of the ethnographer
From the point of view of the teachers the intervention of the social sciences students
brought several benefits. The theory they brought from the ethnography course ena-
©Copyright held by the author(s) 11
Socio-Technical Perspective in IS Development
bled us to anchor the observation part in much more substantial ground. The range of
tools differs from Contextual Inquiry even though they have the same purpose. In-
deed, the ethnographer’s main tool for synthesizing is text whereas in Contextual
Inquiry it is affinity diagrams (see Figure 4). Affinity diagrams are built by writing
single concepts on post-it notes and grouping individual notes by similarity. This
creates clusters of notes that are then assigned a category [8]. In the ESOA course we
use both tools, text and affinity diagrams, to describe observations and create synthe-
sis. The engineering students begin by writing text transcripts of their observations
and then move to affinity diagrams such as the one in Figure 4.
Figure 4 Affinity diagram produced by the 2012 ESOA class
4.2 The Time Element
Research publications such as [10, 22] report problems with the lengthy aspect of
ethnographical studies as well as the amount of data they produce. This apparently
contrasts with the need of corporate projects to quickly produce results. We have seen
the same impatience with our students. Year after year they want to get to the core
answers as quickly as possible.
The impatience of engineers with ethnographic studies is very visible in works
such as Hughes et al. [10]. They report on the difficulty of dealing with the extensive
length of field studies in the face of time pressure [10 p. 28]: “There seems to be a
point in time - and it often comes quite early on - when no new insights or infor-
mation are being uncovered.” They resort to what they call a “quick and dirty” ap-
proach where short field studies are used to uncover the most important aspects that
inform design. This, for us, misses several points. How can you know what is im-
portant? How do you know when to stop the observation? What if some major learn-
ing point happens just after you stopped the observation? Fieldwork means indeed
spending a lot of time waiting for something to happen. When something does hap-
pen, which eventually is always the case, the observer is happy to have invested the
necessary time. This, however, can be only known in retrospect. Experienced observ-
Edited by S. Kowalski, P. Bednar and I. Bider 12
Proceedings of STPIS'15
ers know that it is worth their while to wait for something to happen. Novice, impa-
tient observers tend to try to cut corners, missing much of the action, the learning and
the requirements.
The time element has another dimension. On the one hand, ethnographic methods
were not designed to be taught in such a short time and in a sanitized environment. On
the other hand, it is difficult to propose a full ethnography course in an Engineering
Curriculum. Our purpose is therefore only to draw the attention of the engineering
students to these methods with the hope that they will be wary of secondhand infor-
mation and will not be afraid to go in the field if given the opportunity.
That said, we acknowledge that it is a major challenge, in practice, to obtain the
funds that are necessary to spend time with stakeholders. Depending on the nature of
the work, it may be difficult to get access to the field. Nevertheless, we do our best to
help the engineering students see the necessity to invest the necessary time to uncover
as many details as possible. With enough students who have been exposed to the
benefits of observation, it may be possible to transform practice.
When the engineering students learn that students of social sciences spend a “long
time” just observing social phenomena without asking any questions, they usually
show more patience towards stakeholders. We can sense this clearly in the second
role-play session that follows the social sciences students’ presentation.
4.3 The reflexive position of the engineering students
We make the engineering students aware of the notion of reflexive position during the
debrief session that follows the role-play. Our observation on the reflexive position of
the engineering students is that they are very uncomfortable at the beginning of the
interviews. They don’t know what is their identity and tend to mix the identity of the
teacher or teaching assistant with the role he or she plays. This makes for awkward
encounters, with students who do not present themselves at the beginning of the inter-
view, who begin firing questions rapidly and who may have attitudes that can be seen
as socially inadequate in a business setting. This may seem like a secondary issue, but
it creates a climate of unease and suspicion with the stakeholders that can prove diffi-
cult to overcome. This “problem” is probably due in part to the teachers’ rapid intro-
duction of every role-play phase, which we do in order to introduce an element of
hurry that is very often present in real business settings. While debatable as a learning
strategy, it is part of our implementation of the experiential learning pedagogy where-
by an active and fast-paced experimentation comes before an emotional and technical
debrief.
Another side of the reflexive position is for the engineering students to appreciate
the relationships between the stakeholders they observe and interview. These relation-
ships sometimes constrain what the stakeholders can say about one another, and so
the engineering students should not take what the stakeholders say at face value, but
rather dig deeper into why stakeholders say what they say. We had the example of the
president of the air club who is very nice and positive about her experience with the
engine that is at the center of the role-play and that is giving her a lot of trouble. The
students, believing that stakeholders give them facts, interpret this positive attitude as
a fact that there are no problems with the engine. They have a problem reconciling
©Copyright held by the author(s) 13
Socio-Technical Perspective in IS Development
this “fact” with the “fact” that all during the role-play the engine has been in repair.
They fail to see that the president is a friend of the main investor in the engine manu-
facturer, that it is this investor who has sent the students to the president. The presi-
dent may, therefore, be reluctant to complain about the engine.
4.4 Relationships with stakeholders
We have noticed that the engineering students have great difficulty letting go of their
engineering vocabulary and changing to a language comprehensible by the stakehold-
er. At every role-play the mechanic must tell them repeatedly to talk in a language he
can understand. The students of social sciences insist on this aspect during their
presentation and when we redo the role-play, we can see some improvement. This
shows that when they are made aware of this issue, the engineering students correct
their behavior.
Another example we had a few years ago involved the air club president saying
during the role-play that the airplane was at the repair shop for 5 days whereas, at the
same time, the mechanic (who is in another room) said that he had the airplane in his
repair shop for 2 days. When the two teams of engineering students reconciled the
numbers during the technical debrief, they noticed the difference and accused the
mechanic of lying. Mind you, they did not accuse the president of lying or even of
being imprecise. Their base assumption was that the mechanic was lying. This is a
theme we have seen repeating over and over again, consisting of having a different
attitude toward people who are at a lower social scale. We have also reported on this
in [17].
4.5 Observations and evidences
The engineering students often seem completely uninterested in collecting evidence
during the first contextual interviews. Even during the second contextual interviews
they still consider much of the detailed evidence as irrelevant. They are more likely to
collect official looking papers than small pieces of paper on which a phone number is
scribbled. It is very difficult to make them aware that this apparently insignificant
piece of paper may be the key to unlocking the process they are supposed to discover
and analyze. We therefore attempt to draw their attention to our claim that ethnogra-
phy can help in identifying aspects that most engineers would consider unimportant
details, but it is these unimportant details that can make or break the acceptance of the
final product. Because it is not possible to know ahead of time what details are im-
portant and which can be neglected, they would do well to consider all details as im-
portant and sort them when they analyze and synthesize their findings.
The social science students noticed that some engineering students do not take
notes during the observation or interviews. They may observe the stakeholder or even
ask questions but would not register what they have observed or heard. Similarly,
they ask questions but do not seem to listen to the answer because they jump from one
subject to another without elaborating. The social sciences students helped the engi-
neering students to take notes and pay attention to the available evidences.
Edited by S. Kowalski, P. Bednar and I. Bider 14
Proceedings of STPIS'15
The engineering students are also mostly focused on asking abstract questions ra-
ther than observing the minutiae details of the process unfolding before their eyes. For
example, while the mechanic is trying to find the phone number of the key supplier he
needs to call, a number he is sure to have written somewhere on a piece of paper, the
engineering students will be asking him how many times a year he gets this particular
failure in an engine. The point the teacher who plays the mechanic is making while
looking all over the shop for the phone number is that the process is stuck during this
time, and that the students would do well to ask for what phone number he is looking,
note the problem and later suggest to correct it through some IT system requirement.
If they don’t pay attention to this small detail (and they usually don’t), they miss that
requirement while trying to find answers to questions that are not relevant to the pro-
cess at hand. Hence, the same setting that would see ethnographers harvest loads of
details, have engineers yawning with disinterest. It is easy to brush this off as lack of
experience, but experienced engineers who have not been sensitized to detailed ob-
servation, may also be subject to the same problem. In figure 5, we show two exam-
ples of evidences that the engineering students have missed in the class of 2015. The
note on the right is the one with the phone number that the mechanic is feverishly
looking for, as explained. On the left is a picture of the airplane that is at the center of
the role-play with a note saying that it is non-serviceable (a technical term meaning
that it is broken) and must not be flown.
Figure 5 Evidences missed by engineering students in 2015
4.6 Observations and syntheses
Sommerville et al. [21 p. 169] note that “the ethnographic record of work practice is
inherently unstructured.” They argue that it is therefore “quite impossible to fit these
observations into structured requirements analysis” and “it is difficult to draw design
principles and other abstract lessons from a technique that is concerned with the detail
of a particular situation.”
As we have seen above, the ethnography techniques to which we were introduced
by the social sciences students include synthesis techniques that are precisely what the
engineers are looking for. Thus, current ethnographic methods provide tools for sum-
marizing and generalizing the detailed record. Social sciences students are trained to
seek patterns of behavior, which is the Holy Grail sought by IT engineers. This re-
©Copyright held by the author(s) 15
Socio-Technical Perspective in IS Development
sembles more the techniques proposed by Contextual Inquiry [3] than the ethnogra-
phy techniques used by software engineers in the 1990s (e.g. [9, 10, 20, 22]). The
main difference seems to be in the tools used as we described in the beginning of this
chapter.
4.7 The opinion of one of the students
An interview of one of our ex-students who took the ESOA course in 2013 produced
the following information:
• The student felt that his group didn’t benefit much from the ethnography
techniques because they were obsessed with finding a problem to justify the
solution they identified during the first (non-contextual) interview session.
• The engineering students didn’t know how to transfer the knowledge they
gained during the ethnography presentation because the social sciences stu-
dents showed how to observe and describe social situations but not how to
identify problems and solutions.
• During the ethnography presentation the engineering student realized that
they needed to observe more and interrupt less. Seeing that the social scienc-
es students spent such a long time just observing a situation was an eye
opener to the engineering students who were oriented toward quickly finding
the problem and solution.
The teachers were aware of the difficulty the engineering students had in identifying
the problems, but it is a difficult issue to solve. In future courses we intend to put
more emphasis on problem identification.
5 Ethnography and IS Development Methods
Information Systems development seems to be shifting toward the adoption of so
called agile methods, mainly XP [2] and Scrum [20]. These relatively new methods
prescribe less upfront investment in requirements elicitation and more continuous
contact with stakeholders as a way of providing requirements in the form of stories to
the development team. Both XP and Scrum place high value on involvement with
stakeholders in general and customers in particular. In XP this is called the principle
of Real Customer Involvement [2]. In Scrum it is this responsibility is assigned to the
Product Owner role [20]. As we see it, this is an opportunity rather than a threat to the
use of ethnography in IS development. Both XP and Scrum do not say how to create
and maintain this on-going relationship with customers. Ethnography can be seen as
providing some of the tools necessary for this long-term involvement. How this can
be done in practice is an open question. As we have mentioned in Section 4, obtaining
resources for long-term observation is a challenge. In Scrum this means that the Prod-
uct Owner should have the time and budget to invest in long-term relationship with
his customers. If the Product Owner is assigned to too many projects, probably the
first aspect of her job to be removed will be this on-going relationship.
Beyond the tools for eliciting requirements, ethnography can improve the use of
the socio-technical design [14] by showing that the design of work processes by only
Edited by S. Kowalski, P. Bednar and I. Bider 16
Proceedings of STPIS'15
the work team may result in sub-optimal solutions because the work team may be
blind to some problems and possible solutions. In our experience, field workers usual-
ly know more about their work than managers or IS engineers. However, they are also
often blind to some possible improvements because the norms governing their behav-
ior are tacit and considered… normal. A non-native and nevertheless benevolent ob-
server can be of great help in proposing but not imposing improvements. By adding a
non-native ethnographer it may be possible to identify unseen problems and suggest
better solutions. This means that IS engineers should not go too native with one group
of users at the expense of another. They need to maintain a balance of native and non-
native. Being too native with one group can result in being perceived as alien in an-
other, a situation that actually happens in practice.
Finally, long-term field studies may not be considered useful in situations where
management envisions to radically change the work practices. In these situations,
other humanistic approaches, such as socio-technical design would not be considered
either, as reported by Mumford in [14].
6 Conclusions
We presented the case of an Enterprise Architecture course in which social sciences
students were invited to teach ethnographic techniques to engineering students. We
hope that this will have an effect on both research and practice.
Information Systems research is a fairly closed, self-referencing field. It is mostly
based on software engineering and computer science techniques. Whereas the devel-
opment and maintenance of information systems is indeed an engineering discipline,
the adoption of these systems is mostly a social problem. The social sciences should
be a lot more represented in IS research than they are now.
Most of our engineering students will go on to work in an organization where they
will be involved in IT systems development. If our experience is of any value, it
shows that development is becoming increasingly automated, through the use of turn-
key systems bought and used as-is. In this context, building good relationships with
stakeholders is becoming nearly as important as possessing technical skills. Our hope
is that this course will help these future engineers to be more aware that IT projects
should not be seen from a purely engineering point of view, and that ethnography can
offer them some useful methodological tools.
Acknowledgements: We thank Philippe Gonzalez, Gorica Tapandjieva Aarthi Gopal
and George Popescu for their help with shaping this paper.
©Copyright held by the author(s) 17
Socio-Technical Perspective in IS Development
7 References
1 Abu Lughod, L.: Fieldwork of a Dutiful Daughter. In: Altorki S., El-Solh, F.
(eds.) Arab Women in the Field, Syracuse: Syracuse University (1988)
2 Beck, K., Andres, C.: Extreme Programming Explained: Embrace Change. Pear-
son Education (2005)
3 Beyer, H., Holtzblatt, K.: Contextual Design. Interactions. vol. 6, no. 1, ACM
(1999)
4 Cefaï, D., Costey, P., Gardella, É., Gayet-Viaud C., Gonzalez P., Le Méner E. &
Terzi C. (éds.) L’engagement ethnographique. Paris, Éd. de l’EHESS (2010)
5 Géraud, M.-O., Leservoisier, O., Pottier, R.: Les notions clés de l’ethnologie.
Paris: Arman Colin, [3rd edition] (2010)
6 Goguen, J.A., Linde C.: Techniques for Requirements Elicitation. In: Proc. Re-
quirements Engineering ’93, IEEE (1993)
7 Gold, R.I.: Jeux de rôles sur le terrain. Observation et participation dans
l’enquête sociologique. in Cefaï, D., L’enquête de terrain. Textes réunis, présen-
tés et commentés par Daniel Cefaï. Paris: La Découverte (2003). Translated
from English: Gold, R.I., “Roles in Sociological Field Observations”, Social
Forces, vol. 36, no. 3, pp. 217-223 (1958)
8 Holtzblatt, K., Beyer, H.: Making customer-centered design work for teams.
CACM vol. 36, no. 10, pp. 92-103. ACM (1993)
9 Hughes, J.A., Randall, D., Shapiro, D.: Faltering from Ethnography to Design.
In: Proc. CSCW’92, pp. 115-122. ACM (1992)
10 Hughes, J., O'Brien, J., Rodden, T., Rouncefield, M., Sommerville, I.: Present-
ing Ethnography in the Requirements Process. In: Proc. IEEE International
Symposium on Requirements Engineering. IEEE (1995)
11 Katz, J.: Du comment au pourquoi. Description lumineuse et inférence causale
en ethnographie. In: Cefaï D., Costey P., Gardella É., Gayet-Viaud C., Gonzalez
P., Le Méner E. & Terzi C. (éds.) L’engagement ethnographique, pp. 43-105.
Paris, Éd. de l’EHESS (2010). Translated from English: Katz J., “From How to
Why: On Luminous Description and Causal Inference in Ethnography”, Ethnog-
raphy. vol. 2, no. 4, pp. 443-473 (2001), and vol. 3, no. 1, pp. 63-90 (2002)
12 Kolb, D.A.: Experiential Learning: Experience as the Source of Learning and
Development. Prentice Hall, Englewood Cliffs (1984)
13 Malinowski, B.: Argonauts of the Western Pacific. George Routledge & Sons,
London (1932)
14 Mumford, M.: The story of socio-technical design: reflections on its successes,
failures and potential. Information Systems. vol. 16 no. 4, pp. 317–342 ((2006)
15 Nuseibeh, B., Easterbrook, S.: Requirements Engineering: A Roadmap. In:
Proc. ICSE '00. pp. 35-46. ACM (2000)
16 Regev, G., Gause, D.C., Wegmann, A.: Requirements Engineering Education in
the 21st Century, An Experiential Learning Approach. In: Proc. Requirements
Engineering, IEEE (2008)
17 Regev, G., Gause, D.C., Wegmann, A.: Experiential learning approach for re-
quirements engineering education. Requirements Engineering. vol. 14. pp. 269–
,287. Springer (2009)
Edited by S. Kowalski, P. Bednar and I. Bider 18
Proceedings of STPIS'15
18 Seyff, N., Graf, F., Maiden, N., Grünbacher, P.: Scenarios in the Wild: Experi-
ences with a Contextual Requirements Discovery Method. RefSQ 2009. LNCS,
vol. 5512, pp. 147-161 Springer (2009)
19 Smith, D.E.: On Sociological Description: A Method from Marx, Human Stud-
ies. vol. 4, no. 4, p. 313-337 (1981)
20 Sutherland, J.: Scrum. Random House (2014)
21 Sommerville, I., Rodden, T., Sawyer, P., Bentley, R., Twidale, M.: Integrating
ethnography into the requirements engineering process. In: Proc. of Require-
ments Engineering IEEE (1992)
22 Viller, S., Sommerville, I.: Social analysis in the requirements engineering pro-
cess: from ethnography to method. In: Proc. IEEE International Symposium on
Requirements Engineering. IEEE (1999)
©Copyright held by the author(s) 19