The most significant risk that could jeopardize the success of the project is differing perceptions of what our project should do. Ideally, this would not be an issue because we talked about the requirements thoroughly enough but there is always room for error. This may also manifest in different perceptions of how our different subsystems should communicate each other. For example, the LED system may expect a list of coordinates from the chess engine but the chess engine produces an index number. These integration risks will be managed through communication with the team and things like sample output files so everyone can build their own subsystems without actually having the exact communication in place. Our contingency plans for things like hardware issues or integration problems include moving to a more software based experience like having the user type into a webUI instead of voice commands and having the opponent’s moves be shown instead of told as well .
No changes have been made to the existing design.