SRS: Correct Solution

[keshavd]

I feel like your solution lends itself to another goal statement

A correct solution must be acceptable to a user experienced with EELS and/or CL data processing, as is relevant to the EELS/CL data being processed.

Is it the correct solution being described here, the visualization of the 3d spectra-microscopy created by the user?

Given that your goals are more about reading in, manipulating and exporting data, maybe this should also be an explicitly described goal?

I would definitely ask someone more familiar with preparing SRSs and software engineering principles.

I feel that the description of a correct solution isn't exactly applicable to your tool software because you made an exploratory tool that enables analysis. I don't know if it explicitly outputs a "solution" if you know what I mean.

[icbicket]

The correct solution isn't explicitly linked to the visualization of the data, rather that the results of whatever processing operations the user did should satisfy them (that the processing was done correctly, I suppose). Right now the visualization of the data is included in GS1, though I could think about splitting it up into two simpler goal statements.

I think you are right that this section doesn't really fit with the type of software I'm writing; the purpose of the software isn't to 'solve' something, but to allow the user to explore their data and do some processing operations. This could be an example of one section in the template that doesn't seem to fit with software used for analysis, @smiths . I think even the notion of the software producing a 'solution' is tied to solving equations or systems of equations, which I'm not doing. I could even remove this section entirely and I don't think I would lose much from the documentation. If the software performs well on the tests and the user is satisfied, it is 'correct', but it doesn't necessarily produce a 'solution'. What do you think, @smiths ? I can either remove this section, or leave it as is.

[smiths]

Thanks for the feedback @icbicket, and for looking for examples that fit what we discussed in class on Tuesday. I agree with you that solving something doesn't fit for every project. I agree that your program is more about exploration and analysis. However, you still have output. Characterizing a problem in terms of what output is generated from the given inputs should be a universal part of any scientific computing program. Certainly changing the wording from "Solution Characteristics Specification" to "Output Characteristics Specification," might be helpful.

From the discussion above, I'm not actually sure what section you are thinking could safely be removed. Is it the Goal Statements section, or the Solution Characteristics Specification?

[icbicket]

Sorry, I didn't intend to be so vague, @smiths . I was thinking I could take out 'Properties of a Correct Solution' from the Solution Characteristics Specification (the part @keshavd quoted). As for the Solution Characteristics Specification, I agree changing the name of it might be more general and fit more types of software in scientific computing.

For the Solution Characteristics section itself, I did find it difficult to fit my program to it (coming up with theoretical models, say, is difficult when you have a piece of experimental data that you want to describe). I do see some of the use of this section in helping to motivate the different processing operations I need to perform, and it forced me to think about where the data comes from and how to describe it mathematically. Maybe it was the examples you had for this section that made it seem difficult to apply to an analysis software (though I'm still not sure the section is a perfect fit and couldn't be modified slightly to fit analysis better, I'm not sure how at the moment). I suppose the purpose of the software isn't really to try to fit the data to a mathematical model, but only to provide processing and navigation options, which is why it didn't seem to fit well with the Solution Characteristics section.

[smiths]

Thank you for the clarification. The properties of a correct solution section is definitely one that does not fit for all projects, even ones that are more solution oriented. For instance, in the medical imaging applications I've looked at, there isn't much to add in a section like this. For Newtonian mechanics or heat transfer, there are obvious conservation laws that can be included here. The idea of the section is to capture information that might be useful in the testing or verification phases. If there isn't anything to add, it is okay to say "not applicable."

The purpose of theoretical models is to provide a level of abstraction when it is appropriate, but theoretical models aren't required either. If there isn't a refinement from abstract to concrete, you can skip directly to the instanced model. (Alternatively, this can be viewed as stopping at the theoretical model.) I noticed this when I wrote the requirements for a linear solver. There really isn't any need to refine from theory to an instance model. You can just start with the theory from the math textbook and you are done. I'm sure there is some mathematical abstraction that a linear solver is a concrete example of, but usually this kind of abstraction is going too far, since only a few mathematicians would understand it. 😄

This discussion has been very helpful. Thank you!

[icbicket]

I've modified the text in the SRS (commit c8c424d820f9fd7307df42c2616e3de39be94798) to reflect that the software doesn't really have a single correct solution to find, but is dependent on what the user wants from their data and the program.