I'm not sure if these were left in for me or just by mistake. p6, p7, p17

TODO

Any point that requires more discussion should be pulled out to a different issue; I grouped these all here since they are related and small.

• In the intro, it should be "...the system tests that will be conducted are described...."

Image Import and Export

• The bulleted list of file types should be explained/introduced in the text.
• For the Initial State of your tests, I would be more specific: "ImgBeamer loaded and idle."
• For the Test Case Derivation of T1, it should be "Theses are some...."
• Make sure you do quotation marks properly in LaTeX: ``text''.

Spot Profile and Imaging Parameters

• There should be a comma after "which".
• "To satisfy R4..." should only have the "T" capitalized.
• What is the difference between "loaded and idle" and "running and idle"? You should pick one for consistency.
• In the Input of T3, "height" shouldn't be capitalized.
• What does relative mean here? Is it a typo? "Width and Height as positive real numbers relative."
• There are grammar issues in the Output of T3: "The spot layout should reflect these changes and display an updated arrangement with the given shape. The resulting image should exhibit expected effects as documented by the SRS figures [4]."
  • Make sure to update this in all relevant spots!

Image Quality Metric

• It should be "To satisfy R7, the user should be able...."
• There shouldn't be a comma after "truth".
• The Output for T9 should be "A number that is...."

Hi Dr. Smith!

Here is my first version of my ProblemStatement.pdf. 😬

I've made my current code public here: https://github.com/joedf/ImgBeamer
I will likely have to improve or re-implement some parts, but I was thinking of adding it as a submodule to this repository instead of copying it over. This way I can preserve the commit history and branches I have on there. Would that be okay?

For example, saying that the output is "the completed user surveys" isn't really helpful. These tests can be written more as a walkthrough of what will be done.

Make sure to reference all relevant documentation, including the ones that haven't been written yet (like the MG and MIS)!

The introductory paragraph of your introduction is a bit wordy, at least the first sentence. Is there any chance you could rephrase some of it or add some pictures to quickly demonstrate what you mean to the reader?

Do you think you could expand your introduction a bit more?

This is used in many modules, I do not think you need to be so specific as to mention pointers. Maybe a more general statement like "Provides functionality to update the drawing/image upon request"?

Maybe can add some explanation in assumptions parts to lead readers to DD parts, since some assumptions kind of hard to fully understand before reading Data definition part.

TODO

• When used as an adjective, "easy-to-understand" has hyphens.
• I don't understand the last sentence of this section; consider rewriting it for clarity.

Since your project work involves pictures, I think examples might help get your point across further in some areas when describing the quality of the images, and perhaps even the mathematics.

This idea is not very important, I think your images are great as is, but a few more might help people like me who don't know what pictures from an electron microscope look like. “good” and “bad” pictures in particular.

Your revision history should be more detailed (ideally it should group your git commits into meaningful "chunks"). (Also it looks like you left in the default second row!)
Side note: your commit messages should be more description than "progress on vnv" - what progress was made? Summarize it!

Similarly to #31, some tests are too vague. Some examples of details to think about:

• What are the specific inputs to these tests? T7 and T8 give a range of possible values, and T2 allows for one to not even be provided! You should pick specific values/images for these tests or outline the procedure for obtaining them. If necessary, create multiple tests for multiple inputs!
• Similarly, how will these tests be performed? T3 allow for the test to be performed "by scrolling in the visual spot shape UI or by number input in the GUI."
• Ideally, you would provide the exact images that would be passed to the program for testing. If that is not possible at this stage, at least more specific information about how images should be transformed should be given:
  • In T5, how should "the resulting image resolution ... grow or shrink according to the pixel size given"?
  • In T7-9, what does "somewhat sharp" or "somewhat blurry" mean?
• How many warnings does "little to no warnings" mean in T12? How much setup is "little to no setup" in T14? Does this setup include installation?

Since you're dealing with images in your program, I think it's fairly reasonable that you would have some “implementation-level” details in your SRS (since how else would you discuss images?). However, I think you might want to address it a bit since you're discussing the “quality” of the images in your case study. Specifically, you might want to address:

• what is the importance of the size?
• how does the input image encodings relate to your mathematics?
• how will you represent the images internally in your program once they've been read in? (Since I imagine how you represent the images will affect the math involved with your instance models?)

Assuming these are important, you might also need to tie them back to your instance models, or perhaps add them as system constraints.

Hello Dr. Smith!

Not sure if I did this right. I made some corrections with the suggestions from class. I struggled with the traceability among other things, but I'm sure I'll learn and understand later on.

SRS.pdf

Hopefully, I didn't forget or miss anything.

As per the title, you described the general process in the description box, but do you think you could also explain it in mathematical terms?

MIS

12.4.2 Environment Variables
The graphics processing hardware.

Does your program know this? Isn't it covered under hardware hiding?

This is a very minor nitpick.

When acronyms are written, we usually see them as “The Thing We're Referring To (TTWR),” but you've commonly used “TTWR (The Thing We're Referring To)” but also used the former. It might be good to make sure it's consistent throughout the document.

The only one I remember being the former is in the introductory paragraph where you mentioned SEM.

11.4.2 Environment Variables
The HIDs (e.g., mouse, keyboard) and the screen.

Lacks specificity. Are the variables that the devices exist? That they are connected? Or are the variable generated by the devices (such as mouse pointer position, button state, etc)?

AC12: The implementation of graphical user interface.

What do you mean by "implementation" here? Like it would look the same but be programmed in a different language? Or be rendered using a different library? Or do you mean changes to the requirements of the GUI (display different things, etc)? "Implementation" is very vague.

Are there any qualitative and/or quantitative metrics that users should think about when checking if images are better/worse quality after processing? If so, do you think you could mention some? Right now, the idea of an “optimal spot-to-pixel-size ratio” is a bit difficult to understand.

I am not sure if this will be a problem, it just my professor from other before told us it better not put Wikipedia as reference.

This is very unimportant, and I think it might be something of an issue in regard to describing a GUI focused mode of entry (i.e., is it configurable?).

In particular, the verification plans for the design and verification and validation plan are vague. Who will be reviewing the design once it is complete? What kind of review will it undergo if published in a journal? What does it mean to "reveal any risks"? How will the VnV team members review the VnV Plan? What will the final vetting process entail?

p2

AC10: The implementation of rendering, compositing, clipping, or blending operations (e.g., “Bit BLT”).

BLT is not in acronyms.

AC7: How the overall control of the calculations are orchestrated.

Unclear sentence.

AC8: The display of information on the visualizations and resulting images.

Unclear sentence.

p3

UC6: The software must be able to display a live visualization to the user of the effects of changing the imaging parameters

Run on sentence

I like this. I think the table might be cutting into the right page margin.

p6

Secrets: The algorithm for coordinating the running of the program.

Awkward sentence.

Secrets: The format, structure, verification of the input ground truth image data.

Missing "and".

Secrets: The format and current values of the input imaging parameters (number of rows and columns for the rasterization grid and magnification) data.
Services: Gets and provides the parameters values.

Are the values a secret if they are provided to other modules?

p 10

Secrets: The number of drawing stages / canvases and the references to them, the update and redraw events, drawing rates, and the connection to rendering (M20).

I think this is overly specific again. What about "The images currently displayed and the display information associated/required with/for each one (drawing rate, etc)"?

Services: Initializes the drawing stages, provides methods to manipulate them and to attach events, manages the image rendering and drawing, and holds and manages the update function references for each drawing stage.

Overly specific? This could be shorter "Initalizes and manages the display." maybe "initalizes and manages the display objects. Is reponsible for image rendering, image updating, etc).

Secrets: The HTML DOM Manipulation; CSS rules; user interaction event handling; user input controls, states, and data formats (such as text-boxes, buttons, file dialogs); along with the layout, styles, colors, and sizing.

I'm not sure if we're supposed to be that specific with the languages (imo it's fine though). I don't know if those semicolons are gramatically correct.

Services: Sets up a visual interface for the user to see and interact with, handles user and GUI control events, updates the visual elements representing the state of the application, and sends messages back to the application control (M2) to update the application state accordingly.

This one is nice.

p 11

Secrets: The algorithm, criteria, and validations for processing and comparing two images.

"validations" to "validation algorithm/calculation"?

Services: Compares two images (ideally one - a reference or ground truth image, and the other - an image to compare to) and produces a score on the similarity or quality of the compared image with respect to reference image.

I would rewrite as: "(ideally, one should be a reference or ground truth image and the other should be ...)"

• I was a bit surprised when I saw IM2, I didn't expect that there would be a numeric metric. Do you think you could make it more prominent in the earlier parts?
• It also seems to be missing an output symbol.
• Finally, do you think you can add a mathematical description of it?

It just makes searching the table easier.

• fix spot content definition
• fix wording in Spot profile definition
• missing word "it" in "under-sampling in another can create"

TODO

Any point that requires more discussion should be pulled out to a different issue; I grouped these all here since they are related and small.

• It should be "The following tests...."
• There should be commas here: "...the nonfunctional requirements, as defined in the SRS [4], are met."
• There is an extra space where a comma should be in the third sentence (after "ImgBeamer").
• For consistency, "portability" shouldn't be capitalized.

Both of them are ratios/relative metrics of other data.

TODO

Any point that requires more discussion should be pulled out to a different issue; I grouped these all here since they are related and small.

SRS Verification Plan

• I would say that "The SRS document will be reviewed..." since this document is the plan for your verification, assuming that it hasn't happened already.
• Remove the first "or" in this sentence: "Most of the feedback has been provided as issues on GitHub, or as annotated documents, or by verbal exchange."
• This sentence should be rewritten: "The author is then expected make the resolve the issues and makes accordingly throughout the development of the project."
• In the last sentence, there is only one objective listed, so it should be "The key objective is to...."
  • On my first read, it seemed like "sound" was going to be a verb until I got past it. While the above fix would help, I would also switch the order of "sound" and "coherent" to help mitigate this.

Design Verification Plan

• It should be "Decisions are made...."
  • If these decisions were part of the conceptualization process, then it should be past tense for consistency (i.e., "Decisions were made...).
• There shouldn't be spaces in "MG/MIS".
  • I would put the references beside the document names themselves to be 100% clear (i.e., "MG [1]/MIS [2]").
• There should be commas in this sentence: "The VnV team, as well as any volunteers users, are welcome to...."

Implementation Verification Plan

• I would get rid of the "any"s in the second sentence.
• References to sections should be capitalized (e.g., "Section 4.6.")

Automated Testing and Verification Tools

• As a verb, "unit test" doesn't have a hyphen.

UC1: Input/Output devices (Input: File and/or Keyboard, Output: File, Memory, and/or Screen).

Thinks seems like a strange unlikely change for your software? It seems like the software could run on a laptop or a tablet (which doesn't have a keyboard).

This ranges from a university undergraduate science student in which their curriculum includes electron microscopy (EM),

The length or distance of a ”pixel” by which the probe is moved or deflected to when raster scanning the surface of a sample

This section provides the assumptions, instance models, theoretical models, general definitions, and the data constraints.

p8

7.4.5 Local Functions
doUpdate(), updateInfoDisplay(), and doExport() as described above.

Functions aren't local if they can be accessed by other modules. These should probably be included as exported access programs.

p13
For 10.2 Uses, maybe just use bullet points instead of numbered points (as there doesn't seem to be an order).

p14

10.4.2 Environment Variables
Display/Canvas controls as provided by the GUI Module (M18).

I'm not sure about this, if another module is providing a variable then is it an environment variable here? Would it just be listed in that module?

p25

Mouse events handled by Konva for shape node-editing / “transformers”.

Maybe just say "None" if you aren't writing any.

p28

drawSpotSignal (M??)

Secrets: The display and drawing stage to represent the ground truth image and subregion bounds.

Secrets: The display and drawing stage to represent the subregion.

I see this a lot and I'm not sure what you mean by it. Should it be "stages that represent"? Could this not be simpler like "How the drawing of the ... is generated/updated/constructed/calculated"?

The last sentence of the Implementation Verification Plan says "As a control for the image metrics, they will be calculated using the same image as the ground truth reference to rule out any baseline or unexpected factors in the implementations themselves." I am confused as to what this means: what is the "ground truth reference?" What does it mean to "rule out any baseline ... factors"?

For examples in MIS of Image Rendering

Types are not defined for gridLayer, layer, rect, rows or probe

Hi Dr. Smith,

This was a tough one. Here's goes for my best attempt 😅

• MG.pdf
• MIS.pdf

Cheers!

I might have misunderstood, but could this be mentioned as an input constraint mathematically?

@KarenKarenWang @LesleyWheat

Hi there,
I got an extension to complete my MG/MIS for this Sunday night. Hopefully, I should be done sooner or later...

Hello @smiths !

I have done what I can for the VnV plan. I've spent the better part of a day on this. 😅
VnVPlan.pdf

Again, I don't think I fully understood everything, but I shall learn and "fake it" as we say. 😉
Looking forward to your feedback.

TODO

Any point that requires more discussion should be pulled out to a different issue; I grouped these all here since they are related and small.

• The paragraph starting with "This document..." should be under the General Information heading.
• "ImgBeamer" by itself (as opposed to "the ImgBeamer software" or "the ImgBeamer program") shouldn't have "the" before it.
• The phrase "scanning electron microscope image formation" in parentheses seems like it is a definition of ImgBeamer, but it doesn't look like a definition to me.
• Referring to the "Software Requirements Specification (SRS) document" is redundant - you don't need to say "document".
• Since testing hasn't occurred yet, it should say "Testing of ... its components will be conducted...."
• "Ultimately" should have commas around it (i.e., "...and, ultimately, whether...").
• It should be "...whether it meets the requirements from the SRS."

This is very minor: the UCs list uses the same prefix and numbering of the LCs.

Using the standard double quotation marks in LaTeX ends up forming the right-sided quotation glyphs. To use the appropriate left and right quotation marks, you should use:

``two backticks to start, and two single quotes to end.''

If you want to use single quotes, then you just replace the above with single characters on both ends.

In R2, R3 and R4 you don't mention user input validation but in M3, you mention validation. However, for M4 and M5 there is no mention of validation. There might be a reason for this but it looks odd to me.

The wording of the first sentence is a bit ambiguous as to what you're 'specifying' (though, we obviously know). I think you're specifying the "requirements" of the software, not necessarily the software itself (which might allude to the design of the software).

I think it better to put sampling figure before goal statement.

Can GD2 be described mathematically? As of right now, I'm not quite sure what it is for.