SmartPosition Customer Review and Feedback Presentation

Formt Introduction ◦Sections  4 minutes presentation  2 minutes questions ◦15 minutes questions

Overview The SmartPosition System An aid to improve the outcomes of soccer teams.

Presentation Overview What you will see in today’s presentation ◦System overview (System Boundary Diagram) ◦The requirements Elicitation Process ◦User requirements ◦Specification ◦Formal Analysis ◦Testing ◦System Architecture ◦Questions

System Boundary Diagram

Requirements Elicitation A “Meeting of the Minds” What is the purpose? What did we achieve? An agreement on the system specifications free from undocumented assumptions.

Requirements Elicitation The First Question - Pressman states The first question an engineer asks the client should be context free and focus on the customer and other stakeholders.

Requirements Elicitation Formal Requirements Specification Informal Requirements Raw Requirements Broad Requirements

Requirements Elicitation Through this elicitation process we found that the customer was always happy to broaden the scope of the solution and often avoided agreeing on specifics.

Analysis Process

Each stage of the analysis process allowed the project team to identify all aspects of the system that formed a requirement The formal listing of requirement statements are being used by the system architects to produce both high and low level designs Any changes to the requirements will result in a formal review of the SRS

User Requirements Use several slides to outline the user requirements Group requirements in logical categories, using one slide per category Use one slide per requirement group, if appropriate

User Requirements The user requirement analysis was taken out in a procedural manner considering the three major steps namely: 1) Eliciting requirements 2) Stakeholder identification 3) Stakeholder interviews These points can further be elaborated in the report.

User Requirements Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases,user stories, or process specifications. Eliciting requirements: the task of communicating with the customer or the user to determine what the requirements are.

User Requirements Determining Raw requirements: Raw Requirements were written down line by line from the specification that was given to us. In the second step every statement of the raw requirement was cross referenced to check if it fits the 6 characteristics analysis. To support the analysis a section for actions to be taken is provided to leave feedbacks or arguments that is to be discussed with the client or the stakeholder.

User Requirements 6 characteristics required to fulfill the raw requirements to proceed for informal analysis. 1) Cohesive 2) consistency 3) completeness 4) feasible 5) unambiguous 6) verifiable

User Requirements Architectural and critical requirements: Critical requirements: They are the requirements without which the other systems and the requirements would cease to work or synchronize. Some of the critical requirements are stated below:

User Requirements Each player tracking device shall operate at all times in one of four modes of operation: "TRACK", "REPEL", "TRACK/REPEL" and "OFF" If a player tracking device cannot establish communication with the main unit after 60 seconds it will enter a standby state The main unit shall store the last 60 minutes of tracking data In "REPEL" mode the minimum configurable range between the player tracking devices shall be 3 meters. All battery powered devices shall run for greater than 300 minutes before needing to be recharged The iPad application shall provide a warning to the user when the persistent data storage reaches 90% of its capacity

Specifications For products, give relevant technical specifications, using as many slides as necessary For services, detail the items and conditions under which the service is offered

Formal Analysis Discuss how the product was analyzed, what was found during the analysis process? Class Diagram Sequence Diagram Use Case

Formal Analysis Diagrams System interaction ◦The communication and collaboration between objects within the system ◦Identifies domain classes, attributes and responsibilities of the system objects Sequence Diagrams ◦Communication and interaction between objects ◦Time sequence behavior Activity Diagrams ◦Model workflow ◦State behavior of system

System Setup 3 Sub Systems ◦Main Unit ◦Player Tracking Device ◦iPad application Initial system synchronisation sequence Communications between sub systems identified

View Tracking Data Communication between sub systems ◦Position data pushed to main unit ◦iPad application GUI refresh Timing of data calls between sub systems

Repelling of Players Sub system states identified Sub system domain classes and functions identified Workflow needed for a device to alarm

User Acceptance Testing Detail the product testing techniques used at the user acceptance level. Describe what will be tested, what will not be tested and why.

User Acceptance Testing Detail the product testing techniques used at the user acceptance level. Describe what will be tested, what will not be tested and why.

Features to be tested Features which to be tested are typical features of the systems. They are taken from requirement analysis Will represent for a complete working system. Will also ensure the quality of the system

REPEL Purpose: is used to train players to spread out on the field and not clump together. Action: as defined in requirement analysis, if two tracking units come into the range of a tracking unit, they will start beeping.

REPEL

REPEL

REPEL

REPEL

REPEL

TRACK Purpose: reporting twice every second which other units come into the range of a tracking unit. Action: Each tracking unit is reporting to the main unit twice every second.

TRACK

TRACK

REPEL/TRACK Purpose: a combination of REPEL and TRACK modes Action: ◦If two tracking units come into the range of a tracking unit, they will start beeping. ◦Each tracking unit is reporting to the main unit twice every second.

REPEL/TRACK

SILENT MODE Purpose: avoid any impacts on players in a real soccer game. Action: ◦Each tracking unit shall not start beeping in any scenarios.

SILENT MODE

SWITCH on TRACKING UNIT Purpose: to allow players to turn on/off their tracking units. Action: ◦Turn off: device is off and no LED. ◦Turn on: each tracking unit shall:  Go to sleep if the master unit is off.  Be active if the master unit is on.

SWITCH

SWITCH

DIAL on MASTER UNIT Purpose: to allow the coach to switch between modes on the master units. Action: ◦Able to put it in Repel mode ◦Able to put it in TRACK mode ◦Able to put it in REPEL/TRACK mode ◦Able to turn it off

DIAL

DIAL

Other features to be tested Battery evaluation Configurable range Interference Waterproof Stability

Features NOT to be tested Size and weight Internal system activities ◦For example: the system shall improve positional play for soccer teams External system activities ◦For example: the system shall be designed so as to enable mass production of the design

Architecture Description of the system architecture. (use as many slides as you think necessary)

Stakeholder Analysis Player - User Coach - User Project Owner - SportQuick CEO Project Liaison - SportQuick Project Sponsor Development Team - Red Team Regulatory Department - Health and Safety

System Qualities After analysing the stakeholders and non- functional requirements the following have appeared identified as the most important system qualities Availability Usability Modifiability Testability

Conceptual View

Implementation View

Candidate 1

Candidate 2

Candidate Evaluation Each criterion is given a score from 1 to 5. The candidate with the most points, is selected and candidate with the least points is the fall back option.

Build Plan List availability dates Describe how the team intends to build the product. Give a timeline etc.