<div dir="ltr"><div dir="ltr">Moved to devel </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 21, 2019 at 6:23 AM Jose Valdez <<a href="mailto:Jose.Valdez@edisoft.pt">Jose.Valdez@edisoft.pt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US"><div class="gmail-m_-1473094641044751686WordSection1"><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Hello All,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Regarding the Requirement Management Tools, in these two days, I tried to build an example using both tools and my conclusions were the following:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">rmToo: I analyzed the requirement features there and they did not satisfy me:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  2 -> there is info that cannot be put on the requirements (type of Verification)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  3 -> The way the requirements are organized I believe will not cope with user needs</span></p></div></div></blockquote><div><br></div><div>I co-authored a tool which analysed requirements for "quality". Enforcing that while entering</div><div>the requirements was a horrible decision on their part. Yes, "and" is often a bad sign for a</div><div>requirement but it isn't always. Plus it isn't the only bad sign. When a table is referenced in</div><div>a requirement, that's often a strong hint that the requirement is really really bad. You can</div><div>put dozens of requirements in a table. OTOH, I saw one example where the table referenced</div><div>had controlled information. So it was a clean way to control access to the sensitive information.</div><div><br></div><div>Requirements quality is harder than I bet they did. You can look at the requirements set as</div><div>a graph and look for loops, big clusters of derived requirements, and requirements with no</div><div>parents or children. You can look at the requirements as text and look for forbidden words,</div><div>duplicative requirements, and compound requirements.The tool I refer to had a plagiarism </div><div>algorithm and detected when two requirements were "too close". It also checked requirements</div><div>for user defined forbidden words. On one project, the requirements were merged from multiple</div><div>earlier projects and still had the wrong project names. The forbidden words checked that old</div><div>project names didn't show up.</div><div><br></div><div>Anyway, entry, derivation, hierarchy management, and optional user attributes are what a tool</div><div>should manage. And entry isn't much if the requirements format is easy and open. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1473094641044751686WordSection1"><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">doorstop: After re-analysing, I believe now that the doorstop is, out of the analysed tools, the best choice:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  2 -> Traceability between requirements and other items (architecture, source code and tests)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  3 -> We may change the name of the items (not mandatory to cope with XXX001 default format of the tool)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  4 -> Active project (although I believe this does not assure that it will be in the future)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">  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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"> 6 -> I believe we can live without a requirement analysis feature, being that responsibility the requirement’s author<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"> 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</span></p></div></div></blockquote><div><br></div><div>4. No one can predict the future and I expect the user base for any tool like this</div><div>is fairly small and quiet since anyone doing requirements is unlikely to speak publicly.</div><div><br></div><div>5. Is it possible to have custom fields? I worked on a project where requirements were </div><div>tagged with project phase and HW/SW. Alternatively, can we add comments to the YAML</div><div>files. Or who cares since the author information is in git.</div><div><br></div><div>6. This should be a separate pass.</div><div><br></div><div>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</div><div>used in their code (link to github with source and line.</div><div><br></div><div>It has a prototype GUI. How is it?</div><div><br></div><div>Is the documentation and/or tutorial sufficient to get us started? Whatever tool is adopted,</div><div>common tasks will have to be documented like we do with git use.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1473094641044751686WordSection1"><p class="MsoNormal"><span style="font-family:Arial,sans-serif"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">My choice is for doorstop. Since this is the preferred tool of you, shall I assume this tool our final choice?</span></p></div></div></blockquote><div><br></div><div>I'd wait for others to speak up. But there aren't many options.</div><div><br></div><div>Did you see my comments on capturing this in the Software Engineering Guide? I had suggestions</div><div>for general requirements and a section for specific to each tool category (e.g. source code control,</div><div>issue tracking, documentation, etc.) The RTEMS Project should capture the requirements and</div><div>evaluation for any tool we select and record that publicly. We will have to try to back fill a bit</div><div>for other tools.</div><div><br></div><div>--joel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-1473094641044751686WordSection1"><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Best regards<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Arial,sans-serif">José<u></u><u></u></span></p></div></div></blockquote></div></div>