Repo structure and docs

[dacb]

Two quick things... I don't see the component or functional spec in the doc directory. Also, package names in PEP8 should be lower case with one word preferred.

[FencerDave]

@dacb, thanks for pointing that out.

I added our initial Project-development timeline as an image, as well as a PDF of a User-to-Function relationship diagram we made in google's Draw.io and hopefully will keep up-to-date. (After a meeting yesterday I will be adding color and more detail to it)

Do you have any examples of the Component or Functional specs that we should have made? I was looking through the lectures and I thought you had given an example Document Spec but I can't find it.

[FencerDave]

Oh, and we'll change the repo name (probably to just eisy?) at our next Full-Group meeting, because we all have to delete and Re-download the directory when we change the name (at least I think so...)

[dacb]

No you can use git mv old new

-- David A. C. Beck, Ph.D. dacb@uw.edu http://faculty.washington.edu/dacb/ Research Associate Professor, Dept. of Chemical Engineering Director of Research & Senior Data Science Fellow - eScience Institute Adjunct Associate Professor of Paul G. Allen School of Computer Science & Engineering Adjunct Research Associate Professor, Env. and Occ. Health Sciences Associate Director - NRT Data Intensive Research Enabling Clean Technologies University of Washington, Seattle

On Mar 5, 2020, at 11:55 AM, David Hurt notifications@github.com wrote:

Oh, and we'll change the repo name (probably to just eisy?) at our next Full-Group meeting, because we all have to delete and Re-download the directory when we change the name (at least I think so...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EISy-as-Py/EISy_as_Py/issues/2?email_source=notifications&email_token=ABRPL6WQK2ZMHHHO66QEZWTRF77THA5CNFSM4LAPYDV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN6VQ3A#issuecomment-595417196, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRPL6SUI2A3EBZ6VLWGWLDRF77THANCNFSM4LAPYDVQ.

[dacb]

For the component and functional spec... The functional spec is essentially the use cases. I like to write use cases by first creating a number of "user stories" that describe the specific user types, e.g.

Alice is an experimentalist who will be using the tool to analyze her data.  She has limited programming experience but is an expert user of tools like Excel and instrumentation control software.

Then, for each user type, enumerate the specific use cases, e.g.,

* Alice will use this software to load her raw EIS data into the database.
* Alice will use raw EIS data in the database to create a Nyquist plot.
* Alice will use the user interface to select multiple Nyquist plots to show simultaneously.

I realize these might not match your software, but I just wanted to put in some examples.

For the component specification, use the use cases and things mentioned in them to create components. E.g., in the above there are two top level components that come up right away:

1. A database
2. A user interface But there are likely many more and some that are sub-components of the above. For each component, you can use the following template to create a component 'card' in the form:

   * Name
   * What it does
   * Inputs (with type information)
   * Outputs (with type information)
   * How it interacts with other components

Finally, I love how you are using the wiki. If you put this information in the wiki instead of doc that is great. Do leave a README.md in the doc directory directing folks to the wiki for the documentation.

[FencerDave]

Added Functional Spec Stories in a new docs/Project_management/ folder. (I'll make a more serious version to parallel it as needed. The snarky commentary got away from me at the end)

doc/project_management/functional_spec_stories.md