Skip to main content
Jump to: navigation, search

Difference between revisions of "RMF/Teaching"

< RMF
 
(5 intermediate revisions by 4 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 ==
 +
 
 +
The RMF/Teaching project is migrating to gitHub: http://jastram.github.io/teaching/
  
 
== Vision ==
 
== Vision ==
  
−
Create (1) a set of teaching materials that is actively used; (2) which is embedded in a larger SE context; and (3) which explicitly focuses on applying RE.
+
Now found here: http://jastram.github.io/teaching/
  
 
== Scope ==
 
== Scope ==
  
−
The scope is the creation of teaching materials, centered around a case study, based on existing methods and tools.  This is visualized in the following picture:
+
Now found here: http://jastram.github.io/teaching/
−
 
+
−
[[File:teaching-overview.png]]
+
−
 
+
−
ISO 29110 looks promising as the foundation for the method. Eclipse-based tools in general, and ProR for requirements engineering in particular, will be used.  We are currently looking for a suitable case study, ideally using something that already exists.  The focus will be on the creation of shared teaching materials.
+
  
 
== Objectives ==
 
== Objectives ==
  
−
* '''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).
+
Now found here: http://jastram.github.io/teaching/
−
* '''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.
+
−
* '''Teaching Materials:''' Ideally, one outcome of this effort is a set of adaptable teaching materials.
+
−
 
+
−
Initially, we will focus on teaching materials, specifically a case study (see next section).
+
  
 
== Case Study ==
 
== Case Study ==
Line 40: Line 34:
  
 
The columns show the Relevance of the objective, as rated by various stakeholders.
 
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 [http://profs.etsmtl.ca/claporte/english/VSE/Deploy-Pack/]
 +
* 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]
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 47: Line 46:
 
! Andrea
 
! Andrea
 
! Eckhard
 
! Eckhard
−
! Case 3
+
! Ron
 +
! Michael
 
|-
 
|-
 
| '''Requirements process:'''
 
| '''Requirements process:'''
 +
| -------
 
| -------
 
| -------
 
| -------
 
| -------
Line 58: Line 59:
 
|   
 
|   
 
|  ***
 
|  ***
−
| ---
+
| *
 +
|  **
 
|-
 
|-
 
| Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ...
 
| Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ...
Line 64: Line 66:
 
|  *
 
|  *
 
|  *
 
|  *
−
| ---
+
| *
 +
|
 
|-
 
|-
 
| Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8?
 
| Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8?
Line 70: Line 73:
 
|  **
 
|  **
 
|  **
 
|  **
−
| ---
+
| **
 +
|  *
 
|-
 
|-
 
| Versions vs variants, variability, EU 8
 
| Versions vs variants, variability, EU 8
Line 76: Line 80:
 
|  *
 
|  *
 
|  ***
 
|  ***
−
| ---
+
| Adv
 +
|  **
 
|-
 
|-
 
| Req communication and collaboration media (documents, general purpose comm. media, specialised tooling)
 
| Req communication and collaboration media (documents, general purpose comm. media, specialised tooling)
Line 82: Line 87:
 
|   
 
|   
 
|  ***
 
|  ***
−
| ---  
+
|  **
 +
|  **
 
|-
 
|-
 
| RE process interoperability with the V&V (Verification&Validation, aka testing) process, SI.2.3
 
| RE process interoperability with the V&V (Verification&Validation, aka testing) process, SI.2.3
Line 88: Line 94:
 
|  **
 
|  **
 
|  **
 
|  **
−
| ---  
+
|
 +
| **
 
|-
 
|-
 
| Elicitation, SI.2.2, EU 3
 
| Elicitation, SI.2.2, EU 3
Line 94: Line 101:
 
|  *
 
|  *
 
|  **
 
|  **
−
| ---  
+
|  **
 +
|  **
 
|-
 
|-
 
| Analysis, SI.2.2
 
| Analysis, SI.2.2
Line 100: Line 108:
 
|  **
 
|  **
 
|  *
 
|  *
−
| ---  
+
|  Int
 +
|  **
 
|-
 
|-
 
| Modelling, EU 6
 
| Modelling, EU 6
Line 106: Line 115:
 
|  *
 
|  *
 
|  *
 
|  *
−
| ---
+
| Adv
 +
|  **
 
|-
 
|-
 
| Specification (documenting), SI.2.2, EU 4
 
| Specification (documenting), SI.2.2, EU 4
Line 112: Line 122:
 
|  *
 
|  *
 
|  **
 
|  **
−
| ---
+
| **
 +
|  **
 
|-
 
|-
 
| Verification, SI.2.3 ("correctness and testability"), EU 7
 
| Verification, SI.2.3 ("correctness and testability"), EU 7
Line 118: Line 129:
 
|  *
 
|  *
 
|  ***
 
|  ***
−
| ---
+
|
 +
|  **
 
|-
 
|-
 
| Tracing, SI.2.3, SI.2.6, EU 8
 
| Tracing, SI.2.3, SI.2.6, EU 8
Line 124: Line 136:
 
|  **
 
|  **
 
|  ****
 
|  ****
−
| ---
+
| **
 +
|  **
 
|-
 
|-
 
| Communication, SI.2.3, SI.2.4, SI.2.5, SI.2.6
 
| Communication, SI.2.3, SI.2.4, SI.2.5, SI.2.6
Line 130: Line 143:
 
|   
 
|   
 
|  **
 
|  **
−
| ---
+
| **
 +
|  *
 
|-
 
|-
 
| Reviewing, SI.2.3
 
| Reviewing, SI.2.3
Line 136: Line 150:
 
|  *
 
|  *
 
|  **
 
|  **
−
| ---
+
| **
 +
|  **
 
|-
 
|-
 
| Feedback processing, SI.2.2
 
| Feedback processing, SI.2.2
Line 142: Line 157:
 
|   
 
|   
 
|  *
 
|  *
−
| ---
+
|
 +
|  *
 
|-
 
|-
 
| Attributes management, EU 8
 
| Attributes management, EU 8
Line 148: Line 164:
 
|  **
 
|  **
 
|  ***
 
|  ***
−
| ---
+
| *
 +
|  **
 
|-
 
|-
 
| Change management, SI.2.3, EU 8
 
| Change management, SI.2.3, EU 8
Line 154: Line 171:
 
|  **
 
|  **
 
|  ***
 
|  ***
−
| ---
+
| *
 +
|  **
 
|-
 
|-
 
| Reuse management
 
| Reuse management
Line 160: Line 178:
 
|  *
 
|  *
 
|  ****
 
|  ****
−
| ---
+
| Adv
 +
| 
 
|-
 
|-
 
| Document generation with selective req-info content (views), SI.2.2, SI.2.5, SI.2.6, EU 8
 
| Document generation with selective req-info content (views), SI.2.2, SI.2.5, SI.2.6, EU 8
Line 166: Line 185:
 
|  **
 
|  **
 
|  ****
 
|  ****
−
| ---
+
| *
 +
|  **
 
|-
 
|-
 
| Requirements process KPI reporting
 
| Requirements process KPI reporting
Line 172: Line 192:
 
|  **
 
|  **
 
|  **
 
|  **
−
| ---
+
| Int
 +
|  *
 
|-
 
|-
 
| '''Requirements technology:'''
 
| '''Requirements technology:'''
 +
| -------
 
| -------
 
| -------
 
| -------
 
| -------
Line 183: Line 205:
 
|   
 
|   
 
|  *
 
|  *
−
| ---  
+
|  **
 +
|  *
 
|-
 
|-
 
| Core req-info vs req attributes (w.r.t. formulation, rationale, requirements process, reuse policies)
 
| Core req-info vs req attributes (w.r.t. formulation, rationale, requirements process, reuse policies)
Line 189: Line 212:
 
|  *
 
|  *
 
|  ****
 
|  ****
−
| ---
+
| Int
 +
|  *
 
|-
 
|-
 
| Formulation of requirements: in natural language (EU 5), in formal language, in models, SI.2.3
 
| Formulation of requirements: in natural language (EU 5), in formal language, in models, SI.2.3
Line 195: Line 219:
 
|   
 
|   
 
|  ***
 
|  ***
−
| ---
+
| Adv
 +
|  *
 
|-
 
|-
 
| Formality (acceptance criteria) vs informality (providing context) in specifying requirements, SI.2.4
 
| Formality (acceptance criteria) vs informality (providing context) in specifying requirements, SI.2.4
Line 201: Line 226:
 
|   
 
|   
 
|  **
 
|  **
−
| ---
+
| Int
 +
| 
 
|-
 
|-
 
| Requirements frameworks (BABOK, Volere, IEEE…)
 
| Requirements frameworks (BABOK, Volere, IEEE…)
Line 207: Line 233:
 
|  *
 
|  *
 
|  -
 
|  -
−
| ---
+
| 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
 
| 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
Line 213: Line 240:
 
|  **
 
|  **
 
|  ***
 
|  ***
−
| ---
+
| 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
 
| 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
Line 219: Line 247:
 
|  **
 
|  **
 
|  ***
 
|  ***
−
| ---
+
| Int
 +
|  **
 
|-
 
|-
 
| Baselining, EU 8
 
| Baselining, EU 8
Line 225: Line 254:
 
|  **
 
|  **
 
|  *
 
|  *
−
| ---
+
| **
 +
|  *
 
|-
 
|-
 
| '''Case practicality:'''
 
| '''Case practicality:'''
 +
| -------
 
| -------
 
| -------
 
| -------
 
| -------
Line 237: Line 268:
 
|   
 
|   
 
|  *
 
|  *
−
| ---
+
| **
 +
|  **
 
|-
 
|-
 
| Size: # req-info-items, # acceptance criteria, # test cases
 
| Size: # req-info-items, # acceptance criteria, # test cases
 
|  **
 
|  **
 
|   
 
|   
−
| ---
+
|
−
| ---
+
|
 +
| 
 
|-
 
|-
 
| # Functional requirements
 
| # Functional requirements
Line 249: Line 282:
 
|  *
 
|  *
 
|  -
 
|  -
−
| ---
+
| *
 +
|  **
 
|-
 
|-
 
| # Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, …  requirements
 
| # Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, …  requirements
Line 255: Line 289:
 
|  *
 
|  *
 
|  *
 
|  *
−
| ---
+
| *
 +
|  *
 
|}
 
|}
  
−
=== Case Study Examples ===
+
The table in its current form including a visual evaluation is available as PDF [[File:teaching-evaluation.pdf]].
  
−
* [http://www.tdse.org/tvp.html TDSE Coffee Machine Case Study (in German)]
 
−
* [http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/ NCSU CoffeeMaker Case Study (software only)]
 
−
* [http://www4.cookman.edu/faculty/banisakher/UCM-CoffeeMaker.doc Cookman University Coffee Maker Requirements (see Section 3.0 in document)]
 
−
* [https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf FAA Isolette]
 
−
* [http://nlrp.ipd.kit.edu/index.php/Main_Page All of NLRP Benchmark Homepage]
 
  
−
== Meetings ==
+
--- 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.
  
−
=== 2014-Jul-25 ===  
+
=== Case Study Examples ===
  
−
* Present were Andrea Herrmann, Dusko Jovanovic, Eckhard Jokisch and Michael Jastram.
+
Now found here: http://jastram.github.io/roadmap/
−
* We refined the Vision
+
−
* We discussed choosing the case study:
+
−
* The case study shall combine software and hardware
+
−
* The choice was narrowed down to Coffee Maker, Isolette or Rover
+
−
 
+
−
Next Steps:
+
−
 
+
−
* Dusko will update the table
+
−
* Each participant will evaluate the various case studies
+
−
* We'll eventually decide on a case study using a Doodle Poll
+
−
* The decision shall be made within 1-2 weeks.
+
  
 +
== Meetings ==
  
 +
Now found here: http://jastram.github.io/teaching/posts/
  
 
== Open Questions ==
 
== Open Questions ==
  
−
=== What is the Scope? ===
+
Now found in the gitHub issue tracker: https://github.com/jastram/teaching/labels/question
−
 
+
−
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-discipline.  Therefore, at a minimum we should look into RE in the context of overall SE.
+
−
 
+
−
Next, the scope is clearly operational, not theoretical.  The theory (methodology, process), should be given and can maybe be covered elsewhere.
+
−
 
+
−
=== What is the means? ===
+
−
 
+
−
What can we produce that provides value for this group?  Suggestions include:
+
−
 
+
−
* Templates (process-specific, for specific tools)
+
−
* Case Studies (with artifacts for specific tols)
+
−
* Tutorials (process-specific step-by-step instructions, for specific tools)
+
−
* Slides (for teaching)
+
−
* Reference Materials (e.g. tool-specific adaptation of a process)
+
−
* Project (high level description of a goal with instructions on how to realize it)
+
−
 
+
−
=== What process/methodology would be suitable? ===
+
−
 
+
−
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.
+
−
 
+
−
Suggestion regarding the process: To use the [http://en.wikipedia.org/wiki/ISO_29110 ISO/IEC 29110 Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)]. The standard is accompanied by a set of Deployment Packages (DP) that, taken together, structure a complete software or system lifecycle process package. The DPs provide an "out-of-the-box" process for those VSEs that cannot afford the time, the effort or the resources to attack the "Big League" standards like ISO/IEC/IEEE 12207 or 15288 and the CMMi. Once all DPs have been covered, a basis for a complete VSE software or systems engineering certification program is assembled. To start, the Systems Engineering Requirement Engineering (RE) DP can be made available in Draft version and should be released sometimes in 2014 (as of July 2014). The DP provides a set of basic attributes to capture and manage requirements and to establish traceability links.
+
−
 
+
−
Suggestion regarding the Sample Project: Every training course needs a sample project to work out. For this Systems Engineering training curriculum, it is suggested to use the [http://www.incose.org/symp2014/?page=TVC-challenge INCOSE Tool Vendor Disaster Relief Challenge].
+
−
 
+
−
=== What pre-requisites do we expect from anyone taking this training? ===
+
−
 
+
−
Before setting out to design and develop a training, we need to know what type of background students will bring in to the training session. The following are proposed:
+
−
* the students are new to the world of Requirements Engineering, the equivalent of CMMi Level 0 or 1. They are trying to get themselves up to the equivalent of CMMi Level 2 capability, which would equate to fulfilling the CMMi Requirements Management (REQM) Process Area;
+
−
* the students have read the ISO 29110 Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs);
+
−
* the students have read some introductory material on Requirements Engineering such as [http://www.ireb.org/en/service/literatur.html Requirements Engineering Fundamentals]
+
−
* the students are familiar with the Eclipse environment and they have installed:
+
−
1) the Eclipse development toolset;
+
−
2) the Eclipse Requirements Management framework (RMF);
+
−
3) the FormalMind Studio application (which would include both the RMF and ProR).
+
−
* the students have little or no formal training or experience in Requirements Engineering.
+
−
 
+
−
=== Questions/Issues: ===
+
−
 
+
−
* Do students need to understand basics concepts of Change Management, sufficient to go through the creation, analysis, review and implementation of a Requirement Change Request?
+
  
−
=== How long should the training last? ===
 
−
* at one extreme, some trainees look for a Quick Start package that will get them going within a few days. This end of the spectrum should satisfy the greatest number of potential trainees, who will probably be small business starting on a contract that requires doing basic Requirements Engineering;
 
−
* at the other, some are looking for a comprehensive thorough training package that will prepare them for certification as an RE.
 
  
 
== Interested Parties ==
 
== Interested Parties ==
  
−
* Formal Mind GmbH ([http://www.formalmind.com/contact Michael Jastram])
+
Now found here: http://jastram.github.io/teaching/team/
−
* Herrmann & Ehrlich ([http://www.herrmann-ehrlich.de Andrea Herrmann])
+
−
* REArch Int. ([http://www.rearchint.com/ Dusko Jovanovic])
+
−
* Daniel Gross
+
−
* Paul Jorgensen ([http://gvsu.edu University in Michigan])
+
−
* Ronald (Ron) Houde ([http://ca.linkedin.com/pub/ronald-houde/7/597/989/ LinkedIn Profile Page])
+
  
 
== Backlog ==
 
== Backlog ==

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.

Retrieved from "http://wiki.eclipse.org/index.php?title=RMF/Teaching&oldid=369785"

This page was last modified 09:41, 1 September 2014 by Michael Jastram. Based on work by Yijun Yu, Dusko Jovanovic and Ronald Houde and others.

Back to the top