Skip to content

Latest commit

 

History

History
75 lines (52 loc) · 3.3 KB

projectCharter.md

File metadata and controls

75 lines (52 loc) · 3.3 KB
Raw

Project Charter

Created by: Quentin CLÉMENT
Creation Date: 15/03/2024
Last update: 15/03/2024

Table of Contents

1. Project Overview

This document aims to align the vision of the client and the team. The goal of the project is to improve and optimise the SportShield prototype developed by Coris Innovation.

2. Project Scope

2.1 Scope

Several improvements have been identified by the client. Because of the short period dedicated to this project, the team decided to focus on the following points:

  1. Increase the battery autonomy as well as its lifespan
  2. Implement NFC detection
  3. Optimise movement detection to make it less sensible but still efficient
  4. Change the alarm system to prevent false alarms and use it to alert the user of low-battery
  5. Add LEDs for battery level (nice to have)

2.2 Out of Scope

During the first week, we managed to make every module of the hardware work except the GPRS. We assume that identifying the problem and fixing it will take too much time compared to its importance.
That's why we decided to put it out of scope for this project.

3. Project Deliverables

We want to completely refurbish the code provided at the beginning of the project. We feel that its process could be optimised, and we want to comment as much as possible on our code to make it easier to understand and maintain.

4. Project Schedule

The project will be rythmed by deadlines fixed by the client and the school. The milestones for the project are the following:

  • 18/03/2024: Functional Specifications delivery
  • 30/03/2024: Minimal Viable Product delivery
  • 11/04/2024: Final Product delivery

5. Budget

The budget for this project is limited to the material provided at the beginning of the project. Nevertheless, for some features such as the LED we might need a small budget to buy the necessary components. We will discuss this with the customer when the time comes.

6. Risks

  • Time: We only have 5 weeks to complete the project, and might run out of time if we encounter too many problems.
    In this case, we will prioritise the tasks according to the order defined in scope.
  • Problem with the provided hardware: We might encounter problems with the hardware that we won't be able to fix.
    In this case, we will have to find a workaround or change the scope of the project to use the time we have left to work on another feature.
  • Hardware breakdown: We could break the hardware while working on it.
    In this case, we will try to borrow the device of another team.

7. Conclusion

This document should be approved by us the team, the client, and the school to all move in the same direction.
If some of the parties disagree with some points of this document, we will have to discuss it by mail and make the necessary changes to make sure that everyone is aligned.