RTEMS Requirement Management Tools

[Joel Sherrill]

Moved to devel

On Thu, Mar 21, 2019 at 6:23 AM Jose Valdez <Jose.Valdez at edisoft.pt> wrote:

> Hello All,
>
>
>
> This e-mail will serve to answer some questions that were raised in other
> e-mails regarding Requirement Management Tools selection and this project
> in general.
>
>
>
> First of all, sorry if the way I am sending information to RTEMS community
> is not adequate. For me it has been a little bit difficult because I have
> to contact with two groups, which have their own way to work. If you agree,
> I propose that the discussions shall be held in the Qualification RTEMS SMP
> Tech group with Chris, Gedare, Joel and Mikail (since they are also
> directly involved) also as recipients and then the final conclusions shall
> be put on the community group, with the appropriate format (this idea was
> already proposed by Marcel, if I recall correctly). Please tell me if you
> agree or you have a different idea, which we shall discuss and agree,
> otherwise we will create entropy in this work.
>
>
>
> Regarding the Requirement Management Tools, in these two days, I tried to
> build an example using both tools and my conclusions were the following:
>
>
>
> rmToo: I analyzed the requirement features there and they did not satisfy
> me:
>
>   1 -> the requirement analysis are not adequate in most cases. For
> example it subtracts points in requirement quality, by having the words
> “and” and “or”, which are allowed. Also there is a bug, which adds points
> with the “may” word, which is forbidden in the requirements.
>
>   2 -> there is info that cannot be put on the requirements (type of
> Verification)
>
>   3 -> The way the requirements are organized I believe will not cope with
> user needs
>

I co-authored a tool which analysed requirements for "quality". Enforcing
that while entering
the requirements was a horrible decision on their part. Yes, "and" is often
a bad sign for a
requirement but it isn't always. Plus it isn't the only bad sign. When a
table is referenced in
a requirement, that's often a strong hint that the requirement is really
really bad. You can
put dozens of requirements in a table. OTOH, I saw one example where the
table referenced
had controlled information. So it was a clean way to control access to the
sensitive information.

Requirements quality is harder than I bet they did. You can look at the
requirements set as
a graph and look for loops, big clusters of derived requirements, and
requirements with no
parents or children. You can look at the requirements as text and look for
forbidden words,
duplicative requirements, and compound requirements.The tool I refer to had
a plagiarism
algorithm and detected when two requirements were "too close". It also
checked requirements
for user defined forbidden words. On one project, the requirements were
merged from multiple
earlier projects and still had the wrong project names. The forbidden words
checked that old
project names didn't show up.

Anyway, entry, derivation, hierarchy management, and optional user
attributes are what a tool
should manage. And entry isn't much if the requirements format is easy and
open. :)


>
>
> doorstop: After re-analysing, I believe now that the doorstop is, out of
> the analysed tools, the best choice:
>
>   1 -> Simple to install and to use. Answering to Chris question, the
> scope of project will just pick-up tools compatible with debian, however,
> we may keep this in mind and try to choose platform independent tools.
>
>   2 -> Traceability between requirements and other items (architecture,
> source code and tests)
>
>   3 -> We may change the name of the items (not mandatory to cope with
> XXX001 default format of the tool)
>
>   4 -> Active project (although I believe this does not assure that it
> will be in the future)
>
>   5 -> I believe the problem of there is no native requirement info fields
> (author, type of verification, status, etc – Maybe a lot of them will not
> be used), can be overcome by put in the requirement text itself or by
> creating a separate document for each requirement (with linkage) containing
> some info. For example, if we have requirements R1 to R10, we can create a
> document called authors and then create authors A, B, C and link each
> requirement to the proper author.
>
> 6 -> I believe we can live without a requirement analysis feature, being
> that responsibility the requirement’s author
>
> 7 -> Question: There is a field ‘header’, present in the input YAML files,
> which seems not mandatory, but which I would like to know what is its use
>

4. No one can predict the future and I expect the user base for any tool
like this
is fairly small and quiet since anyone doing requirements is unlikely to
speak publicly.

5. Is it possible to have custom fields? I worked on a project where
requirements were
tagged with project phase and HW/SW. Alternatively, can we add comments to
the YAML
files. Or who cares since the author information is in git.

6. This should be a separate pass.

7. Ask on their mailing list if you can't tell from the code. Or ask here
if you can point to where it is
used in their code (link to github with source and line.

It has a prototype GUI. How is it?

Is the documentation and/or tutorial sufficient to get us started? Whatever
tool is adopted,
common tasks will have to be documented like we do with git use.



>
>
> My choice is for doorstop. Since this is the preferred tool of you, shall
> I assume this tool our final choice?
>

I'd wait for others to speak up. But there aren't many options.

Did you see my comments on capturing this in the Software Engineering
Guide? I had suggestions
for general requirements and a section for specific to each tool category
(e.g. source code control,
issue tracking, documentation, etc.) The RTEMS Project should capture the
requirements and
evaluation for any tool we select and record that publicly. We will have to
try to back fill a bit
for other tools.

--joel


>
>
> Best regards
>
>
>
> José
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190321/a8f29347/attachment-0001.html>