Drasil: Traceability Issues in Projectile

[samm82]

From the matrices, I've noticed the following:
1) DD: vecMag doesn't reference anything
2) TM: acceleration and TM: velocity don't reference anything
3) FR: Input-Parameters and FR: Verify-Parameters don't reference anything
4) None of the (placeholder) NFRs reference anything
5) A: neglectDrag, A: freeFlight, and A: neglectCurv are all referenced, but don't show up as such in the table

• Assumptions being referenced by assumptions is the issue here
  6) GD: velVec isn't referenced
  7) None of the FRs or NFRs are referenced

What should be the line of action here? Who should be looking at this?

Above, 1 and 2 I think are OK, since they are the base-level chunks. I don't think we should worry about the NFRs right now. 5 is a more general issue that I took a look at and didn't get anywhere. 3, 4, and 6 are specific to Projectile, and potentially the FRs from 7.

[Mornix]

1. Is a "known" issue related to #1023.

[smiths]

Thank you @samm82. Nice to see that the number of empty rows and columns is low.

I'll edit in my thoughts on your list below.

1) DD: vecMag doesn't reference anything
I agree that this fine. The DD is referenced, but it doesn't reference other things. As you said, this is because it is a base level chunk.
2) TM: acceleration and TM: velocity don't reference anything
Again, this is fine because these are the TMs that are refined. They are used by other things, but they don't tend to need supporting information. If a TM needed to reference a DD that would be fine, but it isn't necessary.
3) FR: Input-Parameters and FR: Verify-Parameters don't reference anything
The input parameters can be deduced from the IMs, but I don't think we should do this (at least not now). The FR: Verify-Parameters references a section, so it does reference something, but I don't think we should expand our list of items in the traceability matrix. I think our FRs do implicitly reference the preceding material, since the list of inputs and the data constraints are implicitly already listed. However, I don't think we are ready to make this a rule, since the information isn't in a "referenceable" form.
4) None of the (placeholder) NFRs reference anything
I agree that this is fine. The NFRs probably don't have to reference other things, even when they are moved from not being placeholders.
5) A: neglectDrag, A: freeFlight, and A: neglectCurv are all referenced, but don't show up as such in the table
As @Mornix mentioned, this is a known issue.
6) GD: velVec isn't referenced
Now this is interesting! We found something valuable. Although this GD makes sense in general (it is a natural refinement from 1D to 2D for GD: rectVel), it isn't actually necessary for this example. We don't use it to do anything. I think we should delete this GD from Projectile. We should keep the knowledge in Drasil, but we don't actually need it for this example. We would need it if we added the properties of a correct solution rule that the magnitude of the velocity (speed) is the same at the beginning and end of the flight (for conservation of kinetic energy). This is an another example for @szymczdm. I wouldn't have noticed that we didn't need this GD if it wasn't for the traceability matrix.
7) None of the FRs or NFRs are referenced
I think it is fine if FRs and NFRs are not referenced. They are the ultimate output of this document. They are used by the design and the code, but not internally to the SRS.

[samm82]

I created the GDs and TMs specifically in the Projectile example. Should I pull them out to Data.Drasil, and then not use the GD in question in Projectile? @smiths

[smiths]

Yes, I think that makes sense. The GDs aren't actually specific to Projectile. In another problem where we are dealing with kinematic motion, under the same assumptions, we'll need that GD again. I definitely don't want to delete the information. It could be very useful, but for this particular version of Projectile, it is unnecessary. The traceability matrix clearly shows that it isn't used for anything.

When we start thinking about family members based on requirement variabilities, we could create a version of Projectile that outputs the velocity components. This would require keeping this GD for that example.

[samm82]

This will be a big change, so I think we might want to wait until the branch gets merged in first? Also, @smiths, what should go with the TMs and GDs when they get moved. The assumptions that they reference would also need to be moved; should anything else be pulled for future reuse?

[smiths]

Yes, we should wait for the branch to be merged. From my point of view all of the GDs are not Projectile specific, but I don't want us re-organizing things until @JacquesCarette has had a chance to review Projectile. We can pick up this conversation once he has some time to look things over. For now, leave the GD for the velocity vector in Projectile, but keep this issue open.

[JacquesCarette]

@samm82 @smiths Should there be an issue directing me to review Projectile? [I just want to make sure that it is indeed time for me to do so.]

[samm82]

I don't think there are any issues that are Projectile-specific, so I think it's just a matter of who's reviewing it first, which I think is up to @smiths.

[smiths]

@JacquesCarette, yes, I am done reviewing Projectile. @samm82, please create an issue for @JacquesCarette to review Projectile.

[smiths]

As described above (https://github.com/JacquesCarette/Drasil/issues/1628#issuecomment-506475593), most of the absent traceability entries is not a problem. For the 5th entry in the list, a new issue was created (#2185). Entry 6 in the list is no longer relevant, because the example has been improved so that the GD is used.

This issue can now be closed.