Difference between pages "FOSS Course, UPenn, Murphy" and "Requirements Engineering, CSU Long Beach, Penzenstadler"

From TeachingOpenSource
(Difference between pages)
 
 
Line 1: Line 1:
== 0. Overview ==
=== Overview ===


{| border="1"
{{Course Overview
|-
|course=
! style="text-align:right;"| Course Name
Requirements Engineering
| ''Open Source Software Development''
|institution=
|-
California State University Long Beach
! style="text-align:right;"| Course Overview
|instructors=
| This course exposes students to the cultural, technical, and legal aspects of FOSS development and provides students with an opportunity to contribute to a real-world open-source software project, and gain experience in software maintenance and enhancing software quality.
Birgit Penzenstadler
|-
|offerings=
! style="text-align:right;"| Instructor Contact Info
CECS 542, California State University Long Beach, Birgit Penzenstadler, 4th year undergraduate, or graduate
| [[User:Cmurphy|Chris Murphy]]
|overview=
|-
Intermediate/advanced, elective. <br/> This course aims to equip students to develop techniques of software-intensive systems through successful requirements analysis techniques and requirements engineering. <br/> Students learn systematic process of developing requirements through cooperative problem analysis, representation, and validation. <br/> Lecture 2 hours, Lab 4 hours. <br/> Semester long team project plus midterm and final exam.
! style="text-align:right;"| Student Characteristics
|students=
| The course is targeted to upper-level undergraduate or graduate students.  
15-30 students of mixed backgrounds, some transfer, so not necessarily same software engineering knowledge
|-
|prerequisites=
! style="text-align:right;"| Prerequisites
basic knowledge about the principles of software engineering and the software lifecycle
| Students should have completed a traditional software engineering course and have had experience working in groups. They should be familiar with GitHub and the target programming language for the FOSS project on which they will work.
|infrastructure=
|-
classroom, lab, slides, online materials
! style="text-align:right;"| Infrastructure
}}
| The class meets twice a week for 75 minutes each. In general, one of the class meetings will consist of discussions of the reading assignments and/or guest speakers, and the other class meeting that week will be for learning activities, project status updates and presentations, or time to work on the project.  
 
|-
=== Learning Objectives ===
! style="text-align:right;"| Offerings
 
| Univ of Pennsylvania: CIS 399 Special Topics, [http://www.seas.upenn.edu/~cdmurphy/foss/fall2016/ Fall 2016] (14 undergraduates)
This course is the essential stepping-stone for conducting successful large, complex software engineering projects. It introduces students in depth to requirements engineering, which lays the foundation for design and all subsequent development phases. It prepares students for complex projects by introducing them to a variety of techniques that enable to analyze and specify requirements from different application domains and stakeholders. The course provides students with the necessary skillset to communicate, analyze, and negotiate with a wide range of potential stakeholders in a project.
|-
After completing the course students will be able to elicit, analyze, document and verify and validate requirements. <br/>
|}
In particular, they will be able to perform:
* Stakeholder identification and analysis
* Goal identification and analysis
* Creating and refining a system vision
* Developing a domain model of all involved application domains
* Developing a usage model (in the form of UML use cases)
* Eliciting and specifying quality requirements
* Quality assurance techniques
* Requirements management
Furthermore, they will be able to navigate a free open source software context with its development processes and best practices.
 
=== Methods of Assessment ===


== 1. Learning Objectives ==
The students will undertake a semester-long requirements engineering project, composed of individual, written assignments (to practice and demonstrate the skills from the course objectives above). Students may form teams of no more than three members. All members must participate equally, although not necessarily doing the same jobs.
As a result of completing this course, students will be able to do the following:
Per learning objective, there is a team assignment or an individual assignment that is worked on in lab and then further improved and finalized as homework.
* describe the technical, cultural, legal, and business foundations of FOSS
* engage with and make contributions to a FOSS project community


== 2. Methods of Assessment ==
Sample assignments:
Each week, students are expected to post to their public blogs a 200-300 word response to the weekly reading assignment. In some cases, specific prompts may be given but in general the prompt is open-ended. Blog posts are assessed on the following scale:
* Eliciting and documenting the stakeholders for a software system.
* Exceptional: a blog post that is particularly insightful, thorough, or thought-provoking
* Developing a use case in UML.
* Satisfactory: a blog post that demonstrates that the student has read the articles, understands their main points, and can synthesize a response including personal insight
* Performing a review of quality requirements.
* Unsatisfactory: a blog post that demonstrates that the student has not read the articles, does not understand the main points, and/or is simply summarizing the readings but not relaying any personal insight
* Not submitted: when it's... umm... "not submitted"


Students are also expected to attend and participate in all discussions of the reading assignments. Participation is assessed on the following scale:
In addition, there are two exams, a midterm and a final. The author usually gives the students the respective midterm and final of the previous year as practice exams.
* Exceptional: numerous contributions to the discussion that are particularly insightful, thorough, or thought-provoking
* Satisfactory: multiple contributions to the discussion that reflect the student's personal insight
* Unsatisfactory: few or no contributions to the discussion, or contributions that do not offer any insight
* Unexcused absence: when they're... ehhh... "absent" (without a verified excuse)


For learning activities and other class meetings (not involving discussions of reading assignments), students are simply assessed as present or absent.
=== Course Outline ===


Students are also expected to contribute to an open source project. The project on which the student will work must be approved by the instructor. If possible, a mentor within the project community should be identified and should be available to help the student with onboarding activities, becoming familiar with the project and community, and identifying tasks to work on.
This course exposes students to the problem of determining and specifying what a proposed software system should do, why and for whom the system is needed, not how the system should do it, which is the topic of downstream software engineering activities such as design and coding. There are some nontechnical aspects of the course, with respect to communication and negotiation with multiple stakeholders.  Most of the course covers technical approaches to the requirements problem, such as techniques for eliciting stakeholder goals and requirements, notations and models for documenting and specifying requirements, strategies for negotiating requirements, and techniques for analyzing documented requirements. In detail, the course covers the following topics (1 per week, 2 class meetings per week):


There are three milestones for contributions to the project: an initial task (usually around week 3 or 4 in a 13-week course, assuming work starts around week 2); a small task (around week 7 or 8); and a large task (at the end of the course). Each milestone is assessed by the mentor and/or the instruction staff on the following scale:
# Why do we need Requirements Engineering and what is it?
* Exceptional: contributions that exceed expectations and are of very high quality
# Principles: Definitions, process, roles
* Satisfactory: contributions that meet expectations and are of acceptable quality to the community
# System Models: Decomposition and abstraction, system views
* Unsatisfactory: contributions that fail to meet expectations or are of low quality
# Frameworks: What reference structures can I use for requirements?
# Business Case Analysis: Why are we building this system?
# Stakeholders: Who are the people to talk to about requirements?
# Goals and Constraints: What are the major objectives for the system?
# System Vision: What exactly do we want to achieve?
# Domain Models: What are the surrounding systems ours interacts with?
# Usage Models: How will the system interact with the user?
# Software quality models: How to determine the quality characteristics?
# Quality requirements: How to specify which qualities need to be met?
# Quality assurance: How to ensure that RE is done in a good way?
# Change management: How to evolve requirements?


Additionally, students are expected to post project updates to their blogs each week, in which they describe: what they have accomplished in the past week (with supporting evidence such as links to discussion board posts, GitHub PRs, etc.); if they did not accomplish everything planned, why not; how much time they spent on the project last week; what they hope to accomplish in the following week; and what might prevent them from doing so. Weekly blog posts are assessed as follows:
The class consists of interactive lectures from faculty and of lab discussion sessions. The assignments that are carried out in teams will be discussed together in class. Students will benefit from structured lectures that cover an adequate number of examples to facilitate student learning and introduce students to the topics covered. The instructor will introduce all requirements engineering methods and techniques in lectures using a number of examples and hands-on collaborative exercises using HFOSS. Also students will be provided with individual and team assignments and projects that are done outside of class or lab.
* Satisfactory: a blog post in which the student answers all of the prompts
* Unsatisfactory: a blog post in which some prompts are unanswered or not taken seriously
* Not submitted: when it's... like... "not submitted"


Finally, students are expected to submit a final report in which they describe and reflect on their experience and the course in general. The final report is assessed as follows:
The following table provides a course overview per week. Each row per week describes the lecture topic and lab topic and activities. Note that this course currently has two meetings per week and CSULB has 15 week semesters, so some topics may have to be shortened in a different course setting.
* Satisfactory: a report in which the student answers all of the prompts
* Unsatisfactory: a report in which some prompts are unanswered or not taken seriously
* Not submitted: when it's... ya know...


== 3. Course Outline ==
{| class="wikitable" cellpadding="10" ! style="text-align:center; color:purple"
{| class="wikitable" cellpadding="10" ! style="text-align:center; color:purple"
!  Week
!  Week
!  Topics/Activities
!  Lectures
!  Reading Assignments
! Labs / Activities
!  Reading / Resources
 
|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 1
| 1
| Course Introduction
| Course Introduction  
* Course logistics
* [http://foss2serve.org/index.php/File:2017_spring_542CourseSyllabus.pdf Syllabus]
* Brief overview of FOSS
* Why do we need Requirements Engineering and what is it?
* [[Fossisms]]
[https://www.slideshare.net/kamikitty/requirements-engineering-introduction| Slides "Introduction to RE"]
Blogs, IRC, and GitHub
* Introduction to natural language requirements
* Activity: [https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-tools-activity.txt FOSS tools], based on [[Blog_Activity]], [[Intro_IRC_Activity]], and [[Git:_GitHub_Issues_and_Pull_Requests]]
[https://www.slideshare.net/secret/NOcw2ahpblic2g Slides EARS - "Easy Approach to Requirements Syntax"]
| Open source intro and EARS
* Brief overview of HFOSS and the planned activities
* Review HFOSS projects for interest: [http://openmrs.org/]
* [[Practice EARS (Activity)]] approach for OpenMRS requirements
|
|
* [https://www.gnu.org/philosophy/free-sw.html Free software]
* [https://en.wikipedia.org/wiki/Open-source_software Open source software]
* [http://www.foss2serve.org/index.php/HFOSS_Communities HFOSS communities]
* Review HFOSS project [http://openmrs.org/ OpenMRS]
* [http://foss2serve.org/index.php/50_Ways_to_be_a_FOSSer 50 ways to be a FOSSer]


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 2
| 2
| FOSS Background
| Processes and frameworks
* What are the intellectual, technical, and cultural foundations and justifications of FOSS?
* What is the general process and what are the roles that perform RE?
* How does FOSS differ from commercial software?
[https://www.slideshare.net/kamikitty/requirements-engineering-process-roles Slides "Principles: Process and roles"]
FOSS Field Trip and Project Evaluation
* What reference structures can I use for requirements?
* Activity: [https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt Evaluating a FOSS project], based on [[Project_Anatomy_Activity]], [[FOSS_Field_Trip_Activity]], and [[Project_Evaluation_Activity]]
[https://www.slideshare.net/kamikitty/requirements-engineering-frameworks-standards Slides "Frameworks, templates, and standards"]  
|
[[Requirements engineering process (Activity)]]
* Identify the requirements engineering process steps used in HFOSS project
* Compare to traditional requirements engineering phases and artifact-oriented requirements engineering.
 
[[Mapping Requirements Specification Standards (Activity)]]
* Research the ISO RE standard 29148 and requirements specification templates.
|
|
*[https://en.wikipedia.org/wiki/Open-source_software Wikipedia article on FOSS]
* [http://ieeexplore.ieee.org/document/720574/ Standard on Requirements Specifications IEEE 830]
*[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html Eric Raymond, ''The Cathedral and the Bazaar'']
* [https://www.iso.org/standard/45171.html ISO standard 29148 on Requirements engineering]
*[http://www.gnu.org/philosophy/open-source-misses-the-point.html Richard Stallman, "Why Open Source misses the point of Free Software"]
* [https://blog.newrelic.com/2014/05/05/open-source_gettingstarted/ Getting started with open source]
* [https://opensource.com/life/13/4/ten-ways-participate-open-source 10 ways to participate in open source]
* [http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/ 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star]
* [https://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/ How to Contribute to Open Source Without Coding]


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 3
| 3
| Getting Started in FOSS
| Artifact-oriented requirements engineering
* How do you learn about a FOSS project's culture and community?
* Artifact model for domain-indenpendent requirements engineering
* How do you get involved in and known within a community?
[https://www.slideshare.net/kamikitty/requirements-engineering-artifactoriented-requirements-engineering Slides "AMDiRE"]
Start Getting Involved in Project
* Why are we building this system?
* Learning Activity -- '''COMING SOON!'''
[https://www.slideshare.net/kamikitty/requirements-engineering-business-case-analysis Slides "Business Case Analysis"]
|
[[Exploring artifact models (Activity)]]
* Find the requirements documented for OpenMRS and sort the information into a requirements specification template.
|
|
* https://opensource.com/life/13/4/ten-ways-participate-open-source
* [https://link.springer.com/article/10.1007/s00766-014-0206-y AMDiRE article] by Mendez and Penzenstadler, Requirements Engineering, Springer
* https://blog.newrelic.com/2014/05/05/open-source_gettingstarted/


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 4
| 4
| Ways of Contributing to FOSS
| Stakeholders
* What are the different types of contributions someone can make to a FOSS project?
* Who are the people to talk to about requirements?
* What is the process of making contributions?
[https://www.slideshare.net/kamikitty/requirements-engineering-stakeholders Slides "Stakeholders"]
|
[[(Re-)Engineering stakeholders (Activity)]]
* Make list of stakeholders in HFOSS project
* Make stakeholder model (deliverable)
|
|
* https://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/
* [http://ieeexplore.ieee.org/abstract/document/1259199/ Understanding project sociology by modeling stakeholders] by Alexander and Robertson, IEEE Software
* http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/
* http://words.steveklabnik.com/how-to-be-an-open-source-gardener


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 5
| 5
| What Motivates People to Contribute to FOSS
| Goals
* Why do people contribute to FOSS projects?
* What are the major objectives for the system?
* In what ways are people rewarded for their contributions?
[https://www.slideshare.net/kamikitty/requirements-engineering-goals Slides "Goals and Constraints"]
* Does motivation rely on the type of contribution, or vice-versa?
|
[[(Re-)Engineering goals (Activity)]]
* Make list of goals in HFOSS project
* Make goal model (deliverable)
|
|
* [http://l3d.cs.colorado.edu/~yunwen/papers/ICSE03.pdf Yunwen Ye and Kouichi Kishida, "Toward an Understanding of the Motivation of Open Source Software Developers", ICSE 2003]
* [http://dl.acm.org/citation.cfm?id=2451609 A generic model for sustainability] by Penzenstadler and Femmer, GIBSE 2013
* [http://www.diss.fu-berlin.de/docs/servlets/MCRFileNodeServlet/FUDOCS_derivate_000000000137/discpaper19_04.pdf J. Blitzer, W. Schrettl, and P. J. H. Schroder, "Intrinsic Motivation in Open Source Software Development", ''Journal of Comparative Economics'' 35:1]


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 6
| 6
| Licensing and Legal Issues
| System Vision
* What are the different licensing options for FOSS projects?
* What exactly do we want to achieve?
* Why would someone choose one over the other?
[https://www.slideshare.net/kamikitty/requirements-engineering-system-vision Slides "System Vision"]
* Note: we usually have a guest speaker from the Law School for this discussion
* What information sources do I need?
[https://www.slideshare.net/kamikitty/requirements-engineering-system-vision Slides "Information sources for system visions and quality assurance"] (2nd half of same slide set)
|
[[(Re-)Engineering a system vision (Activity)]]
* Making a rich picture for the future OpenMRS
|
|
* http://opensource.org/faq
* [http://www.moodle2.tfe.umu.se/pluginfile.php/32063/mod_resource/content/1/Rich%20pictures%20-monk.pdf Monk & Howard: Methods & tools: the rich picture: a tool for reasoning about work context]
* http://opensource.com/law/13/1/which-open-source-software-license-should-i-use
* Online tutorial by TheOpenUniversity (link)
* http://oss-watch.ac.uk/resources/fossandpatents


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 7
| 7  
| FOSS Business Models and Opportunities
| Domain Models
* How do companies make money from FOSS?
* What are the surrounding systems ours interacts with?
* What advantages does this have over commercial software?
[https://www.slideshare.net/kamikitty/requirements-engineering-domain-models Slides "Domain Models"]
| [[(Re-)Engineering a domain model (Activity)]]
* Develop a UML domain model for a system under analysis.
|
|
* https://handsontable.com/blog/articles/5-successful-business-models-for-web-based-open-source-projects
* [http://ieeexplore.ieee.org/abstract/document/130660/ Domain modeling for software engineering] by N. Iscoe, G.B. Williams, and G. Arango
* http://www.zdnet.com/article/11-open-source-business-models/
* http://www.cio.com/article/2944334/open-source-development/why-the-open-source-business-model-is-a-failure.html


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 8
| 8
| Humanitarian FOSS
| Midterm
* How do HFOSS projects differ from conventional FOSS projects?
* Recap, questions and answers
* [http://foss2serve.org/index.php/File:MidtermSolution.pdf Midterm]
|
Q & A session
* Discussion
|
|
* http://timreview.ca/article/399
* [http://foss2serve.org/index.php/File:MidtermPracticeSolution.pdf Midterm practice]
* https://opensource.com/life/15/2/getting-involved-hfoss
 
* http://www.slate.com/articles/technology/future_tense/2014/09/hfoss_software_for_humanity_computer_science_students_solve_real_world_problems.html


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 9
| 9
| FOSS Success Stories
| Usage Models
* What are examples of successful FOSS projects and organizations?
* How will the system interact with the user?
* What has made them successful?
[https://www.slideshare.net/kamikitty/requirements-engineering-usage-models Slides "Usage Models"]
* What has caused other projects/organizations to not be as successful?
| Use cases
* Lab 1: [[(Re-)Engineering use cases (Activity)]]
* Lab 2: Refine/rework use cases after feedback (deliverable)
|
|
* http://mediashift.org/2013/08/6-things-to-know-about-successful-open-source-software/
* [http://alistair.cockburn.us/Basic+use+case+template Cockburn's Use Case Template]
* http://www.infoworld.com/article/3058778/open-source-tools/the-secrets-to-linkedins-open-source-success.html
* [https://link.springer.com/article/10.1007/s00766-004-0194-4 Sindre & Opdahl: Eliciting security requirements with misuse cases, REJ 2005]
* http://www.techrepublic.com/article/red-hats-open-source-success-story-built-on-killing-complexity-in-it/
* https://techcrunch.com/2014/02/13/please-dont-tell-me-you-want-to-be-the-next-red-hat/


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 10
| 10
| Starting and Growing a FOSS Community
| Scaling RE and RE tools
* How does one go about growing a FOSS community?
* How to adapt RE for a specific project setting?  
* What are some pitfalls in doing so?
[https://www.slideshare.net/kamikitty/requirements-engineering-scaling-re-requirements-refinement Slides "Scaling RE, refining requirements, and system models"]
* How to select RE tools?
[https://www.slideshare.net/kamikitty/requirements-engineering-re-tools Slides "RE Tools"]
| Tools and assessment
* Activity for Lab 1: try out requirements engineering tools
* Lab 2: Write an assessment of one other requirements engineering tool [http://foss2serve.org/index.php/File:2017_542_Lab_RE-Tools.pdf Assignment Sheet]
|
|
* http://oss-watch.ac.uk/resources/howtobuildcommunity
* [http://ieeexplore.ieee.org/abstract/document/5929527/ Requirements Engineering Tools] by Juan M. Carrillo de Gea et al., IEEE Software, 2011
* http://www.drdobbs.com/open-source/building-and-maintaining-an-open-source/240168415
* https://opensource.com/business/14/7/building-open-source-community


|- style="text-align:left; color:black"
|- style="text-align:left; color:black"
| 11
| 11
| Criticisms of FOSS
| Non-functional requirements
* What are some of the drawbacks of FOSS as a way of developing software?
* How to deal with requirements that are not about functionality?
* Can/does FOSS live up to its expectations?
* How to specify which qualities need to be met?
[https://www.slideshare.net/kamikitty/requirements-engineering-nonfunctional-requirements Slides "Classification of non-functional requirements"]
| Non-functional requirements
* [[(Re-)Engineering Quality requirements (Activity)]]
|
* [http://www.ptidej.net/courses/log3410/fall11/Lectures/Article_5.pdf Rethinking the notion of non-functional requirements] by Martin Glinz, Proc. Third World Congress for Software Quality, 2005
* [http://ieeexplore.ieee.org/abstract/document/6381398/ Non-functional requirements in architectural decision making] by D Ameller, C Ayala, J Cabot, X Franch - IEEE software, 2013
 
|- style="text-align:left; color:black"
| 12
| Quality models
* How to determine the quality characteristics?
[https://www.slideshare.net/kamikitty/requirements-engineering-quality-models Slides "Software quality models"]
| Quality models
* Activity: Perform peer review of non-functional requirements elaborated by other team and give feedback on how to improve them.
|
|
* http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community
* [http://ieeexplore.ieee.org/abstract/document/476281/ Software quality: the elusive target] by B Kitchenham, SL Pfleeger - IEEE software, 1996
* http://www.techrepublic.com/article/linux-creator-linus-torvalds-doesnt-really-care-about-open-source/
 
* http://www.infoworld.com/article/2905331/open-source-software/the-new-struggles-facing-open-source.html
|- style="text-align:left; color:black"
| 13
| Quality assurance
* How to ensure that RE is done in a good way?
[https://www.slideshare.net/kamikitty/requirements-engineering-quality-assurance Slides "Quality assurance"]
| Quality assurance in documentation
* [[Documentation Quality Assurance (Activity)]]
|
* [http://ieeexplore.ieee.org/document/720574/ Standard on Requirements Specifications IEEE 830]
* [https://www.iso.org/standard/45171.html ISO standard 29148 on Requirements engineering]
* [https://www.iso.org/standard/35733.html ISO 25010 Standard for Software Quality Models]
* [https://standards.ieee.org/findstds/standard/730-2014.html IEEE 730-2014 Standard for Software Quality Assurance Processes]
 
|- style="text-align:left; color:black"
| 14
| Requirements management
* How to evolve requirements?
[https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Slides "Change management"]
* How to anticipate and plan for risks.
[https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Slides "Risk management"] (2nd half of slide set)
* How to put it all together
[https://www.slideshare.net/kamikitty/requirements-engineering-wrapup-putting-it-all-together Slides "Wrap-up"]
| Requirements management
* Activity: [http://foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity) Bug tracker activity]
* Requirements Rationales (lab discussion on article, [http://foss2serve.org/index.php/File:2017_542_ReqRationale.pdf req. rationale assignment sheet])
|
* [http://ieeexplore.ieee.org/abstract/document/7325184/ Guidelines for Managing Requirements Rationales] by AK Thurimella, M Schubanz, A Pleuss… - IEEE Software, 2017
 
|- style="text-align:left; color:black"
| 15
| Research and Recap
* Research topics
[https://www.slideshare.net/kamikitty/requirements-engineering-present-and-future-hot-research-topics Slides "Hot topics in current and future research"]
* Recap of the 2nd half of the semester
[https://www.slideshare.net/kamikitty/requirements-engineering-recap Slides "Recap"]
| Final exam
* [http://foss2serve.org/index.php/File:FinalPracticeSolution.pdf Final practice]
* [http://foss2serve.org/index.php/File:FinalSolution.pdf Final]
|
* [http://dl.acm.org/citation.cfm?id=336523 Requirements engineering: a roadmap] by B Nuseibeh, S Easterbrook - Proceedings of the Conference on the Future of Software Engineering, 2000
* [http://dl.acm.org/citation.cfm?id=1254725 Research directions in requirements engineering] by BHC Cheng, JM Atlee - 2007 Future of Software Engineering, 2007
|}
|}


== 4. Notes to Instructor ==
The schedule above lists 11 weeks but can be expanded to a longer schedule depending on breaks, exams, etc.


== 5. Moving Forward ==
=== Notes to Instructor ===
This variant of this course will be first taught in Fall 2016; modifications will be reported back in early 2017.  
* If the whole set of activities seems to much, I have grouped a subset that contains the activities for [[(Re-)Engineering a Software Requirements Specification]] that leaves the other aspects (processes, standards, requirements management, etc.) aside.
 
* Lessons learned
** Students like working with real systems as opposed to "toy systems" they come up with
** Re-documenting a software system is kind of boring, so I'd suggest to find a happy medium in between letting students recover requirements and letting them come up with new ones.
** It seems a little tough to get some open source communities interested in reengineering requirements, as they are focused on moving forward with the system and don't necessarily see a need for higher level requirements.
 
* Books: Here are a couple of books on requirements engineering as this topic is not covered in depth within this wiki:
** [https://books.google.at/books/about/Software_Requirements.html?id=40lDmAEACAAJ&redir_esc=y Karl Wiegers and Joy Beatty: “Software Requirements”]
** [https://books.google.at/books?id=AYk_AQAAIAAJ&q=Axel+van+Lamsweerde:+%E2%80%9CRequirements+Engineering%E2%80%9D&dq=Axel+van+Lamsweerde:+%E2%80%9CRequirements+Engineering%E2%80%9D&hl=en&sa=X&ved=0ahUKEwjL-oDB_KHVAhWLaRQKHTjdAPgQ6AEIJjAA Axel van Lamsweerde: “Requirements Engineering”]
** [https://books.google.at/books?id=0i2ERQAACAAJ&dq=Klaus+Pohl:+%E2%80%9CRequirements+Engineering%E2%80%9D&hl=en&sa=X&ved=0ahUKEwjLiJTM_KHVAhXKbhQKHTnPAJ4Q6AEIJjAA Klaus Pohl: “Requirements Engineering”]
 
For the HFOSS part of the course, please refer to the internal and external references in the table above.
 
=== Moving Forward ===
 
* This course was held for the first time in Spring 2017 in the specific format presented above. The underlying course on requirements engineering has been developed and evolved over the past 10 years.
* The data collected is still under analysis.


--------------------
--------------------
This work is licensed under a
{{License CC BY SA}}
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]
 
[[File:CC_license.png]]


Materials linked to by this page may be governed by other licenses.
Materials linked to by this page may be governed by other licenses.


[[Category: Course]]
[[Category: Courses]]
[[Category: Education]]
[[Category:Requirements_Engineering]]

Revision as of 17:50, 24 July 2017

Overview

Course Requirements Engineering
Institution California State University Long Beach
Instructor(s) Birgit Penzenstadler
Term CECS 542, California State University Long Beach, Birgit Penzenstadler, 4th year undergraduate, or graduate
Course Overview Intermediate/advanced, elective.
This course aims to equip students to develop techniques of software-intensive systems through successful requirements analysis techniques and requirements engineering.
Students learn systematic process of developing requirements through cooperative problem analysis, representation, and validation.
Lecture 2 hours, Lab 4 hours.
Semester long team project plus midterm and final exam.
Course Length {{{courselength}}}
Student Characteristics 15-30 students of mixed backgrounds, some transfer, so not necessarily same software engineering knowledge
Prerequisites basic knowledge about the principles of software engineering and the software lifecycle
Infrastructure classroom, lab, slides, online materials


Learning Objectives

This course is the essential stepping-stone for conducting successful large, complex software engineering projects. It introduces students in depth to requirements engineering, which lays the foundation for design and all subsequent development phases. It prepares students for complex projects by introducing them to a variety of techniques that enable to analyze and specify requirements from different application domains and stakeholders. The course provides students with the necessary skillset to communicate, analyze, and negotiate with a wide range of potential stakeholders in a project. After completing the course students will be able to elicit, analyze, document and verify and validate requirements.
In particular, they will be able to perform:

  • Stakeholder identification and analysis
  • Goal identification and analysis
  • Creating and refining a system vision
  • Developing a domain model of all involved application domains
  • Developing a usage model (in the form of UML use cases)
  • Eliciting and specifying quality requirements
  • Quality assurance techniques
  • Requirements management

Furthermore, they will be able to navigate a free open source software context with its development processes and best practices.

Methods of Assessment

The students will undertake a semester-long requirements engineering project, composed of individual, written assignments (to practice and demonstrate the skills from the course objectives above). Students may form teams of no more than three members. All members must participate equally, although not necessarily doing the same jobs. Per learning objective, there is a team assignment or an individual assignment that is worked on in lab and then further improved and finalized as homework.

Sample assignments:

  • Eliciting and documenting the stakeholders for a software system.
  • Developing a use case in UML.
  • Performing a review of quality requirements.

In addition, there are two exams, a midterm and a final. The author usually gives the students the respective midterm and final of the previous year as practice exams.

Course Outline

This course exposes students to the problem of determining and specifying what a proposed software system should do, why and for whom the system is needed, not how the system should do it, which is the topic of downstream software engineering activities such as design and coding. There are some nontechnical aspects of the course, with respect to communication and negotiation with multiple stakeholders. Most of the course covers technical approaches to the requirements problem, such as techniques for eliciting stakeholder goals and requirements, notations and models for documenting and specifying requirements, strategies for negotiating requirements, and techniques for analyzing documented requirements. In detail, the course covers the following topics (1 per week, 2 class meetings per week):

  1. Why do we need Requirements Engineering and what is it?
  2. Principles: Definitions, process, roles
  3. System Models: Decomposition and abstraction, system views
  4. Frameworks: What reference structures can I use for requirements?
  5. Business Case Analysis: Why are we building this system?
  6. Stakeholders: Who are the people to talk to about requirements?
  7. Goals and Constraints: What are the major objectives for the system?
  8. System Vision: What exactly do we want to achieve?
  9. Domain Models: What are the surrounding systems ours interacts with?
  10. Usage Models: How will the system interact with the user?
  11. Software quality models: How to determine the quality characteristics?
  12. Quality requirements: How to specify which qualities need to be met?
  13. Quality assurance: How to ensure that RE is done in a good way?
  14. Change management: How to evolve requirements?

The class consists of interactive lectures from faculty and of lab discussion sessions. The assignments that are carried out in teams will be discussed together in class. Students will benefit from structured lectures that cover an adequate number of examples to facilitate student learning and introduce students to the topics covered. The instructor will introduce all requirements engineering methods and techniques in lectures using a number of examples and hands-on collaborative exercises using HFOSS. Also students will be provided with individual and team assignments and projects that are done outside of class or lab.

The following table provides a course overview per week. Each row per week describes the lecture topic and lab topic and activities. Note that this course currently has two meetings per week and CSULB has 15 week semesters, so some topics may have to be shortened in a different course setting.

Week Lectures Labs / Activities Reading / Resources
1 Course Introduction
  • Syllabus
  • Why do we need Requirements Engineering and what is it?

Slides "Introduction to RE"

  • Introduction to natural language requirements

Slides EARS - "Easy Approach to Requirements Syntax"

Open source intro and EARS
  • Brief overview of HFOSS and the planned activities
  • Review HFOSS projects for interest: [1]
  • Practice EARS (Activity) approach for OpenMRS requirements
2 Processes and frameworks
  • What is the general process and what are the roles that perform RE?

Slides "Principles: Process and roles"

  • What reference structures can I use for requirements?

Slides "Frameworks, templates, and standards"

Requirements engineering process (Activity)

  • Identify the requirements engineering process steps used in HFOSS project
  • Compare to traditional requirements engineering phases and artifact-oriented requirements engineering.

Mapping Requirements Specification Standards (Activity)

  • Research the ISO RE standard 29148 and requirements specification templates.
3 Artifact-oriented requirements engineering
  • Artifact model for domain-indenpendent requirements engineering

Slides "AMDiRE"

  • Why are we building this system?

Slides "Business Case Analysis"

Exploring artifact models (Activity)

  • Find the requirements documented for OpenMRS and sort the information into a requirements specification template.
  • AMDiRE article by Mendez and Penzenstadler, Requirements Engineering, Springer
4 Stakeholders
  • Who are the people to talk to about requirements?

Slides "Stakeholders"

(Re-)Engineering stakeholders (Activity)

  • Make list of stakeholders in HFOSS project
  • Make stakeholder model (deliverable)
5 Goals
  • What are the major objectives for the system?

Slides "Goals and Constraints"

(Re-)Engineering goals (Activity)

  • Make list of goals in HFOSS project
  • Make goal model (deliverable)
6 System Vision
  • What exactly do we want to achieve?

Slides "System Vision"

  • What information sources do I need?

Slides "Information sources for system visions and quality assurance" (2nd half of same slide set)

(Re-)Engineering a system vision (Activity)

  • Making a rich picture for the future OpenMRS
7 Domain Models
  • What are the surrounding systems ours interacts with?

Slides "Domain Models"

(Re-)Engineering a domain model (Activity)
  • Develop a UML domain model for a system under analysis.
8 Midterm
  • Recap, questions and answers
  • Midterm

Q & A session

  • Discussion


9 Usage Models
  • How will the system interact with the user?

Slides "Usage Models"

Use cases
10 Scaling RE and RE tools
  • How to adapt RE for a specific project setting?

Slides "Scaling RE, refining requirements, and system models"

  • How to select RE tools?

Slides "RE Tools"

Tools and assessment
  • Activity for Lab 1: try out requirements engineering tools
  • Lab 2: Write an assessment of one other requirements engineering tool Assignment Sheet
11 Non-functional requirements
  • How to deal with requirements that are not about functionality?
  • How to specify which qualities need to be met?

Slides "Classification of non-functional requirements"

Non-functional requirements
12 Quality models
  • How to determine the quality characteristics?

Slides "Software quality models"

Quality models
  • Activity: Perform peer review of non-functional requirements elaborated by other team and give feedback on how to improve them.
13 Quality assurance
  • How to ensure that RE is done in a good way?

Slides "Quality assurance"

Quality assurance in documentation
14 Requirements management
  • How to evolve requirements?

Slides "Change management"

  • How to anticipate and plan for risks.

Slides "Risk management" (2nd half of slide set)

  • How to put it all together

Slides "Wrap-up"

Requirements management
15 Research and Recap
  • Research topics

Slides "Hot topics in current and future research"

  • Recap of the 2nd half of the semester

Slides "Recap"

Final exam


Notes to Instructor

  • Lessons learned
    • Students like working with real systems as opposed to "toy systems" they come up with
    • Re-documenting a software system is kind of boring, so I'd suggest to find a happy medium in between letting students recover requirements and letting them come up with new ones.
    • It seems a little tough to get some open source communities interested in reengineering requirements, as they are focused on moving forward with the system and don't necessarily see a need for higher level requirements.

For the HFOSS part of the course, please refer to the internal and external references in the table above.

Moving Forward

  • This course was held for the first time in Spring 2017 in the specific format presented above. The underlying course on requirements engineering has been developed and evolved over the past 10 years.
  • The data collected is still under analysis.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC BY SA.png


Materials linked to by this page may be governed by other licenses.

Retrieved from "https://teachingopensource.org/index.php?title=FOSS_Course,_UPenn,_Murphy&oldid=8045"
Powered by MediaWiki