License: MIT License
Developer Names:
Robert Zhu
Zifan Meng
Fred Zhu
Mirza Nafi Hasan
Jiahui Chen
Kelvin Huynh
Date of project start: September 19th 2022
This project is ...
The folders and files for this project are as follows:
docs - Documentation for the project
refs - Reference material used for the project, including papers
src - Source code
test - Test cases
etc.
The rubric mentioned that the requirements should be verifiable. Some of the requirements stated in the SRS do not have a clear way to verify. For example, MLFR6 - The program should be calibrated to match the speed of the signer. How do we verify that the program is properly calibrated? A recommendation is to add a fit criterion to the requirements that describe how it would be verified.
According to marking rubric, the requirements are not traceable. Functional requirements and Non-functional requirements are supposed to be connected in terms of their dependency. A table, diagram or a matrix need to be given to mark all correlations. For example, If NFR1 depends on CFR1, it has to be marked in the table.
The functional requirement (MLFR7), "The ML model should be easily trainable", does not have any system behaviors that are related to the user interactions. Based on the rationale, the "easily trainable" is a software quality and could be listed under usability and maintainability requirements, which the developers can easily update corrections and upload new features easily.
Maybe we can have a more specific non-functional requirements. For example, ease of use can be divided into the system must provide short and clear guidance to user or the interface must be simple.
Hi, overall really good document but one thing I came across was in Section 9: Code Coverage Metrics. The writing in the section is good but the coverage report itself is difficult to read, which is the primary purpose of this section. Figures 9 and 10 are very small and I had to zoom in a lot to read them. Taking into consideration that many people have worse eyesight than me, this could be an issue.
A simple yet effective fix would be to enlarge Figures 9 and 10, or alternatively to summarize the information in a LaTeX table.
Also, if the same information is given in Figures 9 and 10, they might not both be necessary but this is more of a nitpick so don't worry about it.
The Hazard Analysis has provided requirements for the sample data and the machine learning(ML) model being used by the project to mitigate the hazards. But the requirement for the chosen ML model could be ambiguous when trying to build test case(s) for it. It would be better if training error and/or test error that the chosen ML model should achieve on the sample data is given in the requirement instead of just the word "properly".
The usability test in the VnV plan includes obtaining the ease of understanding rating from the users on a scale from 1 to 10. The VnV report includes a more general test without any quantitative metrics. It would be beneficial to record some of these values (time spent understanding instructions and a rating for the ease of use) from users for a more complete test.
Namit Chopra
400196353
choprn9
Hey guys, I noticed a couple of your modules, such as the text to speech module and hardware hiding module(though you arent implementing that one so eh), seem to have non atomic secrets, with secrets that look like "dataset AND algorithm for x".
Naturally you are more familiar with the context of your own system, but it might be worth thinking about keeping your modules as atomic as you can. This feels especially true considering you seem to be looking at many potential future upgrades, as very atomic modules could make your program more modular and easier to change in the future. Even if in the implementation phase you end up grouping a couple of trivial modules together, having the fully decomposed version in a design document can be a nice reference.
Good luck with Revision 0! I know our team is going to have a ton of fun over the next couple weeks...
The listed requirement (ER1) in Section 7.2 Environment Requirement is more like a requirement for the user (to ensure adequate lighting for the camera). It could be better if turn it into a requirement for the system.
You should probably describe what the local functions in M2,3,5,6 are (i.e. their function signature, and what they are supposed to do).
It is unclear which template is used, SRS did not reference the template, and sections added to the template are not identified.
In the capstone rubric, it states: "System tests cover all of the requirements with enough redundancy to build confidence in the product if the tests all pass; traceability between requirements and test cases is clearly documented.". The system tests do not cover all the requirements to build confidence in the product because there is no test for the non-functional requirement "NFR5". Also, the traceability between requirements and test cases are not clearly documented in the traceability matrix. The test case ID and requirement ID in the traceability matrix are the same when they shouldn't be. For example: test id TC-NFR5 covers requirement id TC-NFR5 in the traceability matrix, but in reality it covers NFR7.
For the mentioned tests, many of the 'initial states' refer to the initial state of some external factor rather than the initial state of the system. For example, many tests mention that the "user is working with the ASL translator', or that the 'camera is placed in front of the user'. Rather than making a comment about these external factors, tests should identify the state of the system at the start of each test.
In addition to the existing test cases, some edge cases to test the system in different with respect to the hardware testing section would be nice. i.e How would the system behave given the camera disconnects midway of translation (or momentarily disconnects at different points when providing a long series of hand gestures)? Can the system handle poor quality webcams (i.e what is the minimum spec camera that the system can behave accordingly)? What is the best quality of the webcam the system handle (In terms of processing a high definition video stream) given that the program is running off a Raspberry Pi ?
Andrew Balmakund
400182420
balmakua
When writing system tests for functional and non-functional requirements, there must be at least one functional or non-functional requirement that each test is testing. Having the test, TC-CFR2, without linking it to any specific requirement in the SRS, implies that such a test should not be listed as a functional test of the system you are building. Either a new functional requirement should be created to justify the inclusion of TC-CFR2, or TC-CFR2 should be removed as a functional test of the system.
String Display was mentioned in some of the test cases. It is not made entirely clear what this means. There is no reference in the VnV plan regarding this. Perhaps define this in the abbreviations section. Otherwise, it looks really good!
Mohammad Harun
400196424
harunm1
Update SRS to mention ML model in the place of database for documentation consistency
In the Reference section, IEEE format reference related to this document should be put. If no reference is used in this document, the empty section of reference is not necessary.
The VnV document is missing specific plans for Continuous Integration (CI), or an explanation as to why CI is not being done.
More requirements can be added to avoid unsafe or unacceptable situations , more unsafe behavior can also be added to the requirement
The Hazard Analysis has provided detailed recommended action(s) for different aspects of harware failures. However, the recommended actions given are more about what the user should do when failure is observed while the actions should be more related to what the system itself should react when a failure is detected and how the system will detect the failures. For example, when the Raspberry Pi board cannot function due to the board is not powered, the recommended actions could be "require the device to give an indication to tell the user that the board is not powered when it is detected"
Many modules in MIS (sections 7, 8, 9, 10, 12, 14) are written with exported constants taking inputs and having outputs. Should these be exported access programs?
The team does a good job outline new safety requirements and acknowledging due to constraints it may not be possible to account for all requirements. However, it may be beneficial to have an idea of what requirements does the team believe may not be implemented in the Roadmap section.
If the system cannot read a sign during translation because it doesn't know what it is, would it be the right move to show an error or to just ignore the sign? I think this could slow down the process enough to where a user would get frustrated and not use the system. You could also mention how the system would deal with incorrect classification (i.e. mistaking one sign for another causing an incorrect translation).
In Section 6.2 Failure Modes and Effects Analysis Table, the effects of camera hardware failure appear to be missing from the FMEA table. Adding the effects would make the table more complete (if possible).
In the Software Validation Plan, black box and white box testing was mentioned. Testing is a verification technique, not a validation technique. This section should involve talking to stakeholders, supervisor, etc.
Had a bit of a hard time understanding the purpose and the design of each module in the MIS without taking a peek at the MG. For starters, many of the exported constants seemed as an exported access program to me. Also State variables and Assumptions had been left empty across all modules which even though is completely fine, they could be used to provide further technical understanding into the modules. The formalization could also be used to detail more complex aspects of the machine learning modules or just the portions that will be altered by the team.
Cool idea and great reflection on how the VnV report finished differently than what was in the VnV plan. I think it would be beneficial to add/devise actual steps/methods the team could follow to improve future VnV plannning
Simple prototypes of the user interface can be a great tool for communicating ideas with your stakeholders and users. It allows them to give much better feedback. Also, to me a great product is best built by first thinking about the use cases, the users, and designing around a problem.
Cool idea btw!
@samm82
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.