-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated NFR for maintainability to refer to code, not SRS: #3288 #3735
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the feedback from @samm82, including that the word percent shouldn't be there and the percentage symbol should not be in italics. Those changes will make the change fine from the point of view of stable. How the changes are done should also be investigated. Specifically, we don't want the same Drasil code repeated.
It seems the "%" symbol is always generated between an In regards to the code duplication, I am unsure where to define the requirement so it can be accessed by various examples. Currently, it appears that requirements are defined for each example, with no place for "common" requirements. One possible module I was looking at is code/drasil-docLang/lib/Drasil/Sections/Requirements.hs which has the following description in its README:
|
The percent symbol isn't a priority. We can leave it as it is for now.
@samm82 or @balacij can likely point you to the best way to add common requirements. Much of the boilerplate in the requirements documents are shared between examples. @samm82 was working on a way to standardize common requirements, like the input and output requirements. Ideally the structure of the requirements will be the same between examples, but they will be parametrized by the percentage of time needed for the change, so that different examples can have different percentages. There really isn't a compelling reason for a specific value for any of our examples, but in general not every future maintainability requirement is going to be identical. |
|
Looking at the contents of that file, I think you've found a good spot, @BilalM04. Aside: in that file, I don't quite like how |
code/drasil-example/gamephysics/lib/Drasil/GamePhysics/Requirements.hs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly cleans up the code nicely 😄
Up to @balacij to verify that the changes he'd asked for have been done. |
Updated the NFR for maintainability to the following description:
Change applied to the following examples:
TO DO: Instead of hard-coding the "10%", it should be a parameter than can vary at the time of SRS generation.
closes #3288