Requirements Engineering, CSU Long Beach, Penzenstadler

From Foss2Serve
Revision as of 14:19, 19 July 2017 by BPenzenstadler (Talk | contribs)
Jump to: navigation, search

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

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

Why do we need Requirements Engineering and what is it?

  • Introduction to natural language requirements: EARS - "Easy Approach to Requirements Syntax" (slides2)
Open source intro and EARS
  • Brief overview of HFOSS and the planned activities
  • Review HFOSS projects for interest:

http://openmrs.org/

  • Practice EARS approach for OpenMRS requirements
2 Processes and frameworks
  • Principles: Process and roles (slides3)
  • Frameworks, templates, and standards (What reference structures can I use for requirements?) (slides4)

Activity Requirements engineering process (to be filled in, lab2)

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

Activity Requirements standards (to be filled in, lab3)

  • Standard on Requirements Specifications IEEE 830 (link)
  • ISO RE standard 29148 (link)
  • Find the equivalents of those elements in HFOSS project, e.g. OpenMRS
3 Artifact-oriented requirements engineering
  • AMDiRE: Artifact model for domain-indenpendent requirements engineering (slides5)
  • Business Case Analysis: Why are we building this system? (slides6)
  • 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 2: Find the requirements documented for OpenMRS and sort the information into a requirements specification template.
  • AMDiRE article (link)
4 Stakeholders
  • Stakeholders: Who are the people to talk to about requirements? (Slides7)

Activity (Re-)Engineering stakeholders, goals & questions part 1 (to be filled in)

    • Make list of stakeholders in HFOSS project
    • Make stakeholder model (deliverable)|
  • Onion model paper (link)
5 Goals
  • Goals and Constraints: What are the major objectives for the system? (Slides8)
  • Sustainability goal model paper (link Penzenstadler2013b)
6 System Vision
  • System Vision: What exactly do we want to achieve? (slides9)
  • Information sources for system visions and quality assurance (2nd half slides9)
  • Monk & Howard paper on Rich Pictures (link)
  • Online tutorial by TheOpenUniversity (link)
7 Domain Models
  • Domain Models: What are the surrounding systems ours interacts with? (slides10)
  • Activity
  • read this
8 Midterm
  • Recap, questions and answers
  • Practice exam (pdf)
  • Actual exam (pdf)
  • read this
9 Usage Models
  • Usage Models: How will the system interact with the user? (slides11)
  • Cockburn Use Case Template
10 Scaling RE
  • Scaling RE, refining requirements, and system models (slides12)
  • RE Tools (slides13)
Tools and assessment
  • Activity: try out requirements engineering tools
  • Write an assessment of one other requirements engineering tool
  • IEEE SW article on tool review
11 Non-functional requirements
  • Classification of non-functional requirements (slides14)
  • Quality requirements: How to specify which qualities need to be met? (slides14)
  • Martin Glinz, "Rethinking the notion of NFRs" (link)
12 Quality models
  • Software quality models: How to determine the quality characteristics? (slides15)
  • Activity: Perform peer review of non-functional requirements elaborated by other team and give feedback on how to improve them.
  • Software quality, the elusive target (Kitchenham)
13 Quality assurance
  • Quality assurance: How to ensure that RE is done in a good way?
Quality assurance in documentation
  • IEEE 830-1998
  • ISO 25010 Standard for Software Quality Models
  • IEEE 730-2014 Standard for Software Quality Assurance Processes
14 Requirements management
  • Change management: How to evolve requirements?
  • Risk management: How to anticipate and plan for risks.
  • Wrap-up: How to put it all together (slides18)
  • Activity: Bug tracker activity (to be linked)
  • Requirements Rationales (lab discussion on article)
  • IEEE Software article on requirements rationales
15
  • Hot topics of requirements engineering in current and future research
  • Recap (slides20)
Final exam practice
  • Practice exam
  • Nuseibeh paper
  • Cheng & Atlee paper


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.
  • 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”
    • 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 was held for the first time in Spring 2017.
  • The data collected is still analysis.

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

CC license.png


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

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