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 "Papyrus for Sysml"
(→The Requirements model) |
|||
| Line 15: | Line 15: | ||
This model contains all the requirements dedicated to the current plug-in. | This model contains all the requirements dedicated to the current plug-in. | ||
| − | *Rule: The requirements model cannot contain sub-models or sub-packages. It must contain | + | *Rule: The requirements model cannot contain sub-models or sub-packages. It must contain a hierarchy of requirements. |
==Requirement== | ==Requirement== | ||
| − | Each requirement has an id that conforms to the following grammar: | + | Each requirement has an id that conforms to the following grammar pattern: |
<nowiki><Requirement id>::="Req_"<digit><digit><digit></nowiki> | <nowiki><Requirement id>::="Req_"<digit><digit><digit></nowiki> | ||
For example, ''"Req_001"'' can be the first top requirement inside the plugin. | For example, ''"Req_001"'' can be the first top requirement inside the plugin. | ||
| − | + | Add a dot with 3 new digits if a requirement is contained inside other requirement. | |
A requirement contained inside the first requirement has the following id:''"Req_001.001"'' | A requirement contained inside the first requirement has the following id:''"Req_001.001"'' | ||
Latest revision as of 09:07, 17 March 2016
Structure
Each plugin contains a UML model that allows to design plugins inside SysML.
The name of the root model must be the name of the current plugin.
This UML model contains 4 sub-models:
- a model of Requirements
- a model of Use Cases
- a model of Design
- a model of Test
The Requirements model
This model contains all the requirements dedicated to the current plug-in.
- Rule: The requirements model cannot contain sub-models or sub-packages. It must contain a hierarchy of requirements.
Requirement
Each requirement has an id that conforms to the following grammar pattern:
<Requirement id>::="Req_"<digit><digit><digit>
For example, "Req_001" can be the first top requirement inside the plugin.
Add a dot with 3 new digits if a requirement is contained inside other requirement.
A requirement contained inside the first requirement has the following id:"Req_001.001"