Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Requirements management in PAPYRUS(Use of Diagrams versus Tables in Papyrus)
icon3.gif  Requirements management in PAPYRUS [message #1402937] Fri, 18 July 2014 14:15 Go to next message
Philip LOUCOPOULOS is currently offline Philip LOUCOPOULOSFriend
Messages: 30
Registered: May 2014
Member
Hello,

My main concern is to be able to manage properly requirements in PAPYRUS. I am building a system model (functional architecture of my system) using BDDs, IBDs, Packages, and also starting using activities.

Based on my model, I would like to define requirements by sub-systems. In this case, I wonder how to do that properly and to be able to exploit fully the model and the concerned requirements. Do you see my target ? Rolling Eyes

With PAPYRUS:
I see the possibility to use the requirements diagrams and to link them to the model.
I see also the requirements table (and 2 other tables: allocation and default).

My questions:
1-What does PAPYRUS and the expert users suggest to manage requirements linked to a model ?
2-Is the requirements table working properly ? If yes how does it work ? If no, does anybody have a suggestion for a work around with tables ?
3-More generally, how to manage requirements linked to a diagram and to a model ?
4-How to chack that (by an easy mean) that my requirements are linked/covered (or not) by a SysML object ?

Thank in advance for any help and/or suggestion !

Philip
Re: Requirements management in PAPYRUS [message #1403105 is a reply to message #1402937] Mon, 21 July 2014 11:48 Go to previous messageGo to next message
Tomas Sandkvist is currently offline Tomas SandkvistFriend
Messages: 147
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 #1403203 is a reply to message #1403105] Tue, 22 July 2014 10:38 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 692
Registered: February 2011
Senior Member
Hi,

Regarding this point:

Quote:
- There is no refinedBy relationship per see.


You need to apply the UML Standard Profile, in addition to SysML. "Refine" is a standard stereotype; not a SysML-specific one


Camille


Camille Letavernier
Papyrus developer
Re: Requirements management in PAPYRUS [message #1403218 is a reply to message #1403203] Tue, 22 July 2014 12:02 Go to previous message
Tomas Sandkvist is currently offline Tomas SandkvistFriend
Messages: 147
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 Go to previous message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1006
Registered: July 2009
Senior Member
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
Previous Topic:Exception after applying CSS to model
Next Topic:Change color of UML element
Goto Forum:
  


Current Time: Thu Sep 03 23:47:15 GMT 2015

Powered by FUDForum. Page generated in 0.01731 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software