1 / 50

SmartPosition

SmartPosition. Customer Review and Feedback 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.

seamus
Download Presentation

SmartPosition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SmartPosition Customer Review and Feedback Presentation

  2. Overview

  3. 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 Presentation Overview

  4. System Boundary Diagram

  5. 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

  6. Requirements Elicitation

  7. Requirements Elicitation

  8. 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. Requirements Elicitation

  9. User Requirements

  10. Specifications

  11. Formal Analysis

  12. Analysis Process

  13. 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 Analysis Process

  14. 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

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

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

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

  18. User Acceptance Testing

  19. User Acceptance Testing

  20. 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 Features to be tested

  21. 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

  22. REPEL

  23. REPEL

  24. REPEL

  25. REPEL

  26. REPEL

  27. 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

  28. TRACK

  29. TRACK

  30. 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

  31. REPEL/TRACK

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

  33. SILENT MODE

  34. 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 on TRACKING UNIT

  35. SWITCH

  36. SWITCH

  37. 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 on MASTER UNIT

  38. DIAL

  39. DIAL

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

  41. 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 Features NOT to be tested

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

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

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

  45. Conceptual View

  46. Implementation View

  47. Candidate 1

  48. Candidate 2

  49. 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. Candidate Evaluation

  50. Build Plan

More Related