Doorstop Issues

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Apr 20 05:20:55 UTC 2020


On 20/04/2020 07:12, Chris Johns wrote:

> On 20/4/20 1:14 am, Sebastian Huber wrote:
>> Hello,
>>
>> I am about to add the next couple of hundred specification items for 
>> the RTEMS pre-qualification activity. Before I do this, I would like 
>> to present some issues that popped up during my daily work with 
>> Doorstop. Doorstop is a requirements management tool which was 
>> selected for the pre-qualification activity:
>>
>> https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop 
>>
>>
>> I am quite happy that Jan Sommer suggested to use this tool. I has 
>> some pretty nice features. In particular, I think the file based 
>> organization in YAML format forming a directed acyclic graph is 
>> really the right thing for this project. However, it turned out that 
>> it lacks the required flexibility.
>>
>> 1. Its use case is requirements management. So it has some standard 
>> attributes useful in this domain, like derived, header, level, 
>> normative, ref, reviewed, and text. However, I want to use it more 
>> generally for specification items and these attributes make not 
>> always sense. Having them in every item is just overhead and may 
>> cause confusion.
>>
>> 2. The links cannot have custom attributes, e.g. role, enabled-by.
>>
>> 3. Inside a document (directory) items are supposed to have a common 
>> type. I would like to store at a hierarchy level also distinct 
>> specializations.
>>
>> 4. The verification if the items is quite limited. We need 
>> verification with type-based rules.
>>
>> 5. The UIDs in combination with the document hierarchy lead to 
>> duplication, e.g. a/b/c/a-b-c-d.yml. You have the path (a/b/c) also 
>> in the file name (a-b-c). You cannot have relative UIDs in links 
>> (e.g. ../parent-req) . The specification items may contain multiple 
>> requirements, e.g. min/max attributes. There is no way to identify them.
>>
>> I will probably stop using Doorstop and use a custom tooling.
>
> Have you discussed these issues with the Doorstop project?
Not yet, but it would be quite a big change in Doorstop to fix these issues.
>
>> With Python, this is quite easy. I already have the infrastructure 
>> for this in:
>>
>> https://git.rtems.org/sebh/rtems-qual.git/
>
> Why not place the tool in the rtems-tools repo? This repo exists for 
> this purpose.
Now I am a bit confused. You wanted to have all the pre-qualification 
stuff separated.


More information about the devel mailing list