Nonfunctional requirement(s) for maintainability should refer to the code, not the SRS

[samm82]

As mentioned by @smiths in his review of the ChemCode SRS, an NFR for maintainability should refer to code's maintainability, not the SRS's.

Currently, a common NFR for maintainability is something along the lines of "Maintainable: The traceability between requirements, assumptions, theoretical models, general definitions, data definitions, instance models, likely changes, unlikely changes, and modules is completely recorded in traceability matrices in the SRS and module guide."

This change should be implemented in:

• GamePhysics (this says "Maintainability: The development time for any of the likely changes should not exceed 10% percent of the original development time," but the value of 10% should be defined as a symbolic parameter)
• GlassBR
• NoPCM
• PDController
• Projectile
• SSP
• SWHS

[smiths]

Thanks for noticing this @samm82. I know that we have paid less attention to the NFRs in our case studies. This is an example where we let something through that isn't great. Maintainability is a difficult one to specify. My current thinking is to say something like: "If a likely change is made to the finished software it will take MAINT_FRACTION of the original development time, assuming the same development resources are available." In this MAINT_FRACTION is a symbolic constant for the fraction of the original development time. Maybe MAINT_FRACTION would be 1/10th?

This version of the NFR can be measured. I think it is reasonably unambiguous. The downside is that nobody really knows how much different technologies and processes contribute to achieving this NFR. Unfortunately I think we'll have this problem no matter how we choose to specify maintainability.

[samm82]

GamePhysics's NFR says "Maintainability: The development time for any of the likely changes should not exceed 10% percent of the original development time," which is a bit closer to what we're looking for.

[BilalM04]

@smiths @samm82 would the NFRs for maintainability be the exact same as the description below for each of the linked examples, or would they be different? If they would be different, how would they differ?

GamePhysics's NFR says "Maintainability: The development time for any of the likely changes should not exceed 10% percent of the original development time," which is a bit closer to what we're looking for.

[smiths]

@BilalM04, for all of the examples, let's say "If a likely change is made to the finished software, it will take 10% of the original development time, assuming the same development resources are available." I would prefer the 10% to be a parameter, rather than a hard-coded value. That way it could be varied for each example at the time of generation of the SRS. However, making the 10% a parameter of variation is something we can do later. Making the change presented above will improve the SRS for each example so that is a good starting point.

[BilalM04]

Fixed by #3735