Requirements Engineering, CSU Long Beach, Penzenstadler
m |
m (→Overview) |
||
(17 intermediate revisions by 2 users not shown) | |||
Line 11: | Line 11: | ||
CECS 542, California State University Long Beach, Birgit Penzenstadler, 4th year undergraduate, or graduate | CECS 542, California State University Long Beach, Birgit Penzenstadler, 4th year undergraduate, or graduate | ||
|overview= | |overview= | ||
− | Intermediate/advanced, elective. | + | 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. |
− | This course aims to equip students to develop techniques of software-intensive systems through successful requirements analysis techniques and requirements engineering. | + | |courselength=15 weeks |
− | 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. | + | |
|students= | |students= | ||
15-30 students of mixed backgrounds, some transfer, so not necessarily same software engineering knowledge | 15-30 students of mixed backgrounds, some transfer, so not necessarily same software engineering knowledge | ||
Line 26: | Line 24: | ||
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. | 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. | + | 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: | In particular, they will be able to perform: | ||
* Stakeholder identification and analysis | * Stakeholder identification and analysis | ||
Line 76: | Line 74: | ||
! Week | ! Week | ||
! Lectures | ! Lectures | ||
− | + | ! Labs / Activities | |
! Reading / Resources | ! Reading / Resources | ||
Line 84: | Line 82: | ||
* [http://foss2serve.org/index.php/File:2017_spring_542CourseSyllabus.pdf Syllabus] | * [http://foss2serve.org/index.php/File:2017_spring_542CourseSyllabus.pdf Syllabus] | ||
* Why do we need Requirements Engineering and what is it? | * Why do we need Requirements Engineering and what is it? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-introduction| Slides "Introduction to RE"] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-introduction?qid=427e2b42-e810-409a-a7ec-a26baca54015&v=&b=&from_search=2| Slides "Introduction to RE"] |
* Introduction to natural language requirements | * Introduction to natural language requirements | ||
− | [https://www.slideshare.net/secret/NOcw2ahpblic2g EARS - "Easy Approach to Requirements Syntax"] | + | [https://www.slideshare.net/secret/NOcw2ahpblic2g Slides EARS - "Easy Approach to Requirements Syntax"] |
| Open source intro and EARS | | Open source intro and EARS | ||
* Brief overview of HFOSS and the planned activities | * Brief overview of HFOSS and the planned activities | ||
* Review HFOSS projects for interest: [http://openmrs.org/] | * 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://www.gnu.org/philosophy/free-sw.html Free software] | ||
Line 96: | Line 94: | ||
* [http://www.foss2serve.org/index.php/HFOSS_Communities HFOSS communities] | * [http://www.foss2serve.org/index.php/HFOSS_Communities HFOSS communities] | ||
* Review HFOSS project [http://openmrs.org/ OpenMRS] | * 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" | ||
Line 101: | Line 100: | ||
| Processes and frameworks | | Processes and frameworks | ||
* What is the general process and what are the roles that perform RE? | * What is the general process and what are the roles that perform RE? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-process-roles Principles: Process and roles] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-process-roles Slides "Principles: Process and roles"] |
* What reference structures can I use for requirements? | * What reference structures can I use for requirements? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-frameworks-standards Frameworks, templates, and standards] | + | [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 | * Identify the requirements engineering process steps used in HFOSS project | ||
* Compare to traditional requirements engineering phases and artifact-oriented requirements engineering. | * 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. | * Research the ISO RE standard 29148 and requirements specification templates. | ||
− | |||
| | | | ||
− | * Standard on Requirements Specifications IEEE 830 | + | * [http://ieeexplore.ieee.org/document/720574/ Standard on Requirements Specifications IEEE 830] |
− | * ISO | + | * [https://www.iso.org/standard/45171.html ISO standard 29148 on Requirements engineering] |
* [https://blog.newrelic.com/2014/05/05/open-source_gettingstarted/ Getting started with 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] | * [https://opensource.com/life/13/4/ten-ways-participate-open-source 10 ways to participate in open source] | ||
Line 122: | Line 121: | ||
| 3 | | 3 | ||
| Artifact-oriented requirements engineering | | Artifact-oriented requirements engineering | ||
− | * [https://www.slideshare.net/kamikitty/requirements-engineering-artifactoriented-requirements-engineering AMDiRE | + | * Artifact model for domain-indenpendent requirements engineering |
− | * [https://www.slideshare.net/kamikitty/requirements-engineering-business-case-analysis Business Case Analysis | + | [https://www.slideshare.net/kamikitty/requirements-engineering-artifactoriented-requirements-engineering Slides "AMDiRE"] |
+ | * Why are we building this system? | ||
+ | [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. | |
| | | | ||
− | * AMDiRE article | + | * [https://link.springer.com/article/10.1007/s00766-014-0206-y AMDiRE article] by Mendez and Penzenstadler, Requirements Engineering, Springer |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 134: | Line 135: | ||
| Stakeholders | | Stakeholders | ||
* Who are the people to talk to about requirements? | * Who are the people to talk to about requirements? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-stakeholders Stakeholders] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-stakeholders Slides "Stakeholders"] |
| | | | ||
− | + | [[(Re-)Engineering stakeholders (Activity)]] | |
* Make list of stakeholders in HFOSS project | * Make list of stakeholders in HFOSS project | ||
* Make stakeholder model (deliverable) | * Make stakeholder model (deliverable) | ||
| | | | ||
− | * | + | * [http://ieeexplore.ieee.org/abstract/document/1259199/ Understanding project sociology by modeling stakeholders] by Alexander and Robertson, IEEE Software |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 146: | Line 147: | ||
| Goals | | Goals | ||
* What are the major objectives for the system? | * What are the major objectives for the system? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-goals Goals and Constraints] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-goals Slides "Goals and Constraints"] |
| | | | ||
− | + | [[(Re-)Engineering goals (Activity)]] | |
* Make list of goals in HFOSS project | * Make list of goals in HFOSS project | ||
* Make goal model (deliverable) | * Make goal model (deliverable) | ||
| | | | ||
− | * | + | * [http://dl.acm.org/citation.cfm?id=2451609 A generic model for sustainability] by Penzenstadler and Femmer, GIBSE 2013 |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 158: | Line 159: | ||
| System Vision | | System Vision | ||
* What exactly do we want to achieve? | * What exactly do we want to achieve? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision System Vision] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision Slides "System Vision"] |
* What information sources do I need? | * What information sources do I need? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-system-vision Information sources for system visions and quality assurance] (2nd half of same slide set) | + | [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 | * Making a rich picture for the future OpenMRS | ||
| | | | ||
− | * Monk & Howard | + | * [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] |
− | * Online tutorial by | + | * [http://systems.open.ac.uk/materials/T552/ Online tutorial for rich pictures] by The Open University |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 172: | Line 173: | ||
| Domain Models | | Domain Models | ||
* What are the surrounding systems ours interacts with? | * What are the surrounding systems ours interacts with? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-domain-models Domain Models] | + | [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. | ||
| | | | ||
− | + | * [http://ieeexplore.ieee.org/abstract/document/130660/ Domain modeling for software engineering] by N. Iscoe, G.B. Williams, and G. Arango | |
− | + | ||
− | + | ||
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 182: | Line 183: | ||
| Midterm | | Midterm | ||
* Recap, questions and answers | * Recap, questions and answers | ||
− | * | + | * [http://foss2serve.org/index.php/File:MidtermSolution.pdf Midterm] |
| | | | ||
Q & A session | Q & A session | ||
+ | * Discussion | ||
| | | | ||
− | * | + | * [http://foss2serve.org/index.php/File:MidtermPracticeSolution.pdf Midterm practice] |
+ | |||
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 192: | Line 195: | ||
| Usage Models | | Usage Models | ||
* How will the system interact with the user? | * How will the system interact with the user? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-usage-models Usage Models] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-usage-models Slides "Usage Models"] |
− | | | + | | Use cases |
− | * | + | * Lab 1: [[(Re-)Engineering use cases (Activity)]] |
− | * Refine/rework use cases after feedback (deliverable) | + | * Lab 2: Refine/rework use cases after feedback (deliverable) |
| | | | ||
− | * Cockburn Use Case Template | + | * [http://alistair.cockburn.us/Basic+use+case+template Cockburn's Use Case Template] |
+ | * [https://link.springer.com/article/10.1007/s00766-004-0194-4 Sindre & Opdahl: Eliciting security requirements with misuse cases, REJ 2005] | ||
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
| 10 | | 10 | ||
| Scaling RE and RE tools | | Scaling RE and RE tools | ||
− | * How to adapt RE for a specific | + | * How to adapt RE for a specific project setting? |
− | [https://www.slideshare.net/kamikitty/requirements-engineering-scaling-re-requirements-refinement Scaling RE, refining requirements, and system models] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-scaling-re-requirements-refinement Slides "Scaling RE, refining requirements, and system models"] |
* How to select RE tools? | * How to select RE tools? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-re-tools RE Tools] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-re-tools Slides "RE Tools"] |
| Tools and assessment | | Tools and assessment | ||
− | * Activity: try out requirements engineering tools | + | * Activity for Lab 1: try out requirements engineering tools |
− | * Write an assessment of one other requirements engineering tool | + | * Lab 2: Write an assessment of one other requirements engineering tool [http://foss2serve.org/index.php/File:2017_542_Lab_RE-Tools.pdf RE Tools Assignment Sheet] |
| | | | ||
− | * IEEE | + | * [http://ieeexplore.ieee.org/abstract/document/5929527/ Requirements Engineering Tools] by Juan M. Carrillo de Gea et al., IEEE Software, 2011 |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 217: | Line 221: | ||
* How to deal with requirements that are not about functionality? | * How to deal with requirements that are not about functionality? | ||
* How to specify which qualities need to be met? | * How to specify which qualities need to be met? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-nonfunctional-requirements Classification of non-functional requirements] | + | [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" | |- style="text-align:left; color:black" | ||
Line 227: | Line 232: | ||
| Quality models | | Quality models | ||
* How to determine the quality characteristics? | * How to determine the quality characteristics? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-quality-models Software quality models] | + | [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. | * Activity: Perform peer review of non-functional requirements elaborated by other team and give feedback on how to improve them. | ||
| | | | ||
− | * Software quality | + | * [http://ieeexplore.ieee.org/abstract/document/476281/ Software quality: the elusive target] by B Kitchenham, SL Pfleeger - IEEE software, 1996 |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
Line 237: | Line 242: | ||
| Quality assurance | | Quality assurance | ||
* How to ensure that RE is done in a good way? | * How to ensure that RE is done in a good way? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-quality-assurance Quality assurance] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-quality-assurance Slides "Quality assurance"] |
| Quality assurance in documentation | | Quality assurance in documentation | ||
− | + | * [http://foss2serve.org/index.php/File:2017_542_Lab_QA.pdf Quality Assurance Assignment sheet] | |
| | | | ||
− | * IEEE 830 | + | * [http://ieeexplore.ieee.org/document/720574/ Standard on Requirements Specifications IEEE 830] |
− | * ISO 25010 Standard for Software Quality Models | + | * [https://www.iso.org/standard/45171.html ISO standard 29148 on Requirements engineering] |
− | * IEEE 730-2014 Standard for Software Quality Assurance Processes | + | * [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" | |- style="text-align:left; color:black" | ||
Line 249: | Line 255: | ||
| Requirements management | | Requirements management | ||
* How to evolve requirements? | * How to evolve requirements? | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Change management] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Slides "Change management"] |
* How to anticipate and plan for risks. | * How to anticipate and plan for risks. | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Risk management] (2nd half of slide set) | + | [https://www.slideshare.net/kamikitty/requirements-engineering-requirements-management Slides "Risk management"] (2nd half of slide set) |
* How to put it all together | * How to put it all together | ||
− | [https://www.slideshare.net/kamikitty/requirements-engineering-wrapup-putting-it-all-together Wrap-up] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-wrapup-putting-it-all-together Slides "Wrap-up"] |
− | | | + | | Requirements management |
− | * Activity: Bug tracker activity | + | * Activity: [http://foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity) Bug tracker activity] |
− | * Requirements Rationales (lab discussion on article) | + | * Requirements Rationales (lab discussion on article, [http://foss2serve.org/index.php/File:2017_542_ReqRationale.pdf Rationales Assignment sheet]) |
| | | | ||
− | * IEEE Software | + | * [http://ieeexplore.ieee.org/abstract/document/7325184/ Guidelines for Managing Requirements Rationales] by AK Thurimella et al. - IEEE Software, 2017 |
|- style="text-align:left; color:black" | |- style="text-align:left; color:black" | ||
| 15 | | 15 | ||
| Research and Recap | | Research and Recap | ||
− | * [https://www.slideshare.net/kamikitty/requirements-engineering-present-and-future-hot-research-topics Hot topics | + | * Research topics |
− | * [https://www.slideshare.net/kamikitty/requirements-engineering-recap Recap] | + | [https://www.slideshare.net/kamikitty/requirements-engineering-present-and-future-hot-research-topics Slides "Hot topics in current and future research"] |
− | | Final exam practice | + | * 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 | |
− | * Cheng | + | |
|} | |} | ||
=== Notes to Instructor === | === Notes to Instructor === | ||
− | * 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]] | + | * 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 | * Lessons learned | ||
Line 282: | Line 291: | ||
* Books: Here are a couple of books on requirements engineering as this topic is not covered in depth within this wiki: | * Books: 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” | + | ** [https://books.google.at/books/about/Software_Requirements.html?id=40lDmAEACAAJ&redir_esc=y Karl Wiegers and Joy Beatty: “Software Requirements”] |
− | ** Axel van Lamsweerde: “Requirements Engineering” | + | ** [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”] |
− | ** Klaus Pohl: “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. | For the HFOSS part of the course, please refer to the internal and external references in the table above. | ||
Line 290: | Line 299: | ||
=== Moving Forward === | === Moving Forward === | ||
− | * This course was held for the first time in Spring 2017. | + | * 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 analysis. | + | * The data collected is still under analysis. |
-------------------- | -------------------- | ||
Line 298: | Line 307: | ||
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: Courses]] | + | [[Category:Courses]] |
+ | [[Category:Requirements Engineering]] | ||
+ | [[Category:Specification and Design]] | ||
+ | [[Category:Documentation]] | ||
+ | [[Category:SE Requirements Engineering]] | ||
+ | [[Category:Ready_to_Use]] |
Latest revision as of 08:48, 27 January 2021
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. |
Course Length | 15 weeks |
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):
- 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 | Lectures | Labs / Activities | Reading / Resources |
---|---|---|---|
1 | Course Introduction
|
Open source intro and EARS
|
|
2 | Processes and frameworks
Slides "Principles: Process and roles"
|
Requirements engineering process (Activity)
Mapping Requirements Specification Standards (Activity)
|
|
3 | Artifact-oriented requirements engineering
|
Exploring artifact models (Activity)
|
|
4 | Stakeholders
|
(Re-)Engineering stakeholders (Activity)
|
|
5 | Goals
|
(Re-)Engineering goals (Activity)
|
|
6 | System Vision
Slides "Information sources for system visions and quality assurance" (2nd half of same slide set) |
(Re-)Engineering a system vision (Activity)
|
|
7 | Domain Models
|
(Re-)Engineering a domain model (Activity)
|
|
8 | Midterm
|
Q & A session
|
|
9 | Usage Models
|
Use cases
|
|
10 | Scaling RE and RE tools
Slides "Scaling RE, refining requirements, and system models"
|
Tools and assessment
|
|
11 | Non-functional requirements
|
Non-functional requirements |
|
12 | Quality models
|
Quality models
|
|
13 | Quality assurance
|
Quality assurance in documentation | |
14 | Requirements management
Slides "Risk management" (2nd half of slide set)
|
Requirements management
|
|
15 | Research and Recap
Slides "Hot topics in current and future research"
|
Final exam |
|
Notes to Instructor
- 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:
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
Materials linked to by this page may be governed by other licenses.