Requirements Engineering, CSU Long Beach, Penzenstadler
m |
|||
Line 42: | Line 42: | ||
=== Methods of Assessment === | === Methods of Assessment === | ||
− | * | + | * 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. |
− | * | + | * 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 === | === Course Outline === | ||
Line 66: | Line 65: | ||
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 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. | 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. | ||
Line 78: | Line 70: | ||
{| class="wikitable" cellpadding="10" ! style="text-align:center; color:purple" | {| class="wikitable" cellpadding="10" ! style="text-align:center; color:purple" | ||
! Week | ! Week | ||
− | ! | + | ! Lecture |
+ | | Lab / Activities | ||
! Reading Assignments | ! Reading Assignments | ||
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
| 1 | | 1 | ||
− | | Course Introduction | + | | Course Introduction and syllabus ([[File:2017 spring 542CourseSyllabus.pdf]]) |
− | + | Brief overview of RE - Why do we need Requirements Engineering and what is it? | |
− | + | | | |
− | + | Brief overview of HFOSS and the planned activities | |
| | | | ||
* https://www.gnu.org/philosophy/free-sw.html | * https://www.gnu.org/philosophy/free-sw.html | ||
Line 96: | Line 89: | ||
| Topic | | Topic | ||
* Lecture: Principles: Definitions, process, roles, problem/solution view, artifact orientation | * Lecture: Principles: Definitions, process, roles, problem/solution view, artifact orientation | ||
+ | | | ||
* Lab: Find the equivalents of those elements in HFOSS project, e.g. OpenMRS | * Lab: Find the equivalents of those elements in HFOSS project, e.g. OpenMRS | ||
| | | | ||
− | * https://opensource.com/life/13/4/ten-ways-participate-open-source | + | * [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" | ||
Line 105: | Line 101: | ||
| Topic | | Topic | ||
* Lecture: System Models: Decomposition and abstraction, system views | * Lecture: System Models: Decomposition and abstraction, system views | ||
+ | | | ||
* Activity: | * Activity: | ||
| | | | ||
Line 113: | Line 110: | ||
| Topic | | Topic | ||
* Lecture: Frameworks: What reference structures can I use for requirements? | * Lecture: Frameworks: What reference structures can I use for requirements? | ||
+ | | | ||
* Lab: Introduce activity [[(Re-)Engineering a Software Requirements Specification]] (to be filled in) | * Lab: Introduce activity [[(Re-)Engineering a Software Requirements Specification]] (to be filled in) | ||
** Part 1: Research the ISO RE standard 29148 and requirements specification templates. | ** Part 1: Research the ISO RE standard 29148 and requirements specification templates. | ||
Line 123: | Line 121: | ||
| Topic | | Topic | ||
* Lecture: Business Case Analysis: Why are we building this system? | * Lecture: Business Case Analysis: Why are we building this system? | ||
+ | | | ||
* Lab: Make a business case (pitch) for a system | * Lab: Make a business case (pitch) for a system | ||
| | | | ||
Line 131: | Line 130: | ||
| Topic | | Topic | ||
* Lecture: Stakeholders: Who are the people to talk to about requirements? | * Lecture: Stakeholders: Who are the people to talk to about requirements? | ||
+ | | | ||
* Lab: Activity [[(Re-)Engineering stakeholders, goals & questions]] part 1 (to be filled in) | * Lab: Activity [[(Re-)Engineering stakeholders, goals & questions]] part 1 (to be filled in) | ||
** Make list of stakeholders in HFOSS project | ** Make list of stakeholders in HFOSS project | ||
Line 141: | Line 141: | ||
| Topic | | Topic | ||
* Lecture: Goals and Constraints: What are the major objectives for the system? | * Lecture: Goals and Constraints: What are the major objectives for the system? | ||
+ | | | ||
* Lab: [[(Re-)Engineering stakeholders, goals & questions]] part 2 (to be filled in) | * Lab: [[(Re-)Engineering stakeholders, goals & questions]] part 2 (to be filled in) | ||
** Make list of goals in HFOSS project | ** Make list of goals in HFOSS project | ||
Line 151: | Line 152: | ||
| Topic | | Topic | ||
* Lecture: System Vision: What exactly do we want to achieve? | * Lecture: System Vision: What exactly do we want to achieve? | ||
+ | | | ||
* Activity: [[(Re-)Engineering a system vision]] (to be filled in) | * Activity: [[(Re-)Engineering a system vision]] (to be filled in) | ||
| | | | ||
Line 159: | Line 161: | ||
| 9 | | 9 | ||
| Topic | | Topic | ||
− | |||
* Lecture: Domain Models: What are the surrounding systems ours interacts with? | * Lecture: Domain Models: What are the surrounding systems ours interacts with? | ||
+ | | | ||
+ | * Activity | ||
| | | | ||
* read this | * read this | ||
Line 168: | Line 171: | ||
| Topic | | Topic | ||
* Lecture: Usage Models: How will the system interact with the user? | * Lecture: Usage Models: How will the system interact with the user? | ||
+ | | | ||
* Activity: [[(Re-)Engineering use cases]] (to be filled in) | * Activity: [[(Re-)Engineering use cases]] (to be filled in) | ||
| | | | ||
Line 176: | Line 180: | ||
| Topic | | Topic | ||
* Lecture: Software quality models: How to determine the quality characteristics? | * Lecture: Software quality models: How to determine the quality characteristics? | ||
+ | | | ||
* Activity: [[Understanding Design and Checking Compliance]] (to be filled in) | * Activity: [[Understanding Design and Checking Compliance]] (to be filled in) | ||
Line 185: | Line 190: | ||
| Topic | | Topic | ||
* Lecture: Quality requirements: How to specify which qualities need to be met? | * Lecture: Quality requirements: How to specify which qualities need to be met? | ||
+ | | | ||
* Activity: [[(Re-)Engineering Quality requirements]] (to be filled in) | * Activity: [[(Re-)Engineering Quality requirements]] (to be filled in) | ||
| | | | ||
Line 193: | Line 199: | ||
| Topic | | Topic | ||
* Lecture: Quality assurance: How to ensure that RE is done in a good way? | * Lecture: Quality assurance: How to ensure that RE is done in a good way? | ||
+ | | | ||
* Activity: [[Documentation Quality Assurance]] (to be filled in) | * Activity: [[Documentation Quality Assurance]] (to be filled in) | ||
| | | | ||
Line 201: | Line 208: | ||
| Topic | | Topic | ||
* Lecture: Change management: How to evolve requirements? | * Lecture: Change management: How to evolve requirements? | ||
+ | | | ||
* Activity: Bug tracker activity (to be linked) | * Activity: Bug tracker activity (to be linked) | ||
| | | | ||
* read this | * read this | ||
+ | |||
+ | |- style="text-align:left; color:black" | ||
+ | | 15 | ||
+ | | Recap | ||
+ | | Final exam | ||
+ | | | ||
+ | * practice exam | ||
|} | |} |
Revision as of 12:40, 19 July 2017
Status: under construction until May 2017, but you can take a look at the work in progress.
Contents |
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. Letter grade only (A-F). |
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
- 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.
- 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):
- Why do we need Requirements Engineering and what is it?
- Principles: Definitions, process, roles
- System Models: Decomposition and abstraction, system views
- 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?
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 | Lecture | Lab / Activities | Reading Assignments |
---|---|---|---|
1 | Course Introduction and syllabus (File:2017 spring 542CourseSyllabus.pdf)
Brief overview of RE - Why do we need Requirements Engineering and what is it? |
Brief overview of HFOSS and the planned activities |
|
2 | Topic
|
|
|
3 | Topic
|
|
|
4 | Topic
|
|
|
5 | Topic
|
|
|
6 | Topic
|
|
|
7 | Topic
|
|
|
8 | Topic
|
|
|
9 | Topic
|
|
|
10 | Topic
|
|
|
11 | Topic
|
|
|
12 | Topic
|
|
|
13 | Topic
|
|
|
14 | Topic
|
|
|
15 | Recap | Final exam |
|
Notes to Instructor
- Tips, suggestions, lessons learned (warnings)...
Here are a couple of books on requirements engineering as this topic is not covered in depth within this wiki:
- Karl Wiegers and Joy Beatty: “Software Requirements”
- Axel van Lamsweerde: “Requirements Engineering”
- 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 is held for the first time in Spring 2017. If this page is not updated by August 2017 with experiences and further steps for moving forward, please hassle me per email so I do it :)
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Materials linked to by this page may be governed by other licenses.