ReqXLS: Is it possible to agree on a common Excel format for exchanging requirements?

[stanislaw]

Currently, StrictDoc has only rudimentary support of Excel export/import function. Due to some obvious parallels with how StrictDoc handles the ReqIF export/import, I thought it makes sense to discuss the implementation of a generic Excel interexchange format, and the name for that could be ReqXLS.

Here are some bullet point requirements for what I see could be a good interoperability between StrictDoc and Excel documents:

• Similar to ReqIF, StrictDoc's integration test suite should contain round-trip tests: export an .sdoc to Excel, import Excel back to .sdoc, ensure that the .sdoc files are identical.
• Each tab in the Excel document should correspond to a single document. A tab name is a document name.
• There should be a dedicated column type indicating: REQUIREMENT, SECTION, FREETEXT, etc.
• There should be a dedicated column type indicating level in the TOC: 1, 1.1, 1.1.1, etc.
• Idea: Problematic field: COMMENT. A requirement can have many comments - introduce a separate row with a type REQUIREMENT_COMMENT with one row per one comment.
• Similar idea: Problematic field: REFS. A requirement can have many refs - introduce a separate row with a type
  REQUIREMENT_REF_PARENT, REQUIREMENT_REF_FILE, REQUIREMENT_REF_BIBTEX etc. with one row per one comment.
• Open question: which column to use for a comment's or a ref's content?
• Generate Sections with larger font size so that the Excel document reads like a normal document.
• What else?

[stanislaw]

cc @BenGardiner @GGBeer

[BenGardiner]

thanks @stanislaw , could be a great feature indeed.

To roundtrip an .sdoc the excel sheet will also need to capture the GRAMMAR stuff like required/optional and type. I think this stuff in row 1 would work but I could see it being put in row 9999ish instead. we could hide it or make the font very small to make it less obtrusive.

The TOC levels would be read-only in sdocs that autonumber right?

I think your proposal for multiple rows of comments and refs following a requirement is workable; the dedicated type column could list COMMENT , REQUIREMENT_REF_PARENT, REQUIREMENT_REF_FILE, REQUIREMENT_REF_BIBTEX for each and the ReqXLS parsing could append them to the last requirement instantiated.

Open question: which column to use for a comment's or a ref's content?

I think that SECTION and FREETEXT will need a 'content' column and this too could be used for the comment or ref contents

[GGBeer]

Maybe we should put the meta-data of the DOCUMENT.CONFIG, FRAGMENT, GRAMMAR and BIBLIOGRAPHY parts in additional Worksheets per document. A Worksheet name can have max. 32 characters, used by the document name and some short extension to differentiate the additional Worksheets. This SDoc meta-data is definitly needed for doing a roundtrip .sdoc <=> excel.

This also allows us to delete some of these additional "SDoc" worksheets before sending it to the final recipient, which should not be bothered/interfere with SDoc.

Idea: Partial-Roundtrip:
The Requirement Edits/Comments of the recipient should be merged (or at least diffed) with the original SDoc files on import of the edited excel file. I.e. use the original SDoc files meta-data and add/replace the recipient's edits. This could be usefull in case of multiple parties working on the requirements using Excel as exchange-interface. Also the case of having the requirements as part of a tender and the contractor has to show/describe its compliance.

[GGBeer]

Requirements having fields with multiple entries, should continue on the next row, repeating the Req's UID and add the next field entry into the field's column.
Nice-to-have: In case of multiple fields with multiple entries. e.g. 5x REQUIREMENT_REF_BIBTEX and 3x Comment, the field's columns are filled in parallel. Resulting in only 5 Rows for this requirement.

[stanislaw]

Thank you for the comments! I am slightly distracted by some life stuff, so I did not prepare yet a top-down definition of what we all want, including the implementation options. I would like to synthesize our thoughts with your comments in a more concise form.

One interesting idea that I discussed with @mettta was that we could make the TBL view also conform to this "ReqXLS". This way, both StrictDoc's TBL and exported Excel would both have the same structure. This idea looks quite attractive, but we are not sure yet if it will not limit either of the TBL and Excel. Furthermore, with the new server/UI work, it is very doable to make the TBL fully editable, just as much we are implementing the editing of DOC now.