paissad / reqcoco Goto Github PK

Currently, when the property "redmine.req.declaration.customfield" is set, and when at the same there are no Redmine issues which use that custom field, all Redmine issues are retrieved while it should not be the case.
BTW, the property "redmine.req.tag.required" is set to "false"

Requirements should be able to contain the notion of group
It should not be mandatory to repeat/rewrite the 'group' tag into the @ReqSourceCode or @ReqTestCode as soon as it is already specified into @Req declaration.
Example: @Req(group = "req_grp_1", id = "xx", version = "1.0", revision = "r0" ...)

When using opening or closing parenthesis into a tag of a requirement declaration, the requirement is not retrieved correctly.
Example:
@Req(id="healthchecklb_004", summary="foo (bar)", version="2.0", revision="r0")

The current result returned attached to this issue.

The excel report should look at least look like the HTML report with a table report and some charts.

Knowing that the full description can be very large, it might be useful to encode it into base64 in order to reduce the size of the raw report file.

An optional a tag named for instance "status" which defines the status of the requirement, either for the code or the test.
The following statuses could be used:

• not started
• in progress
• done
• fail

When a requirement has been developed in a revision "r1" for example, while the revision "r2" is the new expected development, it would be good to mark the requirement as outdated.

When recursively parsing a directory for retrieving all requirements declarations, instead of treating all files as simple text files, the most accurate parser should be used to avoid the maximum of parsing failure.

For instance, if a directory contains files with the following extensions .docx , .xlsx, .json, .xml, .txt, .html , .png .... then:

• The MS WORD requirement parser should be used in priority for the .docx file
• The MS EXCEL requirement parser should be used in priority for the .excel file
• The simple text parser should be used for the other files

Add the possibility to get a badge which shows the percentage of requirements coverage (code and tests)

Add the 'status' and 'comment' informations into the table reports

All parsers are currently developed internally even though they are all in different maven modules.
It would be better if they could be defined as plugins.
Or at least add a new plugins directory where the Runner and the maven plugin could load new parsers depending on what is into the classpath

The title is explicit enough

It would be good to show the relations between requirements if the relations are already defined from a source like Redmine for example

The runner and the maven plugin should accept a complementary and optional argument which limit the versions for which to compute the requirements coverage.

This issue depends on issue #26
For the test requirement status, if the JUnit test status is "failure", then the requirement status should be set to the equivalent of "failure" as well

It would be good to have a field which indicates the type of the source where the requirements have been declared
For example, the sourceType would be FILE or DOCX or XLSX or REDMINE, etc ...

Add JSON output report which contains all the informations as in the same as for the excel or html coverage reports

Add the possibility to parse simple text files which are into a directory.
The parsing should be recursive and all files which cannot be parsed should be ignored and logged as warning or error.

Add the possibility to skip the execution of the maven plugin via a property like ${reqcoco.skip}

Add a parameter into the reqcoco.properties file which defines whether or not it is mandatory for developers and testers to add their name into the requirements @ReqSourceCode and @ReqTestCode

Add the possibility to set the requirement tag @Req into a custom field rather than the subject field so far.

Until version 1.0.4, when the tags @ReqSourceCode or @ReqTestCode are used, if the 'status' tag is not specified, the requirement is considered as DONE
This can be tricky, and default status should be TODO rather than DONE