Penzenstadler - Requirements Engineering (Proposal)

This is a template for creating a proposal for development of learning activities related to student participation in HFOSS. To see examples of proposals, select Category under Navigation in the menu to the left, and then select the Proposal category.

Summary

<Provide a short description (a few sentences will do) of the what you intend to do.>

Target Venue

Requirements Engineering course (mine is currently a graduate course, but undergraduates can join as well, only prerequisite is 'Introduction to software engineering' or something simliar)

Target Student Audience

<Who typically takes this course? Majors or non-majors? Is this a required course? At what point in their studies do students take this course?>

Learning Activities

I have a lecture on requirements engineering (slides online, see [1]) for which I will develop lab activities to support the contents talked about in class that develop the skills that will allow students to apply their knowledge in a larger scale, live software product development with its everyday challenges (of missing or incomplete requirements and their management), while at the same time being exposed to open source culture.

There will be 7 activities that can each fill one or two lab sessions, depending on how extensive the instructor decides to discuss the results and the experience the students had. Generally, the first session would be for the introduction of the exercise and the students to perform the exercise, and the second lab would be to discuss the results and give feedback, and to rework and improve the submitted assignment (optional, but I find that beneficial for the students). Drafts for 3 of the activities are provided at [2]

• "Reengineering a Software Requirements Specification": Reengineering a SRS from a roadmap and issue database and coming up with a set of questions on what the functionality should be and what is unclear, then ask community.
• "Understanding Design activity": Understanding the existing design. (Quiz them on it.) Let them understand it and then reengineer a SDS.
• "Quality Assurance activity": Give students a checklist of what to look for: requirements documentation, version control documentation, structure and modularization in comparison to roadmap, "clean-ness" of interfaces, etc.

Further activities planned:

• cnt. here

< Provide a general description of the activities you plan to develop. How many activities will there be? What types? (labs, homework assignments, projects, etc.) What outcomes do you expect? What specific products will you have to share at the end? (lab instructions, grading rubrics, homework assignments, etc.) Note: we only expect basic information at this point since the activities are not developed yet.>

Evaluation

I will use the standard POSSE pre- and post surveys and extend them with specific questions on requirements engineering. The effectiveness in comparison to earlier versions of this course can be evaluated by comparing the results of our SPOT (Student Perceptions of Teaching) evaluation.

Schedule

The course will be held in Spring 2017, so the materials will be developed December 2016 to February 2017 and the evaluation will be completed by May 2017 when the course finishes.

Budget

Development of lab materials, worksheets and exercises, plus data collection and analysis, $1500 Conference travel to the 13th International Conference on Open Source Systems, in collocation with ICSE, May 2017, $1500

Contact Information

Birgit Penzenstadler birgit 'dot' penzenstadler 'at' csulb 'dot' edu