[ ] Recommend that all sections have at least one sentence introduction.
[ ] All tables should have captions (above) and references to the tables in text.
[ ] All scenarios must have a unique ID, etc. M1, M2, M3 etc... This is important for later references to the scenarios (e.g. in testing).
[ ] M1 (first modifiability scenario): The stimulus is rather general “Wants to change the user interface”. This can mean so many different things e.g. from changing colors to revamping the whole UI. The response should also include testing (code is modified and tested). The response measure must be measurable. Now it is not, or rather it does not say anything about the modifiability. It should measure how modifiable it is!!! Also, the Artifact is very general. You should specify what part of the system being changed (the user interface module or something similar).
[ ] M2: Same problem as M1 in regard to artefact. Should also consider adding testing to Response.
[ ] M3: Would it be possible to make this change in build-time??? The response measure is useless. Also, the Artifact is too general.
[ ] U1: The artifact is wrongly described and also the Environment (this is in runtime I guess). Also, the response measure it not measurable.
[ ] U2: The artifact is wrongly described (it is not a part of the system, but rather a state of the system). The response measure is not measurable. You can e.g. state that the level of satisfaction of the user (average score 4 out of 5 on this feature) or something similar.
[ ] U3: Same issue as U2 with artifact. The response measure is ok.
[ ] Even though you are focusing only on modifiability and usability, it is ok to have more quality attribute scenarios here – but you do not need to design or implement support from them later.
[ ] There are several issues that need to be fixed in this section.
[ ] Add scalability as secondary quality attribute. Add further information required by doing this.
[ ] Recommend that all sections have at least one sentence introduction.
[ ] All tables should have captions (above) and references to the tables in text.
[ ] All scenarios must have a unique ID, etc. M1, M2, M3 etc... This is important for later references to the scenarios (e.g. in testing).
[ ] M1 (first modifiability scenario): The stimulus is rather general “Wants to change the user interface”. This can mean so many different things e.g. from changing colors to revamping the whole UI. The response should also include testing (code is modified and tested). The response measure must be measurable. Now it is not, or rather it does not say anything about the modifiability. It should measure how modifiable it is!!! Also, the Artifact is very general. You should specify what part of the system being changed (the user interface module or something similar).
[ ] M2: Same problem as M1 in regard to artefact. Should also consider adding testing to Response.
[ ] M3: Would it be possible to make this change in build-time??? The response measure is useless. Also, the Artifact is too general.
[ ] U1: The artifact is wrongly described and also the Environment (this is in runtime I guess). Also, the response measure it not measurable.
[ ] U2: The artifact is wrongly described (it is not a part of the system, but rather a state of the system). The response measure is not measurable. You can e.g. state that the level of satisfaction of the user (average score 4 out of 5 on this feature) or something similar.
[ ] U3: Same issue as U2 with artifact. The response measure is ok.
[ ] Even though you are focusing only on modifiability and usability, it is ok to have more quality attribute scenarios here – but you do not need to design or implement support from them later.
[ ] There are several issues that need to be fixed in this section.
[ ] Add scalability as secondary quality attribute. Add further information required by doing this.