Teaching requirements engineering to undergraduate students

Abstract

Requirements engineering, an integral part of the life of a software engineer, often receives little or no attention in the education of a computer science student. We report on our experiences in constructing an innovative curriculum that utilizes a three tier model of learning that provides students with hands-on experience on the various facets of requirements elicitation and management. This curriculum can be integrated into an existing course on software engineering, software requirements or the senior capstone experience. We believe our experience will be of use to other computer science and software engineering programs that are aiming at introducing requirements in the undergraduate curriculum. General TermsDesign

Work in progress: Sustainable projects for software engineering courses: Collaborating with technology courses

“…Without a proper understanding of customer requirements, the likelihood of project failure increases [6]. In addition, customers and users often do not know exactly what they want.…”

“…Establishing and maintaining relationships to ensure a healthy supply of such projects can be difficult and in the absence of systematic institutional support (e.g., office of Service Learning), faculty often must be "courageous" [1]. On the other hand, the key characteristics of "realistic project" that motivate students are not the demanding "relationships"; rather, the key characteristics are the actual clients and "real-world" problems [6,7,8]. With these observations, instead of looking externally outside the university, many educators search internally for opportunities for collaboration, and design classes with less logistically demanding projects.…”

Requirements Engineering Out of the Classroom: Anticipating Challenges Experienced in Practice

“…Another relevant aspect pointed out by Mohan and Chenoweth [5] about the RE teaching curriculum was the importance of inserting the students in projects jointly with industry companies, based in scenarios that could evidence better where and how the techniques learned in the first part of the course should be applied. This experience resulted in 33 out of 36 projects being successful, and this success was accredited to the demonstration of how the theory should be applied and why it works, instead of using "toy" projects (i.e., without a real client, only for practicing the theory in class).…”

“…However, such a simulation does not provide a complete immersion in the RE scenario, due to its underlying limitations [4]. Some elements that constitute the real scenarios are difficult to explore or reproduce, such as uncertainties of requirements suppliers as to what should be developed, conflicting requirements, behavioral traits, among other technical and non-technical aspects [5].…”

Introducing Software Specifications to an Undergraduate Software Engineering Program

“…Furthermore, this gives them the experience of how prototypes and client feedback translate into the finished product. This was also observed by Mohan and Chenoweth 9 : it is important that students "carry their requirements projects forward into design and development, sufficiently that they can see the importance of the time spent learning to do requirements" 9 . Nevertheless, it is important to note that student teams spend the larger part of the semester (about 70%) interacting with the client, building mockup/prototype(s) and obtaining client feedback, which they then use to create their SRS (specific tasks and deliverables are discussed in the next paragraphs).…”