Document expected baselining/tracing with Git

[gregshue]

I'm trying to determine how many Git repositories I need to support scalable requirements management with Strictdoc. Please add a guide describing how the expected/supported way of using StrictDoc with Git to address:

1. Horizontal Scaling (within each decomposition layer multiple files are introduced with independent edit/baselining cycles);
2. Vertical Scaling (where new decomposition layers are added to the document tree with independent edit/baselining cycles);
3. Relationships controlled outside of the statement repository;

For example:

1. The Stakeholder Needs/Requirements layer describes the scope of the relevant problems. It must always be open to additions to capture needs as they are reported. Baselines must be created for this dynamically changing set so that lower layer documents can be traced to these statements. This baseline must be independent of the lifecycle of the lower layer documents.

2. The System Requirements layer describes the scope of the (opaque) solution. This must trace back to Stakeholder items. Sometimes this tracing needs to be outside of the repositories providing the Stakeholder and System requirement statements. E.g., System Requirement statements and some User Needs ("As a Product Manufacturer, I need ...") come from a Zephyr Project release. Others come from a release of an open source project from a different organization ("As a Product Manufacturer of a hearing aid, I need ...")). These are integrated into a single product. The tracing must be controlled by the Product Manufacturer in a different repository.

3. The next decomposition cycle ("element") Requirements layer describes the scope of the (opaque) element. This must trace back to System Requirements and be on a different lifecycle than the system requirements themselves. These also may be an aggregation from multiple sources of requirement statements.

Here are some questions I'd like answers to:

a) How do you recommend Git be used to achieve a baseline for a particular document?
b) How do you recommend Git be used to support independent lifecycles for different documents?
c) How do you recommend Git be used to provide control and capture of relationships between document layers independent of the requirement statements in each layer?

Please describe in detail how you expect users to apply the following to provide a scalable solution:

• Git repos
• Git branches
• Git tags
• Git subrepos

[johanenglund]

@gregshue Hi Greg, have you perchance developed a strategy for this yet? I'm in the early stages of setting up a IEC 61508 SW project myself so I'd be very interested to hear what you have ended up with so I don't have to make all the mistakes myself!

[gregshue]

@johanenglund Thanks for asking. I have not pursued this outside of this discussion. Here are some of my reasons:

1. I must honor limits imposed by licenses of commercial products I am currently using at work;
2. The problem space aligns far better with a database domain than a file system domain;
3. Git itself does not provide access or process controls, which are ultimately needed at an individual item/statement level to restrict changes and prevent invalid state transitions;

I'm happy to discuss user needs and identify issues with whatever anyone proposes though!

[johanenglund]

@gregshue Thank you for a prompt reply! How unfortunate that licensing is hampering your open source contributions, sorry to hear.

It would have been very interesting with a couple of case studies of successful implementations of strictdoc.

I'll give the organizational issues some thought and if I manage to get the whole process approved by our 3rd party assessors I'll make an effort to contribute with the setup and lessons learned.

[gregshue]

@johanenglund Actually, I assume the tool licensing prevents development of a competitive "product". I have found many of the concepts they provide to be important, very useful, and beyond what is commonly recognized (e.g., access control at the individual item level) so I'm choosing to be very conservative and honor their value-add.

I think the best opportunities for case studies is by watching open-source projects. The Linux Foundation's Zephyr Project has chosen to go with StrictDoc but they are not very far along. I don't think that is due to StrictDoc or Git though. Perhaps there is some academic work using the tool?

What I would love to see is an open-source security-certified firmware image that used StrictDoc for requirements tracing. The best candidate I can think of is an immutable bootloader for a commercially available SOC development kit. This would have nothing confidential or requiring paid licenses, so everyone could see the complete solution.

Thanks for the discussion. I look forward to anything you can share.