SmartPosition Customer Review and Feedback Presentation.

Slides:



Advertisements
Similar presentations
Project Analysis Course ( ) Final Project Report Overview.
Advertisements

Convene Planning Workshop with Key Stakeholders to Develop TMM Educate Stakeholders Select Exercise Planning Team from Stakeholders Conduct Facilitator.
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
OASIS Reference Model for Service Oriented Architecture 1.0
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
Requirements Elicitation Chapter 4. Establishing Requirements Two questions –What is the purpose of the system –What is inside and what is outside the.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
© Lethbridge/Laganière 2001 Chapter 7: Focusing on Users and Their Tasks1 7.1 User Centred Design (UCD) Software development should focus on the needs.
Trade Study Training Need and Goals Need Consistent methodologies and practices performing trade studies Pros/cons, advantages/disadvantages, customer/management.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
S R S S ystem R equirements S pecification Specifying the Specifications.
Lecture 3 Strategic Planning for IT Projects (Chapter 7)
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with material from: IEEE Standard, Daniel Amyot.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
1 European Conference on Training Strategies Kieran Cox -NSAI Education & Promotion-
Web Development Process Description
S/W Project Management
RUP Requirements RUP Artifacts and Deliverables
Project Analysis Course ( ) Week 2 Activities.
Object Oriented Analysis By: Don Villanueva CS 524 Software Engineering I Fall I 2007 – Sheldon X. Liang, Ph. D.
Project Analysis Course ( ) Final Project Report Overview Prepared by: Sijali Petro Korojelo (Course Assistant)
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Use Case modelling 1. Objectives  Document user requirements with a model  Describe the purpose of an actor and a use case  Construct a use case model.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Software Requirements Engineering CSE 305 Lecture-2.
Mobile Aps: Agile Mentoring Review
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Lecture 7: Requirements Engineering
For accurate communication, since a project can have several participants, each from different background. Represent a given aspect of the system We will.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Final Status Report Sonali PagadeNibha Dhagat David Ziman Reginald Bradshaw II Sebastian Schagerer Janet Xu Phan Marvel Electronics & Home Entertainment.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Requirement Handling
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
CT1404 Lecture 2 Requirement Engineering 1 1. Today's Lecture Definition of a Software Requirement Definition of Software Requirements Management Characteristics.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Mechanical Desktop Design Process Key Concepts in this Lesson: The design process Part modeling Overview This lesson explains the designer process, and.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Prof. Hany H. Ammar, CSEE, WVU, and
Requirement Engineering
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Software Engineering Lecture 10: System Engineering.
SmartPosition Customer Review and Feedback Presentation.
Documenting Software Architectures. Outline  Introduction  Uses of Architectural Documentation  Views  Choosing the Relevant Views  Documenting a.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
System Development Life Cycle (SDLC). Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project.
 System Requirement Specification and System Planning.
Requirements Engineering
System Requirements Specification
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
Lecture # 7 System Requirements
TITLE Business Case YOUR LOGO BUSINESS CASE PRESENTATION 00/00/0000
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

SmartPosition Customer Review and Feedback Presentation

Format of Presentation Introduction Major 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

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