In reply to @tmallard:matrix.org
Sean, I'm clueless on how to open a ui to code diagrams, can't find bookmarks for the url to the language ref ... it looked sumple to add to, I have text galore.

Ok, java, apache, eclipse and tools are too much to get running for me right now, I knocked out a line down to "microwave" and the install list got me.

I have a draft diagram with png/jpg/pdf export options for diagrams & all text in outline as pdf for subtractive construction of the landing pad as a tree.

To repeat a point from Thursday: I really like the idea of starting with a "minimum baseline" mission that is the simplest that Coral could possibly be. Is it a stretch to encode such a thing in a ConOps? It looks like this concept exists in formal literature for Mars missions.

Applying this philosophy to the Hubble Space Telescope would result in a ConOps that states something like "well, if our pointing accuracy is degraded below point X, we can still get images of craters on the Moon. However, we need payload Y in order to get images of other galaxies".

From what I've heard at JPL, the winning proposals for a mission tend to be the ones that evoke the stronger "narrative"/"story", not just scientific prospects - as I imagine these missions serve a marketing purpose as much as they do a scientific endeavor. Then from there, the spacecraft is often over-engineered as to be able to support prospective follow-on missions, should the opportunity (i.e., funding) beyond its baseline mission were to arise.

Should we perhaps follow a similar strategy?

In reply to @drbriefs:matrix.org
However, SysML is by no means a methodology; It's a language. And like any language, you don't need to know every word, phrase, or rhetorical structure to communicate an idea, you use elements of a language that are useful however you see fit. I have, however, been reading a SysML book titled, "Architecting Spacecraft with SysML: a Model-based Systems Engineering Approach", which I'm really liking because it uses the FireSat II example from "The New SMAD" handbook. Instead of having to backtrack every week, I think it'd make more sense to utilize SMAD as our guidebook for answering the question "What should we focus on for next week's meeting?" (while incorporating SysML as the modeling language of choice). Thoughts?

In reply to @drbriefs:matrix.org
I only have the older SMAD book on me, so the table numbering may be a bit different, but I was more generally suggesting we make it a habit to check in with SMAD every once and a while, as we haven't really done so up to now. To try and answer specifically what section we should be looking at, we've been discussing conops a lot lately, so I think it might make sense to look over "Identifying alternative mission concepts", particularly "Elements of the Mission concept of operations" and "Process for defining the mission concept of operations" as a sort of checklist to see if we missed anything, use that to regain our "SE bearings", then either backtrack or move forward accordingly. Open to alternative suggestions.

In reply to @paurd:matrix.org
understood. Here's a document we can use to that end.

In reply to @udit.kumar.sahoo:matrix.org
These Tiny NASA Mistakes Had Huge Consequences
http://www.realclearlife.com/science/tiny-nasa-mistakes-huge-consequences/?utm_medium=40digest.intl.carousel&utm_source=email&utm_content&utm_campaign=campaign#1