Re: Requirement Management tools

[Mikail Yayla]

Hello all,

I am helping Sebastian trying out different requirement management tools.
We are currently evaluating doorstop and how well it can be used.

As an example we created a draft of a possible requirements management
document structure in doorstop for the queue creation with
rtems_message_queue_create.
Here is the created document structure: https://depot.tu-dortmund.de/rfek8

In the folder pub there are the automatically generated HTML files of the
requirement documents which can be viewed in the browser. In the rtems
folder are a few source files.  The other folders (header, include, llt,
reqs, source) are for doorstop documents.

I have tried out ProR and Papyrus as well, and in comparison to those two,
getting accustomed to doorstop was much simpler. There are only a few
command line directives, and using them allows creating a decent overview
of the document structure in HTML in a short time.

Here are the pros and cons for doorstop from my view:

Pros:
- Easy to use, either using the command line interface or creating and
editing the document files by hand.
- Automatic generation of the HTML overview. We can work on the requirement
document and see the changes immediately in the HTML using the publish
directive.
- Traceability is enabled by the file structure with fingerprints. When
changes occur in the documents, these fingerprints are changed. The
doorstop files live inside a version controlled folder, so changes can be
traced.
- Markup can be used in the text fields of the document files

Cons:
- It is a bit inconvenient to use a stringent way of naming files. I
stopped using the command line interface and started creating files by hand
because of this. The author also has this issue in this example:
http://jacebrowning.github.io/doorstop/index.html in
http://jacebrowning.github.io/doorstop/REQ.html
- Files can only reference one (source-)file. For links between doorstop
files, when a file has multiple child files, there are problems in the
HTML. Because of this I did not use links between files yet (links are used
to detect changes in the parent, as these could have an influence on the
children)

Possible bugs:
- For the ref field, in the documentation it says doorstop will first
search the file in the ref field (e.g. 'message.h') in the root and its
subdirs, and if no file was found it will search for matches in text files.
However, for INCLUDE001, the file 'rtems.h' is searched first although the
file 'message.h' exists. I'm still trying to find out the issue.
- In the item traceability table, some links disappear, and I haven't found
out yet why. For example, the links for HEADER are now missing. I think it
has to do with creating links between files, in the case when many children
refer to a single mutual parent file.
- Sometimes the HTML has to be cleaned by hand from old HTML files from
documents which were already deleted.

Other Points and ideas to extend doorstop:
- We could try to adapt doorstop such that it accepts reST in the text
fields, then we could use text from the documentation.
- A visualization of the document structure as a graph would be neat
- There is a GUI but it is experimental, can only be used to view the
document.

If you have some other ideas or other things we should try with doorstop,
please let us know.

Here is the summary of the materials:
The paper with some use cases for doortstop:
https://www.researchgate.net/publication/276044183_Doorstop_Text-Based_Requirements_Management_Using_Version_Control
The example from the author:
http://jacebrowning.github.io/doorstop/index.html
Our test example for RTEMS: https://depot.tu-dortmund.de/rfek8

Best,
Mikail

On Wed, Mar 13, 2019 at 1:00 PM Jose Valdez  wrote:

> Hello Sebastian,
>
> Thank you for creating this ticket. I believe this will help, since now
> the RTEMS community can contribute with other tools and add other tool
> selection criteria.
>
> Just a note that some selection criteria can be classified as "hard" (that
> means must have or must not have) and other as soft ("desirable" having/not
> having).
>
> I believe that you saw (but devel rtems did not), Andre Ribeiro proposed
> other tools:
> -> http://testlink.org
> ->http://www.eclipse.org/osee
>
> As far as I have seen, they use database, so they cannot be used, but
> maybe I can add them on the report for reference. Also myself take a look
> into another tools. From my research I concluded that almost tools were
> projects that started some years ago, but are deprecated now.
>
> Best regards
>
> José
>
>
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: quarta-feira, 13 de março de 2019 06:47
> To: Jose Valdez; devel@rtems.org
> Subject: Re: Requirement Management tools
>
> Hello,
>
> I added a ticket and a wiki page for this topic:
>
> https://devel.rtems.org/ticket/3726
>
> https://devel.rtems.org/wiki/Developer/RequirementsEngineering
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Addr

RE: Requirement Management tools

[Jose Valdez]

Hello Mikail,

Thank you for contributing to this discussion.

I have been also myself investigating the requirement management tools. 
Currently, I converged into the three tools:


è rmToo

è papyrus

è doorstop

During this week,  I took a deeper look into rmToo and doorstop and today I am 
into papyrus. My current conclusion of the analysis of rmToo vs doorstop is 
that the doorstop is more generic (it allows trace between other items besides 
requirements, ex: source code and tests), but it has the price that it has not 
so many specific functionalities for requirements. For example rmToo has the 
following that doorstep does not have:

è requirement analysis (for example looks for forbidden words/expressions in 
the requirements)

è more information in the requirements that doorstop (some useful, other maybe 
not), for example: author of the requirement, effort, status, priority, etc

è constraints can be added (although using like some of formal language written 
in python)

For the remaining features, I would say that the tools are similar (they have 
the same philosophy, although rmToo seems to be more complete but with no 
capability to trace to other items as doorstop).

Best regards

José

From: Mikail Yayla [mailto:mikail.ya...@tu-dortmund.de]
Sent: sexta-feira, 15 de março de 2019 10:33
To: Jose Valdez
Cc: sebastian huber; devel@rtems.org
Subject: Re: Requirement Management tools

Hello all,

I am helping Sebastian trying out different requirement management tools.
We are currently evaluating doorstop and how well it can be used.

As an example we created a draft of a possible requirements management document 
structure in doorstop for the queue creation with rtems_message_queue_create.
Here is the created document structure: https://depot.tu-dortmund.de/rfek8

In the folder pub there are the automatically generated HTML files of the 
requirement documents which can be viewed in the browser. In the rtems folder 
are a few source files.  The other folders (header, include, llt, reqs, source) 
are for doorstop documents.

I have tried out ProR and Papyrus as well, and in comparison to those two, 
getting accustomed to doorstop was much simpler. There are only a few command 
line directives, and using them allows creating a decent overview of the 
document structure in HTML in a short time.

Here are the pros and cons for doorstop from my view:

Pros:
- Easy to use, either using the command line interface or creating and editing 
the document files by hand.
- Automatic generation of the HTML overview. We can work on the requirement 
document and see the changes immediately in the HTML using the publish 
directive.
- Traceability is enabled by the file structure with fingerprints. When changes 
occur in the documents, these fingerprints are changed. The doorstop files live 
inside a version controlled folder, so changes can be traced.
- Markup can be used in the text fields of the document files

Cons:
- It is a bit inconvenient to use a stringent way of naming files. I stopped 
using the command line interface and started creating files by hand because of 
this. The author also has this issue in this example: 
http://jacebrowning.github.io/doorstop/index.html in 
http://jacebrowning.github.io/doorstop/REQ.html
- Files can only reference one (source-)file. For links between doorstop files, 
when a file has multiple child files, there are problems in the HTML. Because 
of this I did not use links between files yet (links are used to detect changes 
in the parent, as these could have an influence on the children)

Possible bugs:
- For the ref field, in the documentation it says doorstop will first search 
the file in the ref field (e.g. 'message.h') in the root and its subdirs, and 
if no file was found it will search for matches in text files. However, for 
INCLUDE001, the file 'rtems.h' is searched first although the file 'message.h' 
exists. I'm still trying to find out the issue.
- In the item traceability table, some links disappear, and I haven't found out 
yet why. For example, the files for HEADER are now missing. I think it has to 
do with creating links between files, in the case when many children refer to a 
single mutual parent file.
- Sometimes the HTML has to be cleaned by hand from old HTML files from 
documents which were already deleted.

Other Points and ideas to extend doorstop:
- We could try to adapt doorstop such that it accepts reST in the text fields, 
then we would use text from the documentation.
- A visualization of the document structure as a graph would be neat
- There is a GUI but it is experimental, can only be used to view the document.

If you have some other ideas or other things we should try with doorstop, 
please let us know.

Here is the summary of the materials:
The paper with some use cases for doortstop: 
https://www.researchgate.net/publication/276044183_Doorstop_Text-Based_Requirements_Management_Using_Version_Control
The example from the author: http://j

Re: Requirement Management tools

[Mikail Yayla]

Hello Jose,

thank you for the comparison.
I just want to add that doorstop also supports extended attributes in its
yml files, but the new attributes will not be part of published documents.
We would need to use other tools to process them. The requirements analysis
could also be done this way.

Best,
Mikail

On Fri, Mar 15, 2019 at 12:00 PM Jose Valdez  wrote:

> Hello Mikail,
>
>
>
> Thank you for contributing to this discussion.
>
>
>
> I have been also myself investigating the requirement management tools.
> Currently, I converged into the three tools:
>
>
>
> è rmToo
>
> è papyrus
>
> è doorstop
>
>
>
> During this week,  I took a deeper look into rmToo and doorstop and today
> I am into papyrus. My current conclusion of the analysis of rmToo vs
> doorstop is that the doorstop is more generic (it allows trace between
> other items besides requirements, ex: source code and tests), but it has
> the price that it has not so many specific functionalities for
> requirements. For example rmToo has the following that doorstep does not
> have:
>
> è requirement analysis (for example looks for forbidden words/expressions
> in the requirements)
>
> è more information in the requirements that doorstop (some useful, other
> maybe not), for example: author of the requirement, effort, status,
> priority, etc
>
> è constraints can be added (although using like some of formal language
> written in python)
>
>
>
> For the remaining features, I would say that the tools are similar (they
> have the same philosophy, although rmToo seems to be more complete but with
> no capability to trace to other items as doorstop).
>
>
>
> Best regards
>
>
>
> José
>
>
>
> *From:* Mikail Yayla [mailto:mikail.ya...@tu-dortmund.de]
> *Sent:* sexta-feira, 15 de março de 2019 10:33
> *To:* Jose Valdez
> *Cc:* sebastian huber; devel@rtems.org
> *Subject:* Re: Requirement Management tools
>
>
>
> Hello all,
>
>
>
> I am helping Sebastian trying out different requirement management tools.
>
> We are currently evaluating doorstop and how well it can be used.
>
>
>
> As an example we created a draft of a possible requirements management
> document structure in doorstop for the queue creation with
> rtems_message_queue_create.
>
> Here is the created document structure: https://depot.tu-dortmund.de/rfek8
>
>
>
> In the folder pub there are the automatically generated HTML files of the
> requirement documents which can be viewed in the browser. In the rtems
> folder are a few source files.  The other folders (header, include, llt,
> reqs, source) are for doorstop documents.
>
>
>
> I have tried out ProR and Papyrus as well, and in comparison to those two,
> getting accustomed to doorstop was much simpler. There are only a few
> command line directives, and using them allows creating a decent overview
> of the document structure in HTML in a short time.
>
>
>
> Here are the pros and cons for doorstop from my view:
>
>
>
> Pros:
>
> - Easy to use, either using the command line interface or creating and
> editing the document files by hand.
>
> - Automatic generation of the HTML overview. We can work on the
> requirement document and see the changes immediately in the HTML using the
> publish directive.
>
> - Traceability is enabled by the file structure with fingerprints. When
> changes occur in the documents, these fingerprints are changed. The
> doorstop files live inside a version controlled folder, so changes can be
> traced.
>
> - Markup can be used in the text fields of the document files
>
>
>
> Cons:
>
> - It is a bit inconvenient to use a stringent way of naming files. I
> stopped using the command line interface and started creating files by hand
> because of this. The author also has this issue in this example:
> http://jacebrowning.github.io/doorstop/index.html in
> http://jacebrowning.github.io/doorstop/REQ.html
>
> - Files can only reference one (source-)file. For links between doorstop
> files, when a file has multiple child files, there are problems in the
> HTML. Because of this I did not use links between files yet (links are used
> to detect changes in the parent, as these could have an influence on the
> children)
>
>
>
> Possible bugs:
>
> - For the ref field, in the documentation it says doorstop will first
> search the file in the ref field (e.g. 'message.h') in the root and its
> subdirs, and if no file was found it will search for matches in text files.
> However, for INCLUDE001, the file 'rtems.h' is searched first although the
> file 'message.h' exists. I'm still trying to find out the issue.
>
> - In the item traceability table, some links disappear, and I haven't
> found out yet why. For example, the files for HEADER are now missing. I
> think it has to do with creating links between files, in the case when many
> children refer to a single mutual parent file.
>
> - Sometimes the HTML has to be cleaned by hand from old HTML files from
> documents which were already deleted.
>
>
>
> Other Points and ideas to extend doo

rtems-libbsd build error

[Vijay Kumar Banerjee]

Hello,

I am trying to `./waf install` the libbsd but getting some error, need help
with that. The commands used and the errors are given below ...

configured using: `./waf configure --buildset=buildset/default.ini
--prefix=$HOME/development/rtems/5 --rtems-arch=arm`

configure was successful.

then : `./waf install`

Error ...

Build failed
 -> task in 'lex__nsyy' failed with exit status 1 (run with -v to display
more information)
 -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to display
more information)
 -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
more information)
 -> task in 'yacc_pcap' failed with exit status 1 (run with -v to display
more information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more
information)
 -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to display
more information)



Thanks
--vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> Hello, 
> 
> I am trying to `./waf install` the libbsd but getting some error, need help
> with that. The commands used and the errors are given below ...
> 
> configured using: `./waf configure --buildset=buildset/default.ini
> --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> 
> configure was successful.
> 
> then : `./waf install`
> 
> Error ...
> 
> Build failed
>  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'objs01' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'objs01' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> display more information)
> 
> 
> 
> Thanks
> --vijay
> 

Hello Vijay,

did you try to build before the install? I don't see the call. Normally it's

  waf configure ...
  waf
  waf install

If you did that: It seems that some of the lex / yacc files should be
regenerated. Did you enable --enable-auto-regen somewhen during an
earlier configuration run (not necessary except if you import yacc or
lex files)? Did you import some yacc or lex files?

Best regards

Christian

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

erc32 dl09 Failure

[Joel Sherrill]

Hi

Is this the way this test fails when the BSP doesn't have enough memory?

*** BEGIN OF TEST libdl (RTL) 9 ***
*** TEST VERSION: 5.0.0.2defa94c4ce2204cf5cb86d2900d8c48e7d7d781
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
--
 Run: 0
Test source (link in strstr): testsuites/libtests/dl09/dl-load.c
load: /dl09-o1.o
handel: 0x206cc20: unresolved externals
handle: 0x206cc20 loaded
space alloc: /dl09-o1.o: 33554432: 0
../../../../../../rtems/c/src/../../testsuites/libtests/dl09/dl-load.c: 156
o->space != NULL

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.2defa94c4ce2204cf5cb86d2900d8c48e7d7d781
RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
executing thread ID: 0x08a010001
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Fri, 15 Mar 2019 at 21:47, Christian Mauderer  wrote:

> Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > Hello,
> >
> > I am trying to `./waf install` the libbsd but getting some error, need
> help
> > with that. The commands used and the errors are given below ...
> >
> > configured using: `./waf configure --buildset=buildset/default.ini
> > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >
> > configure was successful.
> >
> > then : `./waf install`
> >
> > Error ...
> > 
> > Build failed
> >  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> > display more information)
> >
> > 
> >
> > Thanks
> > --vijay
> >
>
> Hello Vijay,
>
> did you try to build before the install? I don't see the call. Normally
> it's
>
>   waf configure ...
>   waf
>   waf install
>
> If you did that: It seems that some of the lex / yacc files should be
> regenerated. Did you enable --enable-auto-regen somewhen during an
> earlier configuration run (not necessary except if you import yacc or
> lex files)? Did you import some yacc or lex files?
>
> I had to install `byacc` package using yum in fedora, then I used the
--enable-auto-regen
option, that worked.
However, it's still not building and I'm seeing a lot of warnings, I think
this is because of the
files I imported from the freebsd source, maybe they depend on some other
headers that
I didn't include. Any suggestion on how to debug, if this is the case?

> Best regards
>
> Christian
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> 
> 
> On Fri, 15 Mar 2019 at 21:47, Christian Mauderer  > wrote:
> 
> Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > Hello, 
> >
> > I am trying to `./waf install` the libbsd but getting some error,
> need help
> > with that. The commands used and the errors are given below ...
> >
> > configured using: `./waf configure --buildset=buildset/default.ini
> > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >
> > configure was successful.
> >
> > then : `./waf install`
> >
> > Error ...
> > 
> > Build failed
> >  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to
> display
> > more information)
> >  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> > display more information)
> >
> > 
> >
> > Thanks
> > --vijay
> >
> 
> Hello Vijay,
> 
> did you try to build before the install? I don't see the call.
> Normally it's
> 
>   waf configure ...
>   waf
>   waf install
> 
> If you did that: It seems that some of the lex / yacc files should be
> regenerated. Did you enable --enable-auto-regen somewhen during an
> earlier configuration run (not necessary except if you import yacc or
> lex files)? Did you import some yacc or lex files?
> 
> I had to install `byacc` package using yum in fedora, then I used the
> --enable-auto-regen
> option, that worked. 
> However, it's still not building and I'm seeing a lot of warnings, I
> think this is because of the
> files I imported from the freebsd source, maybe they depend on some
> other headers that 
> I didn't include. Any suggestion on how to debug, if this is the case? 
> 
> Best regards
> 
> Christian
> 


Hello Vijay,

normally you shouldn't need the --enable-auto-regen option. It only
changes a lot of files that you don't want to change. Especially: If you
use Fedora (or some other Linux) you get GPL licensed output. We
normally use FreeBSD for that step and check in the generated files so
that no user has to use --enable-auto-regen.

Regarding how to start such a port: Normally it's a good idea to get
some overview over what's missing. For that you import the files that
you think are relevant (like you already did). Then you can build with
`waf -k -j1` which continues even if some files are not compilable (-k
is for continue, -j1 so that you receive the messages in order). You
should get a lot of compiler errors during that run.

Now comes the hard part: You have to analyse the errors and try to find
out what's the reason for them. If some big part is missing you most
likely get a lot of similar errors (like "header xy.h not found"). Most
likely you can identify some groups. With that you can estimate what has
to be ported besides the files you already imported.

Identifying these groups is a quite relevant step for planning the
amount of work for your GSoC proposal. If you are unsure, try to ask on
the mailing list. You can also post the build output and an assumption
what groups you estimate to get some feedback.

Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel