edwin-do / capstoneteam30 Goto Github PK

The reviewer's capstone group TA is @tomashetMcMaster.
In the FMEA table I found the references a little hard to follow, some of the Hazards which are separate from each other go by H1-1,H1-2, etc. but the hazards which are part of the same component are labeled H2,H3,H4

Also for the Hazard for the sensors (Nanovoltmeter, temperature sensor) I think there could be a couple more potential hazards like interference/noise from external devices which would skew the results that you are getting from the sensors. I think those components can have other potentials hazards other then them just failing to read values.

Should reference who the users who fill out surveys are, if this is mentioned in other documents it should be referenced. Surveys should be more specific to remove ambiguity.

• SoftArchitect: Quality Information
  • I noticed that you referenced the SRS, but the relationship between modules and SRS was not explicitly stated. You should make a table and list out which requirements are related to each module.

1. GUI is mentioned numerous times throughout the document however, the acronym is not mentioned in the naming conventions and terminology.

2. Under the scope of the work section it is mentioned that the sample rate can be set by the user but a maximum number of samples is not clearly mentioned.

3. NFR-U2 the fit criterion for this requirement states that the time to change a parameter in the interface should take no longer than 5 seconds from when the user starts thinking about it. However this is not quantifiable since you can not accurately measure when a user thinks about something. Rather something such as the task should take 5 seconds from when the user touches the mouse would be more realistic.

4. NFR-M2 states that the product will be supported on both windows 7 and windows 10 however under section 4.4-Tasks it only includes a task of compatibility for windows 7.

5. 2.1.1 context diagram can be expanded to include the event path of a user accessing the program remotely since the scope of the work mentions having remote accessibility as a goal of the project

6. Section 4.6-Risks mentions that the computers in the lab don’t require a network connection. Has the group thought about how to incorporate a remote access functionality to the program when a network connection is not available? Furthermore, if the network connection is actually available but just unused, will setting up that connection create supportability issues with the operating systems of the lab computers?

7. NFR-P4 - Given the measurements are read accurately to 3 decimal places (according to NFR-P3), if there are complex calculations regarding these measurements you might lose more than 1 digit of accuracy. Might not be able to logically prove the accuracy of final results if the display is only accurate to 2 decimal places.

FR-T4 and FR-T2 can be condensed into one test. verification of output and functionality for the same input condition

Try to separate the rationale from the requirements for example, in SFR1, you can have the requirement as 'Graphics shall avoid changing brightness at a rapid rate' and the rationale would be 'To avoid increasing the risk of seizures'

• SoftArchitect: Quality Information
  • As a first-time reader, a component diagram would make it easier to understand the relationships between the modules. A diagram that shows how data is transferred between modules would make it very clear.

The reviewer's capstone group TA is @tomashetMcMaster.
In the FMEA table, component "Serial Connection", the effects of failure for this component can be clearer why this effect is considered a failure to the user.

I think that "Data cannot be communicated to App" only describes a failure in the systems functionality. I think you could consider saying something along the lines of "User will miss changes in the sample during a test" as an example of highlighting how the user would experiences serial communication failure.

Software Architecture: MG
You showcase a traceability matrix to highlight which requirements are fulfilled by which modules, but it is unclear to a first-time reader what those requirements are. Consider adding a hyperlink/reference to your SRS when these requirements are referenced.

Look into what safety precautions we need to have so that we can inform Dr.Zurob before using the equipment

For the software validation plan, you might want to figure out a more specific margin of error. What is considered reasonable when looking at the referenced materials with known results?

The reviewer's capstone group TA is @tomashetMcMaster.
Your critical assumptions are clear but do not really have that much information regarding them, I would try add a little more detail or even explain why these assumptions are being made. Even possibly give examples of failures that these critical assumptions help avoid.

• SystDesDoc: Timeline
  • There is no detailed timeline displaying testing/verification plans in order to complete the implementation of Rev 0.

The reviewer's capstone group TA is @tomashetMcMaster.
In the FMEA table, components such as Current Source, Nanovoltmeter, Temperature Sensor as examples, have the vague recommended action bullet point "Troubleshoot current source setup".

I think that "Troubleshoot current source setup" seems vague because the user does not necessarily know how to act on the failure after reading the recommended action. A possible consideration for hardware related troubleshooting that has a more specific action item could be "User verifies the current hardware connections between devices matches schematic".

The survey for NF-CT1 should be larger. Document references survey but eludes to only one user performing the survey, this survey should be performed with a larger sample size to enforce the validity of results.

6.1: Unit Testing Scope
6.2: Tests for Functional Requirements
--> 6.2.1: Tests for Module 1
--> 6.2.2: Tests for Module 2

• SoftArchitect: Quality Information
  • The Module Hierarchy displays the behavior-hiding modules. However, the secrets of each module aren’t explicitly stated.

Content issues:
-MIS and MG were used in the document but not referred to in the acronym table nor had their name defined.
-Notes are still present in the document. these should be removed.
-list of figures was included in the document but was empty, it should have been removed if not needed per note.
-Formatting of NF-UT1 and NF-UT2 should be fixed, labels are not clear/missing.
-No reflection present in the document.
-Unit testing section should be removed from the document.

Write introduction for hazard analysis

• SoftArchitect: Quality Information
  • There are no likely/unlikely changes stated for each module.

Recognize_Limitations LO_ProbSolutions:

I noticed that the reflection appendix was empty. It would be good to reflect on the limitations of your solution, this can be done by thinking about:

1. Why did you choose this solution compared to the other solutions you thought of previously?
2. If you were given unlimited resources, how would you make this project better?