Session S4C
DEVELOPING TEAMWORK AND COMMUNICATION SKILLS IN A
MULTIDISCIPLINARY EXPERIMENT
Daniela Rosca'
Abstract - The need of producing software engineers with
strong teamwork and communication skills has been
repeatedly stressed by industry worldwide. ABET includes
these skills among the essential ones needed lo be mastered
by the srudents ofan accreditedprogram. Due to this great
emphasis on teaming, communication skills and
multidisciplinary work, academia had lo respond byfinding
novel ways IO introduce them to students. Thispaper reports
upon a mullidisciplinay experiment between sofwnre
engineering and business management students. They
collaborated to produce a software requirements
specijication for managerial processes involved in hiring
and performance evalualion of employees within a ftrm. A
description of the synchronization of the lectures with
project deliverables in the two courses, difjPrent types of
communication needed by students, positive interdependence
of the leanis across disciplines, and how they contributed lo
the success of the project will be discussed among other
multidisciplinary issues encountered during this experiment.
Jndex Terms - Multidisciplinary Teams, Software
Engineering Education. Requirements Engineering,
Management oflnfornlation Systems.
INTRODUCTION
The need of producing software engineers with strong
teamwork and communication skills has been repeatedly
stressed by industry worldwide [ l,2,3). Employers from
different countries across the globe consistently rank these
skills at least as important as technical skills in being
successful in a corporate environment.
In preparing the students for their future professional
life, Monmouth University's Software Engineering
Department has introduced a multidisciplinary project to
create an opportunity for students to exercise teamwork and
communications skills across disciplines. While usually the
multidisciplinary experiments arc incorporated in the
capstone projects [4,5], at Monmouth students get this
experience earlier. The experiment described in this paper is
covered during the requirements engineering course, which
details the first phase of the software engineering lifecycle.
Requirements engineering is a good area for introducing
multidisciplinary issues due to the need of the requirements
engineers to interact with stakeholders from different
domains and backgrounds. Social issues play an important
'Daniela Rosca, Software Engineering Department, Monmoulh Univenity, West Long Branch, NI 07764, droscn~~unniosrlrrhr
0-7803-7961-6/03/517.00 Q 2003 IEEE
33rd ASEE/IEEE Frontiers in Education Conference
s4c-14
role in requirements engineering, as it was underlined by
Goguen in [6,7].
In this paper we report on the multidisciplinary
experiment, the participating courses, and the
multidisciplinary teaming issues encountered. We conclude
with a summary of our observations and lessons learned, and
we identify future directions for the proliferation of the
gained expertise.
MULTIDlSClPLlNARY EXPERIMENT
The joint project has been created between two graduate
courses in the Software Engineering and Business
Administration Departments: the SE507 Software
Requirements course, and BM520 Information Systems in
Organizations course. The leaming goals set for this project
were the following:
1. Simulate an actual software requirements process in
a corporation.
2. Develop appropriate communication skills.
3. Function as a multidisciplinary team for achieving
an end product.
Next, t will describe the structure of the two courses
involved in this experiment, the project, the
multidisciplinary teaming issues, and the calendar
organization of the project.
Course Structures
SE507 - Requirements Engineering. The course
introduces students to the process, nethods and tools related
to the software requirements engineering area. Topics
related to requirements elicitation, analysis, specification,
validation and management arc discussed in the context of
related case studies. During the course of the semester
students arc asked to produce the sofiware requirements
specification document (SRS) of a product, as the main way
of applying the concepts leamed in class. The SRS
document structure is shown in Figure I . The first two
sections of the SRS provide an executive summary of what
the project is about, while section 3 details the technical
requirements.
Team performance is judged according to the quality of
the documents delivered throughout the semester. This
performance is amended for an individual student in
accordance with hidher teaming performance, evaluated by
hidher peers.
November 58,2003, Boulder, CO

1. Introduction
1. I Purpose of the requirements document
1.2 Scope of the product
I .3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
functional, non-functional and interface requirements.
1 tasks t o his team, monitor their progress, coordinate t e a m
4.Appendices
I
5. Index
FIGURE I. THE STRUCTURE OFA SRS DOCUMENT.
i
I
BM520 - BM52O Information Systems in
Organizations. The course surveys the concepts of
management information systems and the information needs
of management. It provides a user-oriented introduction to
the fundamentals of information systems and their
integration into business organizations. The students are
asked to work on 5 smaller size projects, one of which is the
joint project with SE507. Therefore the grade obtained on
the multidisciplinary project represents only a fraction of
their final project grade in that class.
The Multidisciplinary Project
The overall project goal was to produce the SRS for the
managerial processes involved in hiring and performance
evaluation of employees within a firm. The multidisciplinary
teams were able to choose a real firm, the one where a group
member was employed , o r create a fictitious business.
The students in BMS20 were playing the “clients” role,
from a requirements perspective. They were responsible for
providing a report to their counterparts in SE507 containing
the purpose, business justification, main product
functionalities, the actual processes needed to he supported
by the future system, and scenarios describing the ways the
system will be used for achieving the business goals. They
were also responsible for prioritizing the main product
functionalities according to the business needs.
The students in SE507 were responsible for producing a
complete software requirements document (SRS)that would
incorporate the information provided by the business
students. They would need to use this information to
0-7803-7961-6/03/%17.00 2003 IEEE
33‘‘ ASEElIEEE Frontiers in Education Conference
S4C-15
Session S4C
compose the first two sections of the SRS. Also they would
refine that information in order to produce the technical
requirements necessary for the design and implementation of
that product, which are usually described in section 3 of the
SRS.
Multidisciplinary Teaming Issues
Over the first half of the semester a couple of meetings were
scheduled during the class time for allowing the
multidisciplinary teams to collaborate. Each team consisted
of 5 business students and 2 soflware engineering students.
They were formed by considering students preferences, or
scheduling considerations. A project leader was chosen for
each discipline, whose responsibilities were to designate
meeting times beyond the class time, and ensure
communication with the instructors.
Students were taught basic teaming issues, such as the
preparation of their meetings by developing an agenda of
discussion items, and ending up the meetings with a set of
minutes that would contain the conclusions and the
responsibilities assigned to each member of the team, until
thenext meeting. Also, thenecessityofdeveloping a task
plan, complete with the assignment of individual
responsibilities was emphasized. A project web site
facilitated the communication among team members.
Although this infrastructure was present, students preferred
to use personal e-mail, or group lists, since all of them were
familiar with the use of e-mail.
During the first multidisciplinary meeting, language
differences between the two disciplines had to he cleared
out. Also, the SE507 students presented the structure of the
SRS document in detail to their business colleagues, in order
to clarify the input needed from them. The teams defined the
joint approach of the project.
This project allowed the students from the two
disciplines to exercise positive interdependence, by relying
on the work d the students from the other discipline to
achieve the goal of the project. This way SE507 students
were able to focus on the technical requirements of the
project, while their business colleagues were focusing on the
business context definition of the project. Students built a
sense ofmutual confidence and respect for the complexity of
each other’s discipline.
Individual accountability was expected from each
member of the multidisciplinary team. They were expected
to explain or demonstrate their personal contributions to the
project at any given time during the semester. Also, during
the joint meetings, instructors who moderated the meetings
observed the participation in the discussions of the
individual members of the teams.
This project was an excellent oppo~unityfor students to
exercise different types of communication, as specific
audiences required it. They needed to communicate with the
stakeholders from the case study firm, with faculty, with the
November 5-8,2003,Boulder, CO

members of their own discipline, and across disciplines. To
help them in this complex endeavor, faculty presented some
examples of how to structure SRS documents, how to
conduct interviews and brainstorming meetings and how to
make oral presentations.
The instructors’ participation in this experiment was
very sustained. Instructors moderated all the
multidisciplinary meetings, offering additional help in cases
where the requirements of the project went beyond students’
knowledge. Also, they evaluated all the intermediary
documents produced by the multidisciplinary teams,
providing timely feedback. In cases where personality
conflicts appeared, instructors mediated them, only if asked
by the team. Our experience was very fortunate. From the 7
teams formed, only one encountered such problems.
Because instrudors attended all the joint meetings, they
had the opportunity to assess the students’ achievements in
terms of preparing, conducting, and concluding meetings.
After joint meetings, instructors had provided students with
feedback on the positive aspects observed, as well as pointed
out the things that needed to be improved.
Calendar Organization
The project was developed over 14 weeks. The milestones
established by the instructors of the two courses for the
development of the multidisciplinary project were the
following:
-
Week I SE507 and BM520 teams were formed
-
Week 2
independently
Proiect statement distributed in both courses.
- Specific responsibilities assigned in each course.
Week 3 Multidisciplinary teams formed. Students met for
the first time. Common language established.
Clarification of project objectives. Choice of a
-
Weeks
case study firm.
EM520 students worked on developing the
The instructors’ observations could be summarized along the
following dimensions:
4-5
-
Week 6
Week 7
and annotated it with information that needed to
- synchronize the lectures with the project
Week 8
clarification of all the problems identified by the
SE507 students. SE507 students started their
- work on the SRS.
Week 9 Final business case definition delivered to SE507
__ students by BM520 students.
Week SE507 students delivered Sections I and 2 of the
10 SRS.
Weeks SE507 students completed Section 3 of the SRS
11-14 and delivered the final documnt to their
“clients”, the BM520 students.
0-7803-7961-6/03/$17.00 0 2003 IEEE
33‘‘ ASEE/IEEE Frontiers io Education Conference
S4C-16
Session S4C
OBSERVATIONS AND LESSONS LEARNED
All teams successfully completed the joint project. The
business students succeeded in delivering their reports on
time, with the exception of one team, which was excused for
being responsible for delivering a class presentation before
the project deadline. The software engineering teams
delivered the complete projects on time, with only one
exception, as well.
The quality of the SRS produced was far superior to
those delivered in previous years, when the joint project was
not an option. Sections 1 and 2 were treated with much more
consideration, and thoroughly elaborated, due to the
information delivered by the business students. Previously,
these sections were considered just a necessary “digression”
before getting to the technical requirements. The opportunity
to discuss unclear issues with their business colleagues led,
as well, to an increased insight into the technical
requirements
The students were asked to fill in project and course
evaluations, separately. The course evaluations revealed
very high scores, reflecting student satisfaction with the
overall experience of the courses they were involved in. The
project evaluations turned in an encouraging rating of 75%
in the very effective and effective categories. Student
feedback could be summarized as follows:
more class time needed for multidisciplinary teams
meetings;
give business students more motivation for this
project, by making it a bigger part of their grade;
the project was very helpful in supporting the
material taught in class: “it helped understand that
customer requirements can be vague and open to
interpretation, and how difficult it is to translate
them into technical requirements”.
e the need of instructors to meet before the beginning
of the project and during the semester, in order to
share and understand each other’s syllabi, define
the deliverables for the teams in each discipline,
deliverables, schedule class time for team meetings;
due to the fact that most of the students enrolled in
these classes worked full-time, it was very difficult
to find availability for face-to-face meetings outside
the class timeframe. Therefore, we had to sacrifice
class time for supporting team meetings;
this leads to another issue that is critical to the
success of the project: the need to synchronize the
course offerings, at least partially. For this to
happen, support of each department chair is needed,
and planning the experiment has to be done
sufficient time in advance for the proper scheduling
to take place;
November 5-8,2003, Boulder, CO
 Session S4C

the different evaluation of the project for each

discipline influenced how much effort was put into
the project, and the willingness to revise
intermediary deliverables.

FUTURE DIRECTIONS

The experiment reported in this paper provided us the

encouragement to continue and extend it to the
corresponding undergraduate programs. Of course, we
expect that much more guidance and supervision would be
needed for the undergraduate students, and more class time
to be dedicated to teaching and providing feedback on
multidisciplinary issues, and communication skills. Also, we
have started the investigation for extending this project by
incorporating the biology students as well.

REFERENCES
Teles. V.M.. Olivein C.. "Reviewine the Curriculum of Software

Heil,M. K., "Prepafing Technical Commmiations for Fume

Workplaces: A Model that Integrates Teaming, Professional
CommunicationSkills, and a S o h a r e Development Pmcess",
Prceeedi"~sofACMSlGDOC,1999, pp. 110-119.
Seat, E., Lard, S., "Enabling Effective Engineering Teams: A Fm-
for Tcaching Interaction Skills",ProceedingsofFIE'P8,1998.
Fomaro, 8..Heil M., h e r V., "Cross-FunctionalTeamsusedin
Computer Science Senior Des@ CapstoneCounes", P m c e d h p o f
FIE'OO,2000.
Fomm, R., Heil M., Perelti S.,"Enhancing Technical
C o m m i u t i o n Skills of Engineering Students: An Expz<ment in
Multidisciplinary Design'', Pmceedingr ofFlE'O!,ZW1
Goguen, I., "Requirements Engineering as the Kewnciliation of
Technical and Social Issuer", in Reyuiremmn Engineering: Sociol
and Technical Issuer, Acadnnic Press, 1994.
[7] Goguen, J., Linde, C., "Techniques for Requirements Elicitation",
Pmceedhgs uflhe Rquiremenlr Engineering Conference RE '98,
IEEE Computer Society. 1998, pp. 152-164

0-7803-7961-6/03/$17.00 0 2003 IEEE November 5-8,2003, Boulder, CO

33" ASEE/IEEE Frontiers in Education Conference
s4c-17