Redundancy in "Input Variables Table" and "Input Data Table"

[njericha]

The SRS documents have both of these tables and they say very similar things. Input Variables Table is under Data Constraints and has the list of inputs, constraints, and typical values. Input Data Table is under Functional Requirements and lists the inputs, units, and description (similar to the table of symbols). Is there a reasoning for having two separate tables? In SSP both tables list the same inputs. If there is a reason, the naming of these tables should be more descriptive.

[JacquesCarette]

I believe that both tables should use the same list (of variables) as input - that part of the redundancy should definitely be unified.

However, those two tables really have different audiences, and serve different purposes. I completely agree that the naming needs to be made more precise.

[smiths]

I agree with @JacquesCarette. There should be two tables. One of the great things about Drasil is that we can reuse our knowledge in different contexts to provide different views of the information. Since we do not have to manually create the table each time, the work load is reduced, and maintenance problems are removed.

As far as naming goes, I think the tables should be linked to the type of information they provide. What about "Data Constraints Table" and "Required Inputs Table"?

[njericha]

@smiths @JacquesCarette we were discussing some issues with these tables and feel it might make more sense to have the following tables. This would help with #310

Table 1: Input Data Constraints

• Variables
• Physical Constraints
• Software Constraints

Table 2: Output Data Constraints

• Variables
• Physical Constraints
• Software Constraints

Table 3: Required Inputs

• Variables
• Typical Uncertainty
• Typical Value

Table 4: Generated Outputs

• Variables
• Typical Uncertainty
• Typical Value

[smiths]

@njericha , for displaying the data, I am fine with your suggestions. Given the amount of data, I could see there being formatting issues that splitting the information across tables would help with.

If your question is related to the Drasil side of things (rather than the generated document), you need to make sure that you aren't repeating the same information in more than one place.

[JacquesCarette]

I think today's meeting should help clarify this?

[smiths]

@njericha , can you post your new plan based on our discussion? I'd like to make sure that we are all on the same page.

[njericha]

I would be nice to generate only the needed columns (if there are no software constraints then that column would not be generated) but for now we would generate all columns.

Proposed tables:

Data Constraints

Table 1: Input Data Constraints

• Input Variable Symbol
• Physical Constraints
• Software Constraints
• Typical Input Value
• Typical Input Uncertainty (if applicable)

Table 2: Output Data Constraints

• Output Variable Symbol
• Physical Constraints
• Software Constraints
• Typical Output Value (if possible)

Requirements

Table 3: Required Inputs

• Variable Symbol
• Unit
• Name

[smiths]

@njericha , your proposed table names and the content of those tables sounds great, with a few exceptions:

• For Table 1 (Input Data Constraints), I think you mean Typical Input Uncertainty (if applicable)
• The Typical Output Value is a good addition. I like that you have (if possible), but there will be cases where the user will know what value they expect. It is good to capture this information when it is available
• I don't think we need the Typical Output Uncertainty entry. I cannot really think of a case where this information would be available. The output uncertainty could be estimated by numerical experiments, or error propagation analysis, but I just don't see this happening as part of the requirements

[njericha]

Updated the list. We will need #315 to help capture the knowledge together and with the correct fields. By the look of the table, it would seem that output data needs to be a different type than input since they won't have uncertainties.

[njericha]

The only thing left to do would be to intelligently include or skip columns if not needed which is left to #310