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-boun...@rtems.org] Im Auftrag von Sebastian > Huber > Gesendet: Mittwoch, 27. Februar 2019 08:43 > An: j...@rtems.org > Cc: rtems-de...@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.hu...@embedded-brains.de > > <mailto:sebastian.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel