Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RMF/Teaching"

< RMF
(Open Questions)
 
(38 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Requirements Management and Engineering (RE&M) is taught, both in industry and academia.  The availability of open source RE-tools, and the RMF-based (fmStudio)[http://www.formalmind.com/studio] in particular, created some interest for using those tools for teaching.
+
== Outdated ==
  
During the initial discussions, two things became clear:
+
The RMF/Teaching project is migrating to gitHub: http://jastram.github.io/teaching/
  
* RM&E cannot be taught without taking the wider systems engineering (SE) context into account.  In other words, RM&E must be considered a subdiscipline of SE, and must be treated that way.
+
== Vision ==
  
* A tool must follow the process, not the other way around. Therefore, the foundation for this effort must be a solid, leightweight SE develpment process that is appropriate for teaching and relevant in practice.
+
Now found here: http://jastram.github.io/teaching/
 +
 
 +
== Scope ==
 +
 
 +
Now found here: http://jastram.github.io/teaching/
  
 
== Objectives ==
 
== Objectives ==
  
* '''Teaching Materials:''' Ideally, one outcome of this effort is a set of adaptable teaching materials.
+
Now found here: http://jastram.github.io/teaching/
* '''Collaboration of Industry, Service Providers and Academia:''' These three groups can benefit vastly from each other: Industry relies on academia for skilled labor, while service provider deliver expertise to industry in the form of knowledge (consultants) and tools (vendors).
+
* '''Standardization of basic RE (or SE) skills:''' Preparation of students with a basic set of skills that is relevant in industry, so employers know what to expect.
+
  
== Ideas ==
+
== Case Study ==
  
* Examples, Exercises, etc. (Herrmann) (Beispiel-Lastenhefte für die Lehre, Übungen und Musterlösungen.)
+
As the next step, we will focus on building up a case study/example. In the telco on July 25th, 2014, we decided that the case study shall involve software and hardware, and we narrowed it down to the following three:
  
== Join the Discussion ==
+
# '''Coffee Maker:''' A long-time favorite, and there are at least three available (see "Case Study Examples" below)
 +
# '''FAA Isolette:''' This is a complete example from a safety-critical domain.
 +
# '''Rover:''' This one is driven by [https://polarsys.org/wiki/PolarSys_Rover_Demo Gaël Blondelle from the Eclipse Foundation].  On the plus side, it's great for the classroom, as the hardware is cheap.  But in contrast to the others, there is nothing there yet.
  
This discussion was initiated via email - a bad place to keep a conversation going.  For the time being, we will start a new discussion thread on LinkedIn.
 
  
== Open Questions ==
+
The table below serves to compare possible case studies against objectives of an RE (Requirements engineering) education/course/training. Note that at this moment the list of objectives is only a proposal, adding or editing the list is welcome.
  
=== What is the Scope? ===
+
For better understanding of this proposal, a tiny bit of the RE theory adhered to:
  
Systems Engineering or Requirements Engineering? A number of participants pointed out that RE as a stand-alone discipline is losing importance in favor of Systems Engineering, of which RE is a sub-disciplineTherefore, at a minimum we should look into RE in the context of overall SE.
+
RE consists of the activities of [http://en.wikipedia.org/wiki/Requirements_engineering]:
 +
* RD – Requirements development: elicitation, analysis, modelling, specification (documenting), verification
 +
* RM – Requirements management: tracing, communication, reviewing, feedback processing, attributes management, change management, reporting, reuse.
 +
The objectives of a comprehensive RE training is to illuminate all these activities more or less, but there are also other objectives, in the table bellow divided into "Requirements process" and "Requirements technology"; at the bottom, some practicality objectives too (as size of the case study).
  
=== What is the means? ===
+
The columns show the Relevance of the objective, as rated by various stakeholders.
  
What can we produce that provides value for this group?  Suggestions include:
+
The objectives, where applicable, are related to the following two authoritative RE skill overviews:
  
* Templates (process-specific, for specific tools)
+
* SI.m.n are subprocesses of the Software Implementation (SI) process as referred to in "DP-Software Requirements Analysis-V1_2.doc"  on [http://profs.etsmtl.ca/claporte/english/VSE/Deploy-Pack/]
* Case Studies (with artifacts for specific tols)
+
* EU are Education Units as referred to in the IREB-CPRE Foundation Level syllabus [http://www.ireb.org/fileadmin/IREB/Lehrplaene/IREB_cpre_syllabus_FL_en_v21.pdf]
* Tutorials (process-specific step-by-step instructions, for specific tools)
+
* Slides (for teaching)
+
* Reference Materials (e.g. tool-specific adaptation of a process)
+
  
=== What process would be suitable? ===
+
{| class="wikitable"
 +
|-
 +
! Objective that the case illuminates  \  Case
 +
! Dusko
 +
! Andrea
 +
! Eckhard
 +
! Ron
 +
! Michael
 +
|-
 +
| '''Requirements process:'''
 +
| -------
 +
| -------
 +
| -------
 +
| -------
 +
|-
 +
| Place of the RE process in the SE process (CMMI, …), SI.2.1, EU 2
 +
|  **
 +
 +
|  ***
 +
|  *
 +
|  **
 +
|-
 +
| Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ...
 +
|  *
 +
|  *
 +
|  *
 +
|  *
 +
|
 +
|-
 +
| Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8?
 +
|  *
 +
|  **
 +
|  **
 +
|  **
 +
|  *
 +
|-
 +
| Versions vs variants, variability, EU 8
 +
|  **
 +
|  *
 +
|  ***
 +
|  Adv
 +
|  **
 +
|-
 +
| Req communication and collaboration media (documents, general purpose comm. media, specialised tooling)
 +
|  **
 +
 +
|  ***
 +
|  **
 +
|  **
 +
|-
 +
| RE process interoperability with the V&V (Verification&Validation, aka testing) process, SI.2.3
 +
|  **
 +
|  **
 +
|  **
 +
|
 +
|  **
 +
|-
 +
| Elicitation, SI.2.2, EU 3
 +
|  *
 +
|  *
 +
|  **
 +
|  **
 +
|  **
 +
|-
 +
| Analysis, SI.2.2
 +
|  **
 +
|  **
 +
|  *
 +
|  Int
 +
|  **
 +
|-
 +
| Modelling, EU 6
 +
|  **
 +
|  *
 +
|  *
 +
|  Adv
 +
|  **
 +
|-
 +
| Specification (documenting), SI.2.2, EU 4
 +
|  **
 +
|  *
 +
|  **
 +
|  **
 +
|  **
 +
|-
 +
| Verification, SI.2.3 ("correctness and testability"), EU 7
 +
|  **
 +
|  *
 +
|  ***
 +
|
 +
|  **
 +
|-
 +
| Tracing, SI.2.3, SI.2.6, EU 8
 +
|  **
 +
|  **
 +
|  ****
 +
|  **
 +
|  **
 +
|-
 +
| Communication, SI.2.3, SI.2.4, SI.2.5, SI.2.6
 +
|  *
 +
 +
|  **
 +
|  **
 +
|  *
 +
|-
 +
| Reviewing, SI.2.3
 +
|  *
 +
|  *
 +
|  **
 +
|  **
 +
|  **
 +
|-
 +
| Feedback processing, SI.2.2
 +
|  *
 +
 +
|  *
 +
 +
|  *
 +
|-
 +
| Attributes management, EU 8
 +
|  **
 +
|  **
 +
|  ***
 +
|  *
 +
|  **
 +
|-
 +
| Change management, SI.2.3, EU 8
 +
|  **
 +
|  **
 +
|  ***
 +
|  *
 +
|  **
 +
|-
 +
| Reuse management
 +
|  **
 +
|  *
 +
|  ****
 +
|  Adv
 +
 +
|-
 +
| Document generation with selective req-info content (views), SI.2.2, SI.2.5, SI.2.6, EU 8
 +
|  *
 +
|  **
 +
|  ****
 +
|  *
 +
|  **
 +
|-
 +
| Requirements process KPI reporting
 +
 +
|  **
 +
|  **
 +
| Int
 +
|  *
 +
|-
 +
| '''Requirements technology:'''
 +
| -------
 +
| -------
 +
| -------
 +
| -------
 +
|-
 +
| Requirements SMARTness, SI.2.3
 +
|  **
 +
 +
|  *
 +
|  **
 +
|  *
 +
|-
 +
| Core req-info vs req attributes (w.r.t. formulation, rationale, requirements process, reuse policies)
 +
|  **
 +
|  *
 +
|  ****
 +
|  Int
 +
|  *
 +
|-
 +
| Formulation of requirements: in natural language (EU 5), in formal language, in models, SI.2.3
 +
|  **
 +
 +
|  ***
 +
|  Adv
 +
|  *
 +
|-
 +
| Formality (acceptance criteria) vs informality (providing context) in specifying requirements, SI.2.4
 +
|  *
 +
 +
|  **
 +
|  Int
 +
 +
|-
 +
| Requirements frameworks (BABOK, Volere, IEEE…)
 +
|  *
 +
|  *
 +
|  -
 +
|  Int
 +
 +
|-
 +
| V-horizontal traceability: traces among req-info-items at one level of stakeholders’ abstraction: requirements – requirements groups – dependences – reuse traces – change requests – test cases – test reports, SI.2.3, EU 8
 +
|  **
 +
|  **
 +
|  ***
 +
|  Int
 +
|  **
 +
|-
 +
| V-vertical traceability: traces among req-info-items across various levels of stakeholders’ abstraction: business level – product level – component level, SI.2.3, SI.2.4, EU 8
 +
|  **
 +
|  **
 +
|  ***
 +
|  Int
 +
|  **
 +
|-
 +
| Baselining, EU 8
 +
|  **
 +
|  **
 +
|  *
 +
|  **
 +
|  *
 +
|-
 +
| '''Case practicality:'''
 +
| -------
 +
| -------
 +
| -------
 +
| -------
 +
|-
  
Before answering this question, we need to understand the scope. We should look for a slim-lightweight process for MBSE and focus on the RE-part of it.
+
| Domain/application familiarity
 +
|  **
 +
 +
|  *
 +
|  **
 +
|  **
 +
|-
 +
| Size: # req-info-items, # acceptance criteria, # test cases
 +
| **
 +
 +
|
 +
 +
 +
|-
 +
| # Functional requirements
 +
|  **
 +
|  *
 +
-
 +
|  *
 +
|  **
 +
|-
 +
| # Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, …  requirements
 +
|  **
 +
|  *
 +
|  *
 +
|  *
 +
|  *
 +
|}
  
== Interested Parties ==
+
The table in its current form including a visual evaluation is available as PDF [[File:teaching-evaluation.pdf]].
  
* Formal Mind GmbH ([http://www.formalmind.com/contact Michael Jastram])
 
* Herrmann & Ehrlich ([http://www.herrmann-ehrlich.de Andrea Herrmann])
 
* REArch Int. ([http://www.rearchint.com/ Dusko Jovanovic])
 
  
== Backlog ==
+
--- Notes: ---
 +
* Topics should be aligned with the ISO 29110 Profiles (Entry, Basic, Intermediate, Advanced). The initial Training cursus should be targeted at the Basic Profile.
  
 +
=== Case Study Examples ===
  
 +
Now found here: http://jastram.github.io/roadmap/
 +
 +
== Meetings ==
 +
 +
Now found here: http://jastram.github.io/teaching/posts/
 +
 +
== Open Questions ==
 +
 +
Now found in the gitHub issue tracker: https://github.com/jastram/teaching/labels/question
 +
 +
 +
== Interested Parties ==
 +
 +
Now found here: http://jastram.github.io/teaching/team/
 +
 +
== Backlog ==
  
 
== Contact / Initiator ==
 
== Contact / Initiator ==
  
 
[http://www.formalmind.com/contact Michael Jastram]
 
[http://www.formalmind.com/contact Michael Jastram]
 +
 +
= Backup =
 +
 +
During the initial discussions, two things became clear:
 +
 +
* RM&E cannot be taught without taking the wider systems engineering (SE) context into account.  In other words, RM&E must be considered a subdiscipline of SE, and must be treated that way.
 +
 +
* A tool must follow the process/methodology, not the other way around.  Therefore, the foundation for this effort must be a solid, leightweight SE develpment process that is appropriate for teaching and relevant in practice.
 +
 +
== Ideas ==
 +
 +
* Examples, Exercises, etc. (Herrmann) (example customer requirements specification, exercises and sample solutions)
 +
* Create a mind map, to understand the problem we're trying to solve (Daniel Gross)
 +
* use [http://wymagania.net/materialy/REQB-Syllabus-Foundation-Leve-v.1.2.pdf REQB-Syllabus] as a starting point
 +
* alternately, use the International Requirements Engineering Board (IREB) [http://www.ireb.org/en/syllabi/foundation-level.html Foundation Level RE Training Syllabus]
 +
 +
 +
== Join the Discussion ==
 +
 +
This discussion was initiated via email - a bad place to keep a conversation going.  For the time being, we will start a new discussion thread on LinkedIn.

Latest revision as of 09:41, 1 September 2014

Outdated

The RMF/Teaching project is migrating to gitHub: http://jastram.github.io/teaching/

Vision

Now found here: http://jastram.github.io/teaching/

Scope

Now found here: http://jastram.github.io/teaching/

Objectives

Now found here: http://jastram.github.io/teaching/

Case Study

As the next step, we will focus on building up a case study/example. In the telco on July 25th, 2014, we decided that the case study shall involve software and hardware, and we narrowed it down to the following three:

  1. Coffee Maker: A long-time favorite, and there are at least three available (see "Case Study Examples" below)
  2. FAA Isolette: This is a complete example from a safety-critical domain.
  3. Rover: This one is driven by Gaël Blondelle from the Eclipse Foundation. On the plus side, it's great for the classroom, as the hardware is cheap. But in contrast to the others, there is nothing there yet.


The table below serves to compare possible case studies against objectives of an RE (Requirements engineering) education/course/training. Note that at this moment the list of objectives is only a proposal, adding or editing the list is welcome.

For better understanding of this proposal, a tiny bit of the RE theory adhered to:

RE consists of the activities of [1]:

  • RD – Requirements development: elicitation, analysis, modelling, specification (documenting), verification
  • RM – Requirements management: tracing, communication, reviewing, feedback processing, attributes management, change management, reporting, reuse.

The objectives of a comprehensive RE training is to illuminate all these activities more or less, but there are also other objectives, in the table bellow divided into "Requirements process" and "Requirements technology"; at the bottom, some practicality objectives too (as size of the case study).

The columns show the Relevance of the objective, as rated by various stakeholders.

The objectives, where applicable, are related to the following two authoritative RE skill overviews:

  • SI.m.n are subprocesses of the Software Implementation (SI) process as referred to in "DP-Software Requirements Analysis-V1_2.doc" on [2]
  • EU are Education Units as referred to in the IREB-CPRE Foundation Level syllabus [3]
Objective that the case illuminates \ Case Dusko Andrea Eckhard Ron Michael
Requirements process: ------- ------- ------- -------
Place of the RE process in the SE process (CMMI, …), SI.2.1, EU 2 ** *** * **
Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ... * * * *
Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8? * ** ** ** *
Versions vs variants, variability, EU 8 ** * *** Adv **
Req communication and collaboration media (documents, general purpose comm. media, specialised tooling) ** *** ** **
RE process interoperability with the V&V (Verification&Validation, aka testing) process, SI.2.3 ** ** ** **
Elicitation, SI.2.2, EU 3 * * ** ** **
Analysis, SI.2.2 ** ** * Int **
Modelling, EU 6 ** * * Adv **
Specification (documenting), SI.2.2, EU 4 ** * ** ** **
Verification, SI.2.3 ("correctness and testability"), EU 7 ** * *** **
Tracing, SI.2.3, SI.2.6, EU 8 ** ** **** ** **
Communication, SI.2.3, SI.2.4, SI.2.5, SI.2.6 * ** ** *
Reviewing, SI.2.3 * * ** ** **
Feedback processing, SI.2.2 * * *
Attributes management, EU 8 ** ** *** * **
Change management, SI.2.3, EU 8 ** ** *** * **
Reuse management ** * **** Adv
Document generation with selective req-info content (views), SI.2.2, SI.2.5, SI.2.6, EU 8 * ** **** * **
Requirements process KPI reporting ** ** Int *
Requirements technology: ------- ------- ------- -------
Requirements SMARTness, SI.2.3 ** * ** *
Core req-info vs req attributes (w.r.t. formulation, rationale, requirements process, reuse policies) ** * **** Int *
Formulation of requirements: in natural language (EU 5), in formal language, in models, SI.2.3 ** *** Adv *
Formality (acceptance criteria) vs informality (providing context) in specifying requirements, SI.2.4 * ** Int
Requirements frameworks (BABOK, Volere, IEEE…) * * - Int
V-horizontal traceability: traces among req-info-items at one level of stakeholders’ abstraction: requirements – requirements groups – dependences – reuse traces – change requests – test cases – test reports, SI.2.3, EU 8 ** ** *** Int **
V-vertical traceability: traces among req-info-items across various levels of stakeholders’ abstraction: business level – product level – component level, SI.2.3, SI.2.4, EU 8 ** ** *** Int **
Baselining, EU 8 ** ** * ** *
Case practicality: ------- ------- ------- -------
Domain/application familiarity ** * ** **
Size: # req-info-items, # acceptance criteria, # test cases **
# Functional requirements ** * - * **
# Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, … requirements ** * * * *

The table in its current form including a visual evaluation is available as PDF File:Teaching-evaluation.pdf.


--- Notes: ---

  • Topics should be aligned with the ISO 29110 Profiles (Entry, Basic, Intermediate, Advanced). The initial Training cursus should be targeted at the Basic Profile.

Case Study Examples

Now found here: http://jastram.github.io/roadmap/

Meetings

Now found here: http://jastram.github.io/teaching/posts/

Open Questions

Now found in the gitHub issue tracker: https://github.com/jastram/teaching/labels/question


Interested Parties

Now found here: http://jastram.github.io/teaching/team/

Backlog

Contact / Initiator

Michael Jastram

Backup

During the initial discussions, two things became clear:

  • RM&E cannot be taught without taking the wider systems engineering (SE) context into account. In other words, RM&E must be considered a subdiscipline of SE, and must be treated that way.
  • A tool must follow the process/methodology, not the other way around. Therefore, the foundation for this effort must be a solid, leightweight SE develpment process that is appropriate for teaching and relevant in practice.

Ideas

  • Examples, Exercises, etc. (Herrmann) (example customer requirements specification, exercises and sample solutions)
  • Create a mind map, to understand the problem we're trying to solve (Daniel Gross)
  • use REQB-Syllabus as a starting point
  • alternately, use the International Requirements Engineering Board (IREB) Foundation Level RE Training Syllabus


Join the Discussion

This discussion was initiated via email - a bad place to keep a conversation going. For the time being, we will start a new discussion thread on LinkedIn.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.