Create 2024-08-02.md

safety/2024-08-02.md

@@ -0,0 +1,49 @@
+# SPDX FuSa Meeting 2024-08-02
+
+## Attendees
+* Steven Carbno
+* Nicole Pappler
+* Chuck Wolber
+* Alfred Strauch
+* Ryan Brooks
+* Kate Stewart
+* Ayan Kumar Halder
+
+## Agenda
+- Continue discussion of modeling
+
+## Notes
+- Introduced notion of Action, that has been introduced 
+- Things on checklists makes sense as "Actions" class 
+   - Actor vs Participant vs Agent (what we have defined).
+   - Roles for participants - "Role is based on type of actor" 
+   - Actor type is not sufficient to differentiate role. 
+   - Should Actor have a role property,  or should we use a set of relationship types.
+   - We should differentiate context of entity vs their roles around actions?
+- Is an Agent a system?   OTE - Automated test Environment.  
+   - How should a system be tied into this?
+   - X person started the automated test framework, then.
+- For now - let's use element collection for a system.    Can Element collection be used as an agent object?
+   -Do we need an "operates" type of relationship.    Who operates the action. 
+   - Do we need an object that shows what is a standard. 
+   - Plan for Aspect of Cerification (PSAC) is document calling the shots... 
+- Should we consider Certification as a "Requirement";   
+  - Certification plans tree down to subsystems; and show evidence of compliance during the processes.    Might be refered to as a compliance plan. 
+  - Design is encompassed in requirements,  so not sure certification should be considered this way. 
+  - Pedigree to show actors are qualified for the job.
+- Top level is compliance plan, which breaks down into subsystems...
+- Compliance Object - need somethign to represent the standard as it's own entity.  Which things comply with. 
+    - Hazard Assessment, Mitigation, and Compliance.
+- Standard would be an Artifact.
+  - then it would be a requirement the Safety Plan. 
+
+- Should we add a type to requirements - to encompass standards?   Let's try this.  
+   - Hazard assessment, should provide level of rigour.   Doing hazard assessment creates requirements on system as well. 
+   - Consider adding type on requirement object
+   - Chuck will look to see if we can map PSAC to these concepts.
+
+- Discussion should requirements have actions associated with them, that can generate evidence, that becomes requirements. 
+- Should we have requirement types?   chaining.   Someone's evidence, is another part's relationship.
+- Types:  planning, execution, etc. ...   
+- Evidence says, we need more requirements.    Evidence is "generating" Requirments.
+- Abstraction of planning document.