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.
Difference between revisions of "RMF/Teaching"
(→Case Study) |
|||
(4 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | == Outdated == | |
+ | |||
+ | The RMF/Teaching project is migrating to gitHub: http://jastram.github.io/teaching/ | ||
== Vision == | == Vision == | ||
− | + | Now found here: http://jastram.github.io/teaching/ | |
== Scope == | == Scope == | ||
− | + | Now found here: http://jastram.github.io/teaching/ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Objectives == | == Objectives == | ||
− | + | Now found here: http://jastram.github.io/teaching/ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== 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 48: | Line 47: | ||
! Eckhard | ! Eckhard | ||
! Ron | ! Ron | ||
+ | ! Michael | ||
|- | |- | ||
| '''Requirements process:''' | | '''Requirements process:''' | ||
Line 60: | Line 60: | ||
| *** | | *** | ||
| * | | * | ||
+ | | ** | ||
|- | |- | ||
| Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ... | | Requirements in a Product Creation Process: up front (waterfall), ongoing (agile), ... | ||
Line 66: | Line 67: | ||
| * | | * | ||
| * | | * | ||
+ | | | ||
|- | |- | ||
| Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8? | | Requirements process states (rigour): Draft -> Proposal -> … -> Approval , EU 8? | ||
Line 72: | Line 74: | ||
| ** | | ** | ||
| ** | | ** | ||
+ | | * | ||
|- | |- | ||
| Versions vs variants, variability, EU 8 | | Versions vs variants, variability, EU 8 | ||
Line 78: | Line 81: | ||
| *** | | *** | ||
| Adv | | 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 83: | Line 87: | ||
| | | | ||
| *** | | *** | ||
+ | | ** | ||
| ** | | ** | ||
|- | |- | ||
Line 90: | Line 95: | ||
| ** | | ** | ||
| | | | ||
+ | | ** | ||
|- | |- | ||
| Elicitation, SI.2.2, EU 3 | | Elicitation, SI.2.2, EU 3 | ||
Line 95: | Line 101: | ||
| * | | * | ||
| ** | | ** | ||
+ | | ** | ||
| ** | | ** | ||
|- | |- | ||
Line 102: | Line 109: | ||
| * | | * | ||
| Int | | Int | ||
+ | | ** | ||
|- | |- | ||
| Modelling, EU 6 | | Modelling, EU 6 | ||
Line 108: | Line 116: | ||
| * | | * | ||
| Adv | | Adv | ||
+ | | ** | ||
|- | |- | ||
| Specification (documenting), SI.2.2, EU 4 | | Specification (documenting), SI.2.2, EU 4 | ||
Line 114: | Line 123: | ||
| ** | | ** | ||
| ** | | ** | ||
+ | | ** | ||
|- | |- | ||
| Verification, SI.2.3 ("correctness and testability"), EU 7 | | Verification, SI.2.3 ("correctness and testability"), EU 7 | ||
Line 120: | Line 130: | ||
| *** | | *** | ||
| | | | ||
+ | | ** | ||
|- | |- | ||
| Tracing, SI.2.3, SI.2.6, EU 8 | | Tracing, SI.2.3, SI.2.6, EU 8 | ||
Line 126: | Line 137: | ||
| **** | | **** | ||
| ** | | ** | ||
+ | | ** | ||
|- | |- | ||
| 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 132: | Line 144: | ||
| ** | | ** | ||
| ** | | ** | ||
+ | | * | ||
|- | |- | ||
| Reviewing, SI.2.3 | | Reviewing, SI.2.3 | ||
Line 138: | Line 151: | ||
| ** | | ** | ||
| ** | | ** | ||
+ | | ** | ||
|- | |- | ||
| Feedback processing, SI.2.2 | | Feedback processing, SI.2.2 | ||
Line 144: | Line 158: | ||
| * | | * | ||
| | | | ||
+ | | * | ||
|- | |- | ||
| Attributes management, EU 8 | | Attributes management, EU 8 | ||
Line 150: | Line 165: | ||
| *** | | *** | ||
| * | | * | ||
+ | | ** | ||
|- | |- | ||
| Change management, SI.2.3, EU 8 | | Change management, SI.2.3, EU 8 | ||
Line 156: | Line 172: | ||
| *** | | *** | ||
| * | | * | ||
+ | | ** | ||
|- | |- | ||
| Reuse management | | Reuse management | ||
Line 162: | Line 179: | ||
| **** | | **** | ||
| Adv | | 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 168: | Line 186: | ||
| **** | | **** | ||
| * | | * | ||
+ | | ** | ||
|- | |- | ||
| Requirements process KPI reporting | | Requirements process KPI reporting | ||
Line 174: | Line 193: | ||
| ** | | ** | ||
| Int | | Int | ||
+ | | * | ||
|- | |- | ||
| '''Requirements technology:''' | | '''Requirements technology:''' | ||
Line 186: | Line 206: | ||
| * | | * | ||
| ** | | ** | ||
+ | | * | ||
|- | |- | ||
| 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 192: | Line 213: | ||
| **** | | **** | ||
| Int | | 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 198: | Line 220: | ||
| *** | | *** | ||
| Adv | | 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 204: | Line 227: | ||
| ** | | ** | ||
| Int | | Int | ||
+ | | | ||
|- | |- | ||
| Requirements frameworks (BABOK, Volere, IEEE…) | | Requirements frameworks (BABOK, Volere, IEEE…) | ||
Line 210: | Line 234: | ||
| - | | - | ||
| Int | | 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 216: | Line 241: | ||
| *** | | *** | ||
| Int | | 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 222: | Line 248: | ||
| *** | | *** | ||
| Int | | Int | ||
+ | | ** | ||
|- | |- | ||
| Baselining, EU 8 | | Baselining, EU 8 | ||
Line 228: | Line 255: | ||
| * | | * | ||
| ** | | ** | ||
+ | | * | ||
|- | |- | ||
| '''Case practicality:''' | | '''Case practicality:''' | ||
Line 241: | Line 269: | ||
| * | | * | ||
| ** | | ** | ||
+ | | ** | ||
|- | |- | ||
| Size: # req-info-items, # acceptance criteria, # test cases | | Size: # req-info-items, # acceptance criteria, # test cases | ||
Line 247: | Line 276: | ||
| | | | ||
| | | | ||
+ | | | ||
|- | |- | ||
| # Functional requirements | | # Functional requirements | ||
Line 253: | Line 283: | ||
| - | | - | ||
| * | | * | ||
+ | | ** | ||
|- | |- | ||
| # Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, … requirements | | # Extrafunctional (restrictions, technology, markets, maintenance …), quality, regulation, … requirements | ||
Line 259: | Line 290: | ||
| * | | * | ||
| * | | * | ||
+ | | * | ||
|} | |} | ||
+ | |||
+ | The table in its current form including a visual evaluation is available as PDF [[File:teaching-evaluation.pdf]]. | ||
+ | |||
--- Notes: --- | --- Notes: --- | ||
Line 266: | Line 301: | ||
=== Case Study Examples === | === Case Study Examples === | ||
− | + | Now found here: http://jastram.github.io/roadmap/ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Meetings == | == Meetings == | ||
− | + | Now found here: http://jastram.github.io/teaching/posts/ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Open Questions == | == Open Questions == | ||
− | + | Now found in the gitHub issue tracker: https://github.com/jastram/teaching/labels/question | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | |||
− | |||
− | |||
== Interested Parties == | == Interested Parties == | ||
− | + | Now found here: http://jastram.github.io/teaching/team/ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Backlog == | == Backlog == |
Latest revision as of 09:41, 1 September 2014
Contents
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:
- 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 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
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.