AW: Requirements Format

[Jan.Sommer at dlr.de]

In one project we use Doorstop (https://doorstop.readthedocs.io/en/latest/reference/items/) due to a lack of an actual DOORS license for every partner.
For software developers it is quite easy to handle as it has a CLI and can be easily integrated with git as everything is a text file.
However, it only gives you the basics. With some scripting we used it to generate our Latex-requirements documents with traceability matrices.

Best regards,

   Jan


> -----Ursprüngliche Nachricht-----
> Von: devel [mailto:devel-bounces at rtems.org] Im Auftrag von Sebastian
> Huber
> Gesendet: Mittwoch, 27. Februar 2019 08:43
> An: joel at rtems.org
> Cc: rtems-devel at rtems.org
> Betreff: Re: Requirements Format
> 
> On 26/02/2019 16:15, Joel Sherrill wrote:
> >
> >
> > On Tue, Feb 26, 2019 at 8:57 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >
> >     Hello Joel,
> >
> >     On 26/02/2019 15:44, Joel Sherrill wrote:
> >     > Hi
> >     >
> >     > I have mentioned this before but reading ticket 3703, you obviously
> >     > didn't remember it.
> >
> >     I remember it and I think I proposed to use ReqIF.
> >
> >     > ReqIF is an OMG standard for representing
> >     > requirements in XML format. It was designed to facilitate
> >     requirements
> >     > exchange between partnering organizations.
> >     >
> >     > https://www.omg.org/spec/ReqIF/About-ReqIF/
> >     >
> >     > It appears to be supported by all the major requirement tools
> >     including
> >     > DOORS and LDRA's toolset. Importantly, it is supported by the
> >     Eclipse
> >     > Requirements Management Framework (RMF) and the ProR tool
> >     >
> >     > https://en.wikipedia.org/wiki/Requirements_Modeling_Framework
> >     > https://www.eclipse.org/rmf/
> >     > https://www.eclipse.org/rmf/pror/
> >
> 
> The ProR and ReqIF Studio look like mostly dead projects to me. They
> didn't manage to build a reasonable user base and community in the last
> couple of years. I experienced stability problems with both tools (e.g.
> NULL pointer exceptions). The documentation is not really great and if
> you start to try things beyond simple examples it gets hairy. I don't
> want to work with such tools and waste my time.
> 
> >     >
> >     > This is a solved problem. We should not define our own XML format.
> >     > One exists and there is a set of open source tools we can use to
> >     work
> >     > with requirements.
> >
> >     Did you try to use these tools? It is a nightmare.
> >
> >
> > We were starting to look at some requirements tools for another project.
> > Some of the feedback will be from people with experience with other
> > requirements tools. My impression is that requirements tools generally
> > suck.
> >
> >
> >     We evaluated also Papyrus:
> >
> >     https://www.eclipse.org/papyrus/
> >
> 
> My experience and one of our trainees with Papyrus are not really great.
> This is a complex tool you have to use intensively in your day to day
> work to be productive. There are some videos available, but getting
> started is quite difficult. I guess most people learn it with the help
> of colleagues. I also guess that it is used via in-house versions and
> not all known bugs are fixed in the public version. It is overkill just
> to manage requirements with it.
> 
> >
> >     I will try to summarize the problems we encountered using ReqIF in
> >     the
> >     next days.
> >
> >
> > The format or the Eclipse tools? The format is separate from the tools.
> 
> First, we need a data model for the requirements in the scope of RTEMS.
> You need this model also for ReqIF. ReqIF is the Requirements
> Interchange Format, the emphasis is on interchange. It is an open
> question, if it is suitable as a project internal representation for our
> requirements. At the moment I tend to use some sort of XML file and use
> a simple text editor.
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel