<div dir="ltr">Interesting question about conformance. There are a few aspects:<div>a) is a modeling tool able to load and support the CSRM profile?</div><div>b) is a modeling tool able to additionally load the actual CSRM model? Despite the model not being normative, the tool is clearly pretty useless for CSRM purposes if it can load only the profile but not the reference model/framework that everyone is supposed to start from. In the sense of tool conformance the reference model is like a test so there's nothing wrong IMO with using it for conformance</div><div>c) is an actual Cubesat model conformant with the  constraints in the profile? Since the constraints in the profile are normative then this can be part of formal compliance</div><div>d) is an actual Cubesat model consistent with the structure in the reference model? This relates more to your "strongly encouraged" point. I think this aspect could be taken further (in FTF) with regard to indicating what must be retained and what dispensed with. It might not represent formal compliance with the specification but we could use a milder phrase such as "consistent with".</div><div><br></div><div>a) and b) relate to the modeling tool; c) and d) relate to an actual model.</div><div>All are, I think, appropriate.</div><div><br></div><div>Pete</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Jun 2021 at 20:01, Manfred Koethe <<a href="mailto:koethe@88solutions.com">koethe@88solutions.com</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 dir="auto" style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div style="overflow-wrap: break-word;">Hi Dave,<div><br></div><div>Please find below my very initial review of the current CSRM Submission. The quality has substantially improved, but, and I’m sorry to say that, the current document is still somewhat disappointing.</div><div><br></div><div>I still need to go through the other parts, but are at the moment a bit crippled by a hardware failure.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Manfred</div><div>___________________<div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>Manfred Koethe</div><div>88solutions Corporation</div><div><a href="mailto:koethe@88solutions.com" target="_blank">koethe@88solutions.com</a></div><div>+1 (619) 736-1001</div><div><br></div></div><br></div><div><div>Initial AB Review: Cube Sat Reference Model [ Part 1 ]</div><div><br></div><div>General Note</div><div>-------------------</div><div>The whole document needs a "gramar refurbishment" for improved readability. As a non-native (and in particular German) speaker, I don't feel qualified to provide fully detailed instructions. I wil try my best, however. :-)</div><div><br></div><div>Clause 1 Scope</div><div>----------------------</div><div>In general, I find the the Scope clause rather washed-out and confusing. Length is not the criterion here, but clarity is.</div><div><br></div><div>The 4th paragraph is particularly confusing:</div><div>"A mission-specific CubeSat team will download the CSRM normative Specification XMI file from OMG and import it into their own graphical modeling tool. It is anticipated that the mission-specific CubeSat team will use non-normative material to guide development of their Mission-Specific Model (MSM). The mission team identifies the systems engineering methodology to be followed and revises the MSM organization, elements, relationships, and diagrams as needed."</div><div><br></div><div>It should at least make clear that the CSRM Specification consists of a normative profile that defines the necessary stereotypes (and is supposed to be used as-is), and an unpopulated, educational CSRM model skeleton as a starting point for a project-specific cube sat model.</div><div><br></div><div>In summary, Clause 1 Scope should just state three things:</div><div><br></div><div>- This is a specification to aid the development of CubeSat Space-Ground Systems Models</div><div>- It consists of a normative Profile defining all required stereotypes</div><div>- And it consists of an unpopulated skeleton CubeSat SysML model as starting point for project-specific development.</div><div><br></div><div>If you can find some nice words around these three key points and get rid of all that stakeholder blah blah, that would make a nice, concise and attractive Scope clause.</div><div><br></div><div>Clause 2 Conformance</div><div>--------------------------------</div><div>The only normative part of this specification is the CSRM Profile, which is fundamental to everything else. Therefore, you need to state that:</div><div><br></div><div>"Conformant implementations must implement the CSRM Profile in its entirety."</div><div><br></div><div>[ ideally, the Profile should be usable "as-is, out of the box", however experience shows that some form of customization by tool vendors could improve the usability of the Profile in the respective tool, therefore it is valid to refer to an "implementation" here. ]</div><div><br></div><div>For the "educational" part of CSRM, you can legally only state:</div><div><br></div><div>"CubSat model developers are strongly encouraged to use the provided skeleton model without altering its structure to maximize the opportunity for reuse and/or interchange."</div><div><br></div><div>Since the provided csrm model itself is not normative, you cannot put more force here.</div><div><br></div><div>Clause 3 Normative References</div><div>-------------------------------------------</div><div>Besides citing SysML, I believe you need to cite domain-specific documents too. I saw  a message from you including such kind of documents, you need to reference them here in Clause 3.</div><div><br></div><div>Clauses 4 and 5</div><div>-----------------------</div><div>Both clauses should point to Annex B, therefore Clause 5 needs correction.</div><div><br></div><div>[ it would improve the structure of the document to make abbreviations, references and glossary three separate annexes ]</div><div><br></div><div>Clause 6 Additional Information</div><div>-------------------------------------------</div><div>It would be good style to start Clause 6 with an "How to read this specification", pointing to the various parts, and in particular enumerate which part is normative, which part is informative, and which part is educational.</div><div><br></div><div>Then, if you really want to talk about all the stuff around stakeholders, etc., which you stuffed into the Scope, here would be the right place to clean all that stuff out of the Scope and consolidate it in a subclause of Clause 6. And since Clause 6 is implicitly non-normative, you don't need to mark the moved stuff as informative.</div><div><br></div><div>Clause 7 CSRM Profile</div><div>--------------------------------</div><div>Since this specification is a collection of normative, informative and educational parts, I recommend to mark Clause 7 explicitly as "normative".</div><div><br></div><div>In the first sentence of 7.1, replace "the sysML" by "SysML".</div><div><br></div><div>Figure 2 is not readable. Please use (and provide) a SVG vector graphic.</div><div><br></div><div>Subclause 7.1.1: The first sentence is incomplete. Also, I'm not sure if the whole stakeholder discussion needs to be repeated here, I find it rather confusing. Brevity would be helpful. Maybe eliminate thee first paragraph, or at least substantially compact it.</div><div><br></div><div>Subclause 7.1.3: If MissionNeed "drives everything else", and you are not using alphabetic ordering, then why not starting Clause 7 with MissionNeed? [ just a thought...]</div><div><br></div><div>Subclause 7.1.5: It does not "define the system's expectations" but the "expectations on the system's capabilities".</div><div><br></div><div>Subclause 7.16: describing "CubeSatRequirement" as "Requirement of the CubeSat system" is rather lame and not helpful. Also, shouldn't it be "requirements on the CubeSat system"? Your sentence is semantically the inverse direction....</div><div><br></div><div>Reading on, I have a rather fundamental question:</div><div>You are using the language (in 7.1.6 and following subclauses) "XYZ Requirement is a requirement of XYZ", which means XYZ requires something. Are you not meaning "XYZ Requirement" is a requirement that XYZ needs to fulfill? Then the phrase should be something like "XYZ Requirement" is a requirement on (or for) XYZ". Please clarify, this is very important.</div><div><br></div><div>Reading on even more, ALL the requirements descriptions are very lame, and implying the inverse semantic direction. This MUST be corrected since it confuses the reader.</div><div><br></div><div>Subclause 7.1.11: What is a "space segment"? This is really in need of a few more senseful words.</div><div><br></div><div>Subclause 7.1.12: "This element is not intended to be refined, verified, satisfied, or verified." What? What does that mean?</div><div><br></div><div>Subclause 7.1.13: The description does (IMHO) match the element is is supposed to describe.</div><div><br></div><div>Subclause 7.1.14: "SegementRequirement : A requirement of a segment" - really???</div><div><br></div><div>IN SUMMARY OF SUBCLAUSE 7.1: ALL descriptions (and I really mean ALL) of the requirements MUST be redone. What you provided is terse to the extreem, as if every character would cost extra. Also, from my understanding, ALL given description describe the semantic inverse. The descriptions in the current form are not acceptable, since no user would understand them correctly.</div><div><br></div><div>Subclause 7.2.4: The description misses some words to make it fluently readable.</div><div><br></div><div>Figure 4 is not readable. Please use (and provide) a SVG vector graphic.</div><div><br></div><div>Subclause 7.3.3: The description misses some words to make it fluently readable.</div><div><br></div><div>Figure 7 is not readable. Please use (and provide) a SVG vector graphic.</div><div><br></div><div>Annex B</div><div>------------</div><div>Why are specific tools mentioned here?</div><div><br></div><div>"Clean XMI File" is *not* a tool artifact, but an XMI file free of any tool-specific notations and/or extensions.</div><div><br></div><div>==> I need to do another pass through the Annex B, so expect more comments...</div></div><div><br></div><div><br></div><br>
</div>
<br></div></div></div></div></blockquote></div>