SmartPositionCustomer Review and Feedback Presentation

Format of Presentation

IntroductionMajor sections of the project

◦Each section will be presented for 4 minutes

◦Followed by 2 minutes of discussion

Finally 15 Minutes of Questions

Presentation Overview

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

Overview

The SmartPosition

System

An aid to improve the outcomes of

soccer teams.

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, focused on the customer and other stakeholders.

Requirements Elicitation

Formal Requirements Specification

Informal Requirements

Raw Requirements

Concept

Inception

Analysis Process

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

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 analysisWill 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 evaluationConfigurable rangeInterferenceWaterproofStability

Features NOT to be tested

Size and weightInternal 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 - UserCoach - UserProject Owner - SportQuick CEOProject Liaison - SportQuick Project

SponsorDevelopment Team - Red TeamRegulatory 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

AvailabilityUsabilityModifiabilityTestability

Conceptual View

Implementation View

Candidate 1

Candidate 2

Candidate Evaluation

Available Modifiable Testable Usable Performance Hardware Software TotalLayer 3 3 3 3 2 5 4 23MVC 3 5 3 5 5 1 5 27

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 datesDescribe how the team

intends to build the product. Give a timeline etc.