Home » Modeling » Papyrus » Requirements management in PAPYRUS(Use of Diagrams versus Tables in Papyrus)
|
Re: Requirements management in PAPYRUS [message #1403105 is a reply to message #1402937] |
Mon, 21 July 2014 11:48 |
Tomas Sandkvist Messages: 149 Registered: October 2013 |
Senior Member |
|
|
Hi Philip!
I've been messing around with both diagrams and tables;
- If you apply your own stereotyped requirements (I have, using the SYSMOD profile), you must always remember to enter your requirement data (id, text etc) under the profile tab, NEVER to use the dialog fields, because if you do, the table cells will show an error message.
- You can't use requirement trees if you want to use the table, all requirements must be flat in the same package as the table
- Diagrams tends to get really messy very quickly. I can understand why the wizards of SysML recommends handling requirements in some dedicated system
- If you apply your own stereotyped requirements, watch out for the display of id and text in diagrams. I had problems in 0.10.2 with this, where if I did not (in contradiction to my first point) use the id and text fields of the parent stereotype (i.e. the property text boxes), there was issues with seeing these on the diagram. I think it works in 1.0 though, but not 100% certain
- The table populates with requirements automatically. You can't add elements that satisfies the requirement by other means that by creating a diagram, pull in the element and add the satisfies relation (at least not by my knowledge). I bit weird yes.
- There is no refinedBy relationship per see. I was able to come by this by adding the use case property as a table column inherited from the class element, and rename the header.
- The export to Excel is a charm! That way I can pull my requirements out and make the look good!
In summary, there's a lot of potential, you have to be a bit inventive, but it should be possible to get some basic (e.g. don't try to handle too many requirements at once) requirement management up and running.
Thats my five cents of experience so far...
Regards,
Tomas Sandkvist
|
|
| |
Re: Requirements management in PAPYRUS [message #1403218 is a reply to message #1403203] |
Tue, 22 July 2014 12:02 |
Tomas Sandkvist Messages: 149 Registered: October 2013 |
Senior Member |
|
|
Hi Camille!
Aha, I think I get it now, here's what I did:
- In the requirement table, add the refinedBy column
- In a Requirements diagram, add Satisfy relationship.
- Replace the Satisfy stereotype with the Refine from the UML profile
And voila! Now I can see the relationship!
Thanks a lot, could not have guessed that without help!
Tomas
[Updated on: Tue, 22 July 2014 12:03] Report message to a moderator
|
|
|
Re: Requirements management in PAPYRUS [message #1403280 is a reply to message #1403105] |
Mon, 21 July 2014 13:11 |
|
Hi, Tomas,
See some follow-up in-line, below.
Thanks,
Christian
On 2014-07-21 11:48:54 +0000, Tomas Sandkvist said:
> Hi Philip!
>
> I've been messing around with both diagrams and tables;
>
> - If you apply your own stereotyped requirements (I have, using the
> SYSMOD profile), you must always remember to enter your requirement
> data (id, text etc) under the profile tab, NEVER to use the dialog
> fields, because if you do, the table cells will show an error message.
This sounds like a bug. Have you raised a bugzilla?
> - You can't use requirement trees if you want to use the table, all
> requirements must be flat in the same package as the table
>
> - Diagrams tends to get really messy very quickly. I can understand why
> the wizards of SysML recommends handling requirements in some dedicated
> system
>
> - If you apply your own stereotyped requirements, watch out for the
> display of id and text in diagrams. I had problems in 0.10.2 with this,
> where if I did not (in contradiction to my first point) use the id and
> text fields of the parent stereotype (i.e. the property text boxes),
> there was issues with seeing these on the diagram. I think it works in
> 1.0 though, but not 100% certain
>
> - The table populates with requirements automatically. You can't add
> elements that satisfies the requirement by other means that by creating
> a diagram, pull in the element and add the satisfies relation (at least
> not by my knowledge). I bit weird yes.
This sounds like something that needs a bugzilla ... Shouldn't the
table editors support adding new requirements like this? They are
called "editors", after all ;-)
> - There is no refinedBy relationship per see. I was able to come by
> this by adding the use case property as a table column inherited from
> the class element, and rename the header.
If this is a common need, it may be worthwhile raising an enhancement
request to streamline this workflow in the table. A Gerrit
contribution accompanying it would probably also be welcome. :-)
> - The export to Excel is a charm! That way I can pull my requirements
> out and make the look good!
>
> In summary, there's a lot of potential, you have to be a bit inventive,
> but it should be possible to get some basic (e.g. don't try to handle
> too many requirements at once) requirement management up and running.
>
> Thats my five cents of experience so far...
>
> Regards,
> Tomas Sandkvist
|
|
|
Goto Forum:
Current Time: Thu Mar 28 13:56:05 GMT 2024
Powered by FUDForum. Page generated in 0.02921 seconds
|