Penzenstadler - Requirements Engineering (Proposal)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
m
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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==
 
==Summary==
<Provide a short description (a few sentences will do) of the what you intend to do.>
+
I intend to develop a series of HFOSS lab assignments along with instructions for a course on requirements engineering as to date there is only one [[Requirements Analysis]] activity in the portfolio provided on foss2serve.
 
 
 
==Target Venue==
 
==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)
+
Requirements Engineering course (mine is currently a graduate course, but undergraduates can join as well, only prerequisite is 'Introduction to software engineering' or something similar).
 
 
 
==Target Student Audience==
 
==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?>
+
Requirements Engineering is an elective course and is usually taken by majors. The years vary. However, the activities to be developed can also be used during any software engineering course in the requirements engineering phase of the course.
 
 
 
==Learning Activities==
 
==Learning Activities==
I have a lecture on requirements engineering (slides online, see [http://birgit.penzenstadler.de/teach/590RE.html]) 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.
+
I have a lecture on requirements engineering (slides online, see [http://birgit.penzenstadler.de/teach/590RE.html]) 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 free open source culture specifically in a humanitarian context.
  
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.
+
There will be 6 new 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. As 7th activity, the existing [[Requirements Analysis]] will be reused.
 
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).
 
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 [http://maythesource.blogspot.com/2016/11/fosscsulb-course-preparation.html]
 
* "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.>
+
* New activity: "(Re-)Engineering a system vision": Understand the vision of an existing system from its online documentation and extract the major features and the business case. Submit the visions to the community for voting on how well they represent their core ideas.
 +
* Existing activity: [[Requirements Analysis]]: To be used first to get an understanding of the setup and the tools used in FOSS. Includes intro to github and issue tracking.
 +
* (New 'super-activity', broken down in 3 activities) "(Re-)Engineering a Software Requirements Specification": Reengineering a SRS from a roadmap and issue database. The outcome of these assignments will be submitted to the community for review, and then can be fed back into the issue tracker (e.g. to improve and detail feature requests) and provided to the community for their roadmap in case a contact is established and the community is interested.
 +
** New activity: "(Re-)Engineering use cases": Developing use case overview diagrams and use case scenarios according to the Cockburn template, based on information in the roadmap and issue tracker.
 +
** New activity: "(Re-)Engineering stakeholders, goals & questions": Listing the stakeholders of the system and identifying their major goals and objectives. Along with that, coming up with a set of questions (per stakeholder) on what the functionality should be and what is unclear, then (optional) ask community about those.
 +
** New activity: "(Re-)Engineering Quality requirements": Developing quality requirements from the roadmap and the issue tracker according to the ISO 25010 quality model, and then checking compliance of those qualities in the actual implementation, for example the understandability / ease of use of interfaces, etc.
 +
* New: "Understanding Design and Checking Compliance": Understanding the existing design. Quiz them on their basic understanding to make sure they are on track. Then let them understand the high-level design and conduct an analysis of whether the design is consistent with the requirements. Give a summary of the feedback to community members and let them decide on validity and/or usefulness and feed the information back into the issue tracker.
 +
* New: "Documentation Quality Assurance": Give students a checklist of what to look for in road map, issue tracking, and version control documentation. Let them write a QA review report. Depending on the community, some of the feedback may be relayed to them via the issue tracker.
 +
 
 +
Draft notes for 3 of these activities are provided at [http://maythesource.blogspot.com/2016/11/fosscsulb-course-preparation.html] but they are very rough.
 +
A draft course outline that will be completed along with a description of the activities is available at [[Requirements Engineering, CSU Long Beach, Penzenstadler]].
 +
 
 +
Deliverables: I will provide the lab instructions, grading rubrics, and homework assignments via this wiki in the activities category.
 
 
 
==Evaluation==
 
==Evaluation==
I will use the standard [[http://foss2serve.org/index.php/Evaluation_Instruments | POSSE pre- and post surveys]] and extend them with specific questions on requirements engineering.
+
I will use the standard [[Evaluation Instruments]] (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.
 
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.
  
Line 32: Line 37:
 
   
 
   
 
==Budget==
 
==Budget==
Development of lab materials, worksheets and exercises, plus data collection and analysis, $1500
+
Development of a course page, activity descriptions, lab materials, worksheets and exercises, plus data collection and analysis, $3000
Conference travel to the 13th International Conference on Open Source Systems, in collocation with ICSE, May 2017, $1500
+
 
 +
Conference travel to the 13th International Conference on Open Source Systems, in collocation with ICSE, May 2017, $1000.
 
 
 
==Contact Information==
 
==Contact Information==
 
Birgit Penzenstadler birgit 'dot' penzenstadler 'at' csulb 'dot' edu
 
Birgit Penzenstadler birgit 'dot' penzenstadler 'at' csulb 'dot' edu
 
 
[[Category:Proposal]]
+
 
 +
[[Category:Proposals]]

Latest revision as of 13:24, 8 February 2017

Contents

Summary

I intend to develop a series of HFOSS lab assignments along with instructions for a course on requirements engineering as to date there is only one Requirements Analysis activity in the portfolio provided on foss2serve.

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 similar).

Target Student Audience

Requirements Engineering is an elective course and is usually taken by majors. The years vary. However, the activities to be developed can also be used during any software engineering course in the requirements engineering phase of the 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 free open source culture specifically in a humanitarian context.

There will be 6 new 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. As 7th activity, the existing Requirements Analysis will be reused. 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).

  • New activity: "(Re-)Engineering a system vision": Understand the vision of an existing system from its online documentation and extract the major features and the business case. Submit the visions to the community for voting on how well they represent their core ideas.
  • Existing activity: Requirements Analysis: To be used first to get an understanding of the setup and the tools used in FOSS. Includes intro to github and issue tracking.
  • (New 'super-activity', broken down in 3 activities) "(Re-)Engineering a Software Requirements Specification": Reengineering a SRS from a roadmap and issue database. The outcome of these assignments will be submitted to the community for review, and then can be fed back into the issue tracker (e.g. to improve and detail feature requests) and provided to the community for their roadmap in case a contact is established and the community is interested.
    • New activity: "(Re-)Engineering use cases": Developing use case overview diagrams and use case scenarios according to the Cockburn template, based on information in the roadmap and issue tracker.
    • New activity: "(Re-)Engineering stakeholders, goals & questions": Listing the stakeholders of the system and identifying their major goals and objectives. Along with that, coming up with a set of questions (per stakeholder) on what the functionality should be and what is unclear, then (optional) ask community about those.
    • New activity: "(Re-)Engineering Quality requirements": Developing quality requirements from the roadmap and the issue tracker according to the ISO 25010 quality model, and then checking compliance of those qualities in the actual implementation, for example the understandability / ease of use of interfaces, etc.
  • New: "Understanding Design and Checking Compliance": Understanding the existing design. Quiz them on their basic understanding to make sure they are on track. Then let them understand the high-level design and conduct an analysis of whether the design is consistent with the requirements. Give a summary of the feedback to community members and let them decide on validity and/or usefulness and feed the information back into the issue tracker.
  • New: "Documentation Quality Assurance": Give students a checklist of what to look for in road map, issue tracking, and version control documentation. Let them write a QA review report. Depending on the community, some of the feedback may be relayed to them via the issue tracker.

Draft notes for 3 of these activities are provided at [2] but they are very rough. A draft course outline that will be completed along with a description of the activities is available at Requirements Engineering, CSU Long Beach, Penzenstadler.

Deliverables: I will provide the lab instructions, grading rubrics, and homework assignments via this wiki in the activities category.

Evaluation

I will use the standard Evaluation Instruments (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 a course page, activity descriptions, lab materials, worksheets and exercises, plus data collection and analysis, $3000

Conference travel to the 13th International Conference on Open Source Systems, in collocation with ICSE, May 2017, $1000.

Contact Information

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

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox