Top Banner
Software Requirements Specification Document Exceed Doctor Software System Version: 2.0 Date: May 29, 2014
36
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: SRS

Software Requirements Specification Document

Exceed Doctor Software System

Version: 2.0 Date: May 29, 2014

Page 2: SRS

Document History and Distribution

1. Revision History

Revision # Revision Date Description of Change Author 1.0 March 05, 2014 Preliminary draft Dmitry Kotleev 1.1 April 8, 2014 R&D review Michael Sidorenko 1.2 April 23, 2014 Sales & Marketing review Nir Danai 2.0 May 29, 2014 Final draft Vladimir Lucenko

2. Distribution

Recipient Name Recipient Organization Distribution Method Dave Graver Great Lakes Orthodontics, Ltd. Email

Page 3: SRS

Software Requirements Specification

05/14/15 18:07 PM 1f

Table of Contents

1. Introduction 4

1.1. Purpose 4

1.2. Scope 4

1.3. Definitions, Acronyms, and Abbreviations 5

1.4. References 6

1.5. Overview 6

2. General Description 7

2.1. Product Perspective 7

2.2. Product Functions 8

2.3. User Characteristics 9

2.4. Constraints 9

2.5. Assumptions and Dependencies 10

3. Specific Requirements 10

3.1. External Interface Requirements 10 3.1.1. User Interfaces 10 3.1.2. System Interfaces 10 3.1.3. Hardware Interfaces 10 3.1.4. Software Interfaces 11 3.1.5. Communications Interfaces 11

3.2. Functional Requirements 11 3.2.1. Internet and Data Exchange Server Connectivity 11 3.2.2. System Updating 11 3.2.3. Authorization 12 3.2.4. Processing Orders 12

3.2.4.1. Order Types 12 3.2.4.2. Order Contents 12 3.2.4.3. Order Lifecycle 12 3.2.4.4. Working with Orders' Lists 13

Page 4: SRS

Software Requirements Specification

05/14/15 18:07 PM 2f

3.2.4.5. Opening an Order 13 3.2.4.6. Closing an Order 14 3.2.4.7. Local Storage of Orders 14

3.2.4.7.1. Opening Cases from the Hard Drive 14 3.2.4.7.2. Saving Cases to the Hard Drive 14

3.2.4.8. Server Storage Requirements 15 3.2.4.9. Downloading Cases from Server 15 3.2.4.10. Uploading Changes to Server 16

3.2.5. Positioning Brackets 16 3.2.5.1. General Requirements for Working with 3D Models, Placement Plans and Placement Plans Modifications 16 3.2.5.2. Modes of Operation with the Placement of Brackets 17 3.2.5.3. Visualization of the 3D Model and the Placement Plan 17

3.2.5.3.1. General requirements for the visualization of three-dimensional scenes 17 3.2.5.3.2. Visualization Models, Plans and Modifications of the Model 18 3.2.5.3.3. Displaying 3D Scenes 18 3.2.5.3.4. Visualization of Arches 19 3.2.5.3.5. Visualization of Teeth 19 3.2.5.3.6. Visualization of Brackets 19 3.2.5.3.7. Visualization of Wires 20 3.2.5.3.8. Visualization of Occlusogram 20 3.2.5.3.9. Visualization of Teeth and Brackets Animation 21

3.2.5.4. Selection of Elements in 3D Scenes 21 3.2.5.4.1. Tooth selection 22 3.2.5.4.2. Bracket selection 22 3.2.5.4.3. Wire selection 23

3.2.5.5. Tools for Visual Analysis for Recommended Bracket Positioning 23 3.2.5.5.1. Heat Map Distances between Brackets and Teeth 23 3.2.5.5.2. Displaying Bracket Positioning Relative to the Tooth 23 3.2.5.5.3. Displaying Bracket Information 23 3.2.5.5.4. Displaying Tooth Information 23 3.2.5.5.5. Displaying Information about the Movement of a Particular Tooth 24 3.2.5.5.6. Displaying Information on Teeth Movement 24

3.2.5.6. Measuring Tools 25 3.2.5.6.1. Measuring Teeth Width 25 3.2.5.6.2. Measuring Arch Length 25

Page 5: SRS

Software Requirements Specification

05/14/15 18:07 PM 3f

3.2.5.6.3. Measuring Arch Width 25 3.2.5.6.4. Measuring Cross Section 27

3.2.5.7. Editing Bracket Positions 27 3.2.5.7.1. General Functionality Requirements for Editing Positions 27 3.2.5.7.2. Modifying Bracket Position When Working With a Rx Placement Plan 28 3.2.5.7.3. Modifying Bracket Positions When Working with a Tx Placement Plan 29 3.2.5.7.4. Modifying Teeth Positions When Working with a Tx Placement Plan 29 3.2.5.7.5. Modifying Wire Position When Working with a Tx Placement Plan 30

3.2.5.8. Approval /Rejection of a Placement Plan or Placement Plan Modification 31 3.2.6. Additional Information to the User 31 3.2.7. Localization 31

3.3. Logical Database Requirements 32

3.4. Design Constraints 33

3.5. Software System Attributes 33 3.5.1. Performance 33 3.5.2. Reliability 33 3.5.3. Availability 33 3.5.4. Security 34 3.5.5. Maintainability 34 3.5.6. Portability 34

Page 6: SRS

Software Requirements Specification

4f

1. Introduction

This section introduces the requirement specification document for the Exceed Doctor Software system. It provides the purpose and scope of the system. Any definitions and references are listed in this section as well as an overview of the remaining requirements specification document.

1.1. Purpose

This requirements specification document gives the detailed description of both functional and nonfunctional requirements for the Exceed Doctor Software system. The document has been developed after a number of consultations with the applicant and considering the complete requirement specifications of the given project. The final product of the team will be meeting the requirements of this document.

1.2. Scope

The Exceed Doctor Software system (hereinafter - EDS) is part of the eXceed® service for the production of orthodontic bracketing trays. The system allows the treating clinician to examine and amend a proposed plan for placing brackets on a computerized 3D-model of the patient's teeth. The initial placement plan is generated by a separate software and is therefore beyond the scope of this system. The objective of the EDS is to provide the tools needed to assess the quality of the proposed plan and when necessary, have it adjusted. The end result of the doctor using the EDS is one of the following three options:

i. Approving the proposed placement plan, thereby allowing fabrication of bracketing trays based on that plan;

ii. Adjusting the proposed placement plan and approving the adjusted plan, thereby allowing fabrication of bracketing trays, based on the adjusted plan.

iii. Rejecting the proposed placement plan and communicating the necessary revisions, allowing the Exceed Center to generate a revised plan.

Bracket placement planning through the use of three-dimensional modeling, instead of direct, manual cementing carries the following advantages:

• Reducing the duration of the initial bonding appointment;

• Reducing the number of mid-course bracketing corrections (bracket repositioning)

• Increasing treatment predictability due to fewer corrections.

Page 7: SRS

Software Requirements Specification

5f

1.3. Definitions, Acronyms, and Abbreviations

Bracket/s (appliance/s)

Small objects, typically made of metal, ceramic or composite, that are cemented onto the teeth to be used as anchorage points for the wires, as part of an orthodontic correction.

3D Model (model) 3D computer replica of the patient's teeth, produced by digitizing dental casts or impressions of the patient's mouth or by direct, intra-oral scanning. Refers to a specific order.

Data Exchange Server

A computer used to store data about Orders and information exchange between EDS, DPO (see below) and the Exceed Center. The Data Exchange Server is part of Exceed Software System.

DPO Doctor's Personal Office - a web application allowing to upload patient records, submit, manage and track Orders. The DPO is part of Exceed Software System.

ECS Exceed Center Software System - the software used by Exceed Center employees to generate Rx and Tx Placement Plans. The ECS is part of Exceed Software System.

EDS Exceed Doctor Software System - the software used by the treating clinician to analyze, modify and approve Rx and Tx Placement Plans. The EDS is part of the Exceed Software System.

ES Exceed Software System - System formation, registration procurement and fulfillment of Orders for the production of bracketing trays

Exceed Center An office where employees are using the ECS to generate Rx and Tx Placement Plans.

Order/s (Case/s) Request for a virtual bracket placement plan and the subsequent production of bracketing trays. Each request is linked to a 3D-model of the patient's dentition.

Placement Modification/s (Modification/s)

Dr.-adjusted modification of the Placement Plan. Refers to a specific order. Each Placement Plan can be modified a few times.

Placement Plan/s (Plan/s)

Layout of the brackets positioned on the patient's teeth, originally prepared by the Exceed Center. Refers to a specific order.

Page 8: SRS

Software Requirements Specification

6f

Rx Case Order of the Rx service

Rx Plan/s Mathematical calculation displaying the recommended positioning of Brackets on the patient's teeth, based on the pre-treatment 3D Model, the type of orthodontic brackets utilized, and the clinician's general pre-treatment bracketing preferences.

Rx Service Production of bracketing trays based on the Doctor-approved Rx Plan.

Scene 3D virtual space displaying the 3D Model, as well as the Placement Plans.

Tx Case/s Order of a Tx service

Tx Plan/s A mathematical calculation of the recommended positioning of Brackets on the patient's malocclusion, based on dynamic tooth movement from the pre-treatment malocclusion to a desired post-treatment outcome. It is based on the pre-treatment 3D Model, the type of Brackets utilized, the treatment plan prescribed by the clinician, the clinician's general post-treatment preferences, as well as intra-oral images, facial photos and panoramic radiographs of the patient.

Tx Service Production of bracketing trays based on the doctor-approved Tx Plan.

Wire/s Ligament, typically made of metal or smart alloys that are attached to orthodontic brackets and are used to apply forces on the teeth, as part of an orthodontic correction.

1.4. References

IEEE Std. 830-1993: IEEE Recommended Practice for Software Requirements Specifications.

1.5. Overview

The rest of the document contains an overall description of the EDS (section 2), and the specific requirements for the system (section 3).

Page 9: SRS

Software Requirements Specification

7f

2. General Description

This section is used to provide a high-level description of the system.

2.1. Product Perspective

The Exceed Doctor Software System (EDS) is part of the Exceed Software System (ES), intended for the formation, registration, procurement and fulfillment of Orders for the production of bracketing rays. ES components are depicted below.

Clinics Exceed Center

Data Exchange Server

Exceed Doctor Software System

Doctor’s Personal Office

Exceed Center Software System

Figure 1 – Exceed Software System block diagram

Participants are dental offices (clinics), placing Orders, and the Exceed Center, which oversees the process.

The Clinics will utilize the DPO and the EDS:

Doctor's Personal Office (DPO) – is a web application allowing clinicians to upload patient records, submit, manage and track Orders. Depending on the type of service requested, uploaded records may include the pre-treatment 3D Model, the type of brackets utilized, the treatment plan prescribed by the clinician, as well as intra-oral images, facial photos and panoramic radiographs of the patient.

Page 10: SRS

Software Requirements Specification

8f

Exceed Doctor Software System (EDS) is a desktop-application providing clinicians the tools needed to analyze, modify and approve Rx and Tx Placement Plans proposed by the Exceed Center.

The Exceed Center will utilize the ECS:

Exceed Center Software System (ECS), providing tools for generating Rx and Tx Placement Plans, based on inputs received through the DPO.

Since this is a data-centric service, data storage is necessary. For that, the Data Exchange Server will be utilized. All the components will communicate with the Data Exchange Server. All of the Data Exchange Server communication will be conducted over the Internet.

System components operate with data organized in accordance with the data model ES. Description of the data model is given in Section 3.3. Requirements for EDS contained herein. Requirements for other ES components are beyond the scope of this document.

2.2. Product Functions

Orders are divided into two types based on the type of the service requested - eXceed Rx or Tx. The method for calculating the recommended position of the brackets on the teeth also differs based on the type of service. Each type of order involves its own set of functions:

Rx Plan – Mathematical calculation displaying the recommended positioning of Brackets on the patient's teeth, based on the pre-treatment 3D Model, the type of orthodontic brackets utilized, and the clinician's general pre-treatment bracketing preferences. Based on those preferences: one of the three possible placement methods is selected: FA (Andrews) Method, MBT (McLaughlin, Bennett, Trevissi) Method and the Pitts Method. All three methods have been formulated in the past by orthodontic scholars and published in peer-reviewed literature.

When working with plans prepared under this scheme, clinicians have to assess the proposed positioning. In case there are any necessary revisions, clinicians may correct the Placement Plan themselves or send revision request to the Exceed Center asking for an adjusted Rx Plan.

Orders for the Rx Service are called Rx-cases.

Tx Plan - mathematical calculation of the recommended positioning of Brackets on the patient's malocclusion, based on dynamic tooth movement from the pre-treatment malocclusion to a desired post-treatment outcome. It is based on the pre-treatment 3D Model, the type of brackets utilized, the treatment plan prescribed by the clinician, the clinician's general post-treatment preferences, as well as intra-oral images, facial photos and panoramic radiographs of the patient.

The Tx plan provides the clinician with more opportunities and treatment planning options, taking into account the individual dental and facial characteristics of the patient.

Page 11: SRS

Software Requirements Specification

9f

When working with plans prepared under this scheme, the doctor examines the final position of the teeth on the simulated post-treatment outcome, and the placement of the brackets relative to the teeth. In case there are any necessary revisions, clinicians may correct the Placement Plan themselves or send revision request to the Exceed Center asking for an adjusted Tx Plan.

Orders for the Tx Service are called Tx-cases.

The end result of using each of the two services is the calculation of the recommended bracket position and, pending clinician's' approval, the manufacturing of bracketing trays.

The Rx and Tx Services are independent.

2.3. User Characteristics

Users expected to use the EDS could come from two groups – certified orthodontists, who specialize in the treatment of orthodontic irregularities and general dentists, who provide all kinds of dental services, including orthodontic care. Users must therefore possess dental academic education as a minimum, be able to evaluate the quality of the proposed Placement Plans and when necessary, perform or ask for adjustments.

2.4. Constraints

2.4.1. The system should not allow the user performing any actions until all necessary prior steps have been completed.

2.4.2. The EDS should be developed using the C ++ programming language.

2.4.3. The EDS should operate on at least the WINDOWS Operating System. Using EDS on other platforms is expected through virtualization/WINDOWS emulation programs (for example, Parallels for MAC OS).

2.4.4. The exchange of data with the Data Exchange Server must run over TCP.

2.4.5. Software Requirements:

System requires WINDOWS 7 or MAC OS 10 or greater.

For use on Mac OS, Parallels version 7 or higher must be installed.

DirectX9 or greater should be installed.

2.4.6. Hardware Requirements:

A dedicated video card supporting DirectX 9 and Pixel Shaders 3.0 or higher.

Page 12: SRS

Software Requirements Specification

10f

2.5. Assumptions and Dependencies

One underlying assumption about the EDS is that it will always be used on computers with sufficient specifications. If the computer does not have enough hardware resources available for the application, there may be scenarios where the application may not work as intended or even at all.

3. Specific Requirements

This section contains all of the functional and quality requirements of the system. It gives a detailed description of the system and its features.

3.1. External Interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also gives a description of the hardware, software and communication interfaces and provides basic user interface requirements.

3.1.1. User Interfaces

3.1.1.1. The Graphical User Interface (GUI) of the system should be as easy to use and as intuitive as possible.

3.1.1.2. The elements of the GUI should be hidden when not required by the user.

3.1.1.3. The system must display prompts regarding important functions and events.

3.1.1.4. System prompts can be disabled by the user, as well as being able to view the display prompts.

3.1.2. System Interfaces

The EDS does not provide interfaces to other external systems.

3.1.3. Hardware Interfaces

3.1.3.1. EDS must be able to run on a personal computer.

3.1.3.2. To fully benefit from the three-dimensional functions of EDS, a 3-button mouse is recommended.

Page 13: SRS

Software Requirements Specification

11f

3.1.4. Software Interfaces

3.1.4.1. The interaction between the program and the video card must be carried out by API DirectX 9 or higher.

3.1.4.2. Simultaneous imaging pixels showing the 3D Model and the Placement Plan should be carried out with the help of Pixel Shaders 3.0 or higher.

3.1.4.3. Work with project files should be made with the appropriate operating system API.

3.1.5. Communications Interfaces

3.1.5.1. Exchange data with Data Exchange Server should be carried out by TCP.

3.2. Functional Requirements

This section includes the requirements that specify all the fundamental actions of the software system.

3.2.1. Internet and Data Exchange Server Connectivity

3.2.1.1. The system must perform Internet connection availability check at startup.

3.2.1.2. The system should display connection status to the Internet at all times.

3.2.1.3. The system should not allow the user to update the system, authorize, and perform actions that are only available to authorized users without an active connection to the Internet (see 3.2.3). The remaining functions of the system must be available at any state of connection to the Internet, active or inactive.

3.2.1.4. Users should be able to define parameters for connecting to the proxy server, if used.

3.2.2. System Updating

3.2.2.1. Each time the system is started, connection should be established with the Data Exchange Server to check for system updates.

3.2.2.2. Each time there is a change in Internet connection status, the system should connect to the Data Exchange Server and check for system updates.

3.2.2.3. If there is an update available, the system should prompt the user to download and install the update.

Page 14: SRS

Software Requirements Specification

12f

3.2.2.4. The user should be able to decline the prompt to download and install the update and instead, continue to work with the current version.

3.2.2.5. With the consent of the user to upgrade, the system must implement and install the update.

3.2.3. Authorization

3.2.3.1. The system should allow users to log in.

3.2.3.2. Only authorized users should be able to: a) view current list of Orders on the Data Exchange Server; b) downloading Orders from the server: c) approve Placement Plans and sending them back for revisions. Unauthorized users should be deprived of these features.

3.2.3.3. The system should not allow the user to authorize without an active Internet connection (see 3.2.1).

3.2.3.4. For authorized users, the system should display the name of the user account.

3.2.3.5. The system should allow the user to sign out and subsequently log in using a different account.

3.2.4. Processing Orders

3.2.4.1. Order Types

3.2.4.1.1. The system must perform the work with two types of orders: Rx Orders and Tx orders (see 2.2).

3.2.4.1.2. The system should be able to handle normal and demo orders, the latter type is designed to allow novice or unregistered users a quick preview into the system's capabilities.

3.2.4.2. Order Contents

3.2.4.2.1. The system shall operate on the contents of the order in accordance with the data model described in 3.3.

3.2.4.3. Order Lifecycle

3.2.4.3.1. The system must distinguish between the following order statuses:

The 3D model and the Placement Plans proposed by the Exceed Center;

Page 15: SRS

Software Requirements Specification

13f

Orders requiring attention from the user - orders which include new or revised Placement Plans, followed by approval or a revision request

Placement Plans Modifications performed by the user;

Placement Plans revision requests communicated to the Exceed Center.

3.2.4.1.2. When the 3D model and the Placement Plan are in the process of preparation by the Exceed Center, the Order should not be available for download from the server.

3.2.4.1.3. Orders requiring the attention of the user should be available to download from the server for the purpose of Placement Plan Modification, Placement Plan approval or Placement Plan revision request.

3.2.4.4. Working with Orders' Lists

3.2.4.4.1. The user should be able to view the list of Orders or Cases.

3.2.4.4.2. The user should be able to view the lists of Orders as a general list, as well as sorted out by patients.

3.2.4.4.3. Viewing Orders' list should be available to the user regardless of the status of the Internet connection and user's authorization. An authorized user should view a list of its current Orders available on the server. An unauthorized user should view a list of Orders that occurred when accessing the list during the last system startup.

3.2.4.4.4. The user should be able to view a separate list of Orders requiring attention: approval or sending back for revision. The list should accommodate Orders for which the Exceed Center has prepared new or revised Placement Plans.

3.2.4.4.5. The user should be able to view a separate list of recently opened Orders.

3.2.4.4.6. The user should be able to view a separate list of demo cases.

3.2.4.5. Opening an Order

3.2.4.5.1. The user should be able to open an Order from within the list of available Orders.

3.2.4.5.2. At any time, the system should open no more than one Order.

3.2.4.5.3. Unauthorized users should only be allowed the possibility of opening locally stored Orders (about local storage, see 3.2.4.7). Authorized users should be allowed the possibility of opening locally stored Orders as well as loading Orders from the Data Exchange Server (see 3.2.4.8).

3.2.4.5.4. Unauthorized users at the opening of the order should open the Order from the hard drive (see 3.2.4.7.1).

Page 16: SRS

Software Requirements Specification

14f

3.2.4.5.5. Authorized users at the opening of the order (except for demo cases) should be checked for changes in order data on the server. If there are changes, data should be loaded from the server (see 3.2.4.8.1). In the absence of changes detected, data should open Orders from the hard drive (see 3.2.4.7.1).

3.2.4.5.6. When opening a demo Order, the Order should be loaded from the hard disk (see 3.2.4.7.1).

3.2.4.5.7. To successfully open an Order, all Order contents must be rendered, with the ability of working with the virtual placement of brackets (see Section 3.2.5).

3.2.4.6. Closing an Order

3.2.4.6.1. At any time during the viewing of the Order, the user should have the opportunity to close the order.

3.2.4.6.2. Prior to closing the Order and in the presence of unsaved changes, the system should provide an alert on the situation and request confirmation of the need to complete the work without saving changes.

3.2.4.7. Local Storage of Orders

3.2.4.7.1. Each time Order data is reloaded from the server, the order must be maintained locally (see 3.2.4.8.1).

3.2.4.7.2. All demo cases must be stored locally.

3.2.4.7.3. Locally saved Orders must be able to open for both authorized and unauthorized users (see the authorization. 3.2.3).

3.2.4.7.4. The user should be able to adjust the path to the directory for local storage of Orders.

3.2.4.7.1. Opening Cases from the Hard Drive

3.2.4.7.1.1. When trying to open a local Order copy that is not stored locally, the system should display an appropriate message.

3.2.4.7.2. Saving Cases to the Hard Drive

3.2.4.7.2.1. When working with the contents of the Order (see Section 3.2.5), user should have the opportunity, at all times, to locally save all changes made.

Page 17: SRS

Software Requirements Specification

15f

3.2.4.8. Server Storage Requirements

3.2.4.8.1. Communication with Data Exchange Server should be available to authorized users only (see 3.2.3).

3.2.4.8.2. The system should not allow users to communicate with the Data Exchange Server without an active Internet connection (see 3.2.1).

3.2.4.8.3. The amount of data transferred between the Data Exchange Server and EDS, should be minimized: sender must only transmit data that is missing from the recipient (new Placement Plans, Placement Plans Modifications, new data on the positioning of brackets, new types of bracket data etc.).

3.2.4.8.4. Local changes in Orders without uploading to a server should lead to out of sync data between the server and the EDS Order. Data transfer between the server and EDS should lead to data synchronization upon request.

3.2.4.8.5. Indicator of synchronization between the server and EDS should be set separately for each 3D model, Placement Plan and Placement Plan modification. It is a valid situation where some 3D models, Placement Plans, Placement Plans modifications, are synchronized, and some are not.

3.2.4.8.6. The user should see the synchronization status indicator for each 3D model, Placement Plan and Placement Plan modification.

3.2.4.8.7. Exchange of data with the server when demo cases are concerned should not take place.

3.2.4.9. Downloading Cases from Server

3.2.4.9.1 Loading data on request from the server must be carried out only if the data are available on the server (for example, a new Placement Plan, on the local storage of Orders see Section 3.2.4.7).

3.2.4.9.2. If the Order is not stored locally, upon loading, the system must load order data completely. If a local copy of the Order exists, the system should proceed by creating a local copy of the new data received from the server (to make data integration).

3.2.4.9.3. A successful loading from the server is completed when the Order or Order update are maintained locally over a local copy of the previous Order.

3.2.4.9.4. A successful loading from the server to the loaded 3D models, Placement plans and Placement Plan Modifications must display a synchronization sign.

3.2.4.9.5. When downloading from the server has been unsuccessful, the system should display an appropriate message, including an inactive status of the Internet connection.

Page 18: SRS

Software Requirements Specification

16f

3.2.4.10. Uploading Changes to Server

3.2.4.10.1. Uploading data to the server should be done in case a Placement Plan has been approved, sent back for revisions, or self-modified (see 3.2.5.8).

3.2.4.10.2. Prior to loading, the server should have local data storage order (see 3.2.4.7).

3.2.4.10.3. Following a successful upload to the server of the downloaded models, a synchronization sign must be displayed.

3.2.4.10.4. When downloading to the server system has been unsuccessful, an appropriate message should be displayed, including an inactive status of the Internet connection.

3.2.5. Positioning Brackets

3.2.5.1. General Requirements for Working with 3D Models, Placement Plans and Placement Plans Modifications

3.2.5.1.1. Using the 3D Model and the Placement Plans must be available to the user only after opening the Order.

3.2.5.1.2. The Order must maintain information about each 3D model, Placement Plan and Placement Plan Modifications. Deleting data entities when dealing with orders at the EDS should not be available.

3.2.5.1.3. Upon selecting an Order, all associated 3D models, Placement Plans and Placement Plan Modifications, including names and numbers shall be displayed (see 3.3).

3.2.5.1.4. Within the Order, the user should be able to select one or more of the 3D models, Placement Plans and/or Placement Plans Modifications and visually compare them.

3.2.5.1.5. When working with an Order, the user must be able to make modifications only with the aim of ultimately approving the Placement Plan in question, or any modifications thereof. When working with a demo Order, the user should be able to make a modification in any way.

3.2.5.1.6. The user should not be able to modify the 3D Model.

3.2.5.1.7. A Placement Plan Modification should be created automatically every time a user attempts to edit a Plan requiring approval (see also 3.2.5.7.1).

3.2.5.1.8. The user must be able to clearly indicate the need to revise a Placement Plan.

3.2.5.1.9. Only a Placement Plan proposed by the Exceed Center can be modified. The user will not be able to modify an already modified Placement Plan.

Page 19: SRS

Software Requirements Specification

17f

3.2.5.2. Modes of Operation with the Placement of Brackets

3.2.5.2.1. Working with placement of brackets can be conducted in one of two modes:

"Edit" mode - the user only edits the Placement Plan;

"Animation" mode - the user only views an animated visualization of moving teeth and brackets from pre- to post-treatment.

3.2.5.2.2. When working with Rx Placement Plan, the system should operate only on "Edit" mode.

3.2.5.2.3. When working with Tx Placement Plan, the system will allow the user to switch between "Edit" and "Animation" modes.

3.2.5.3. Visualization of the 3D Model and the Placement Plan

3.2.5.3.1. General requirements for the visualization of three-dimensional scenes

3.2.5.3.1.1. When working with Rx Placement Plan, "Edit" mode, changes should show the position of brackets on the patient's teeth in the 3D Model, pre-treatment.

3.2.5.3.1.2. When working with Tx Placement Plan, "Edit" mode, changes should show the position of brackets on the patient's teeth in the 3D model, post-treatment.

3.2.5.3.1.3. When working with Tx-plan, "Edit" mode, the user should be able to see the position of the teeth and the brackets on the 3D model, pre- as well as post-treatment.

3.2.5.3.1.4. The system should have the ability to display multiple 3D Scenes for simultaneous viewing of user-selected 3D models, Placement Plans and Placement Plans Modifications. To display a 3D Scene, each system must have a separate rectangular area of the screen.

3.2.5.3.1.5. For each 3D scene, the system must clearly establish the appropriate 3D Model that defines the shape of the jaws and teeth as well as:

When the visualization model should be built on the basis of this model;

When the Placement Plan should be based on the visualization model associated with the said Placement Plan;

When the Placement Plan Modifications should be based on the visualization model associated with the modified Placement Plan.

3.2.5.3.1.6. For each 3D Scene, the system shall uniquely identify the position of the brackets (and when working with a Tx Placement Plan – also the dental arches):

When model brackets are not displayed;

When the Placement Plan is determined by the positioning of the brackets;

Page 20: SRS

Software Requirements Specification

18f

When the Placement Plan Modification is determined by the modified positioning of the brackets.

3.2.5.3.2. Visualization Models, Plans and Modifications of the Model

3.2.5.3.2.1. The system should display a single, 3D Scene selected by the user for each 3D Model, Placement Plan and Placement Plan Modification. The choice of model may be necessary for the user to view the original orthodontic condition of the patient prior to treatment and placing brackets.

3.2.5.3.2.2. The system must provide the ability to display multiple 3D Scenes - one for each 3D Model, Placement Plan or modified Placement Plan selected by the user, to enable their visual comparison.

3.2.5.3.3. Displaying 3D Scenes

3.2.5.3.3.1. The user must be able to switch at any time between successive projections of 3D Scenes to display:

Front view;

Rear view;

Left side view;

Right side view.

3.2.5.3.3.2. When only one of the jaws is selected for display (upper or lower, see 3.2.5.3.4), an occlusal view of the same jaw must be made available.

3.2.5.3.3.3. When switching between available, multiple displays of the 3D scenes, all views should be centered with respect to the viewpoint.

3.2.5.3.3.4. The user should be allowed to move relative to the 3D scene viewpoint.

3.2.5.3.3.5. The user should be allowed to freely rotate relative to the 3D scene viewpoint.

3.2.5.3.3.6. The user should be allowed to freely zoom in and out of the 3D Scene with respect to the viewpoint (perform scaling).

3.2.5.3.3.7. When displaying multiple models, Placement Plans or Placement Plans Modifications (see 3.2.5.3.2), the user should be allowed to perform all movements and change projections simultaneously for all scenes displayed. This feature should help the user to perform a visual comparison of selected 3D Models, Placement Plans or Placement Plan Modifications.

Page 21: SRS

Software Requirements Specification

19f

3.2.5.3.4. Visualization of Arches

3.2.5.3.4.1. Visualization of the arches should be performed when working with both 3D models, Placement Plans and Placement Plans Modifications.

3.2.5.3.4.2. At the request of the user, the system should display within the 3D Scene, upper arch separately (hide lower), lower arch separately (hide upper) or both arches together.

3.2.5.3.4.3. At the request of the user, the system should display two separate 3D Scenes: one - for the upper arch, the other - for the lower arch.

3.2.5.3.4.4. The user should be able to select the joint arrangement of 3D Scenes to display separately the upper and lower arches using the following templates:

Scene 1 - on top of the other - from the bottom;

Scene 2 - on the left, the other - on the right.

3.2.5.3.4.5. A separate display of 3D Scenes for the upper and lower arches should be available in the case of a simultaneous display of multiple 3D Models/ Placement Plans / Placement Plan Modifications (see Section 3.2.5.3.2). In this case, each selected view should be displayed in two stages - one for the upper arch and the other – for the lower.

3.2.5.3.5. Visualization of Teeth

3.2.5.3.5.1. Visualization of teeth must be performed when working with pre- and post-treatment 3D models, Placement Plans and Placement Plan Modifications.

3.2.5.3.5.2. When working with Rx Placement plan, the system should display the initial position of the teeth, pre-treatment.

3.2.5.3.5.3. When working with a Tx Placement plan, "Edit" mode, the system should display the final position of the teeth, post-treatment.

3.2.5.3.5.4. When working with a Tx Placement Plan, "Animation" mode, the system should display the position of the teeth pre-treatment and gradually progress to show the post-treatment position.

3.2.5.3.5.5. When working with a Tx Placement Plan (all modes), the system must make it visually noticeable to the user to display zone/s of teeth intersections, when available (a condition where one tooth collides into the other).

3.2.5.3.6. Visualization of Brackets

3.2.5.3.6.1. Visualization of brackets should work with Placement Plans and Placement Plan Modifications, but not with the 3D Models.

Page 22: SRS

Software Requirements Specification

20f

3.2.5.3.6.2. A bracket must be rendered in accordance with its type, i.e. EDS visualizes selected brackets. Data for visualization is obtained from bracket CAD files (provided directly by the brackets' vendors or through 3D scanning of the said brackets).

3.2.5.3.6.3. When working with a Rx Placement Plan, the system should present the position of the brackets on the teeth, pre-treatment.

3.2.5.3.6.4. When working with a Tx Placement Plan, "Edit" mode, the system should display the position of the brackets on the teeth, pre- and post-treatment.

3.2.5.3.6.5. When working with a Tx Placement Plan, "Animation" mode, the system should display the movement of brackets and teeth from the initial, pre-treatment position until the final, post-treatment position. The trajectory of the teeth and brackets calculated when creating a Tx Placement Plan is for presentation purposes only. The EDS does not show and does not pretend to predict the true trajectory of the teeth.

3.2.5.3.6.6. The system must produce visually noticeable alerts to the user, at the time when position of the brackets is conceived as erroneous and as such, requires user attention. Instances that call for increased attention can be the following:

A bracket intersects with an adjacent or opposing tooth;

A brackets collides with the gingival tissue.

A bracket is positioned too far from the tooth crown (>1.5 mm).

3.2.5.3.6.7. When brackets' positioning is deemed as incorrect, the system should provide the user a written explanation - what seems to be the perceived problem.

3.2.5.3.6.8. The user should be able to toggle between hiding and showing brackets for both arches simultaneously.

3.2.5.3.7. Visualization of Wires

3.2.5.3.7.1. Wires should be displayed only when working with a Tx Placement plan. Wires are presented in natural size. EDS produces the visualization of only the final Wire prescribed.

3.2.5.3.7.2. Visualization of Wires should work with Placement Plans and Placement Plan Modifications, but not with the 3D Models.

3.2.5.3.7.3. The system should display the final position of the Wire, post-treatment.

3.2.5.3.7.4. The user should be able to toggle between hiding and showing Wires for both arches simultaneously.

3.2.5.3.8. Visualization of Occlusogram

3.2.5.3.8.1. The system shall, at the request of the user, display an occlusogram (a color chart depicting the distance in mm between the upper and lower arches).

Page 23: SRS

Software Requirements Specification

21f

3.2.5.3.8.2. The occlusogram should be displayed to the user at any projection.

3.2.5.3.8.3. The occlusogram displays gradations of color surfaces of the teeth, where each shade corresponds with a positive (if teeth are spaced apart from each other) or negative (if teeth interfere with each other) distance between the teeth.

3.2.5.3.8.4. In the occlusogram, there are designated colors displayed on all tooth portions, where distances to other teeth range from -0.2 to 1.2 mm. Other portions of the teeth surface not falling within that range are to be displayed in the usual color of the tooth.

3.2.5.3.9. Visualization of Teeth and Brackets Animation

3.2.5.3.9.1. Animation movements should be available only when working with Tx Placement Plans.

3.2.5.3.9.2. Animation visualization should be available with Tx Placement Plans and Tx Placement Plan Modifications, but not with 3D Models.

3.2.5.3.9.3. When using the animation, the user should not be able to make any changes to the current Placement Plan or Placement Plan Modification. When attempting to modify the current Plan, the system should display an appropriate message.

3.2.5.3.9.4. When in the "Animation" mode, the user must be able to view the movement dynamics of brackets and teeth, from pre- to post-treatment.

3.2.5.3.9.5. The user should be able to play back the animation.

3.2.5.3.9.6. The user should be able to pause the animation.

3.2.5.3.9.7. The user should be able to choose to render a particular time from the start of treatment until the end of treatment.

3.2.5.4. Selection of Elements in 3D Scenes

3.2.5.4.1. In the "Edit" mode, the user must be able to distinguish between the following elements, comprising the 3D Scene:

Tooth;

Bracket;

Wire.

3.2.5.4.2. The user must be able to select only one object at a time. Simultaneous selection of multiple elements should not be allowed.

Page 24: SRS

Software Requirements Specification

22f

3.2.5.4.1. Tooth selection

3.2.5.4.1.1. Selection of the tooth must be made by left-clicking on the image of the tooth (but not bracket) in the 3D Scene.

3.2.5.4.1.2. When a tooth is selected, it should be highlighted.

3.2.5.4.1.3. When a tooth is selected, the ADA tooth number should appear in a separate panel (see 3.2.5.5.4).

3.2.5.4.1.4. When a tooth is selected, a heat map showing the distances between the bracket mounted on that tooth and the tooth (see 3.2.5.5.1) should appear in a separate panel.

3.2.5.4.1.5. When a tooth is selected, when working with a Tx Placement Plan or Tx Placement Plan Modification, a separate panel should display information about all the movements of that tooth (see 3.2.5.5.5).

3.2.5.4.1.6. When a tooth is selected, when working with a Tx Placement Plan Modification, controls should be displayed for managing its movement (rotation, extrusion, intrusion, mesial-distal body movement, in-out body movement, angulation, torque adjustment) (see 3.2 .5.7.4).

3.2.5.4.2. Bracket selection

3.2.5.4.2.1. Selection of brackets must be done by left-clicking on the image of the bracket in the 3D Scene.

3.2.5.4.2.2. When a bracket is selected, the bracket should be highlighted.

3.2.5.4.2.3. When a bracket is selected, a separate panel should display information about the selected bracket (see 3.2.5.5.3).

3.2.5.4.2.4. When a bracket is selected, a separate panel should display the number of the bracket (see 3.2.5.5.4).

3.2.5.4.2.5. When a bracket is selected, a heat map showing the distances between the said bracket and tooth on which the said bracket is mounted, should be displayed in a separate panel (see 3.2.5.5.1).

3.2.5.4.2.6. When a bracket is selected, a view showing the positioning of the bracket relative to the tooth from the occlusal view should be displayed on a separate panel (see 3.2.5.5.2).

3.2.5.4.2.7. When a bracket is selected, when working with a Rx Placement Plan Modification, controls should be displayed for managing its movement on the tooth surface, pressing to the tooth surface, rotation and panning (see 3.2.5.7.2).

3.2.5.4.2.8. When a bracket is selected, when working with a Tx Placement Plan Modifications, controls should be made visible for managing mesial-distal movement.

Page 25: SRS

Software Requirements Specification

23f

3.2.5.4.3. Wire selection

3.2.5.4.3.1. Selection of Wires should not be made available

3.2.5.5. Tools for Visual Analysis for Recommended Bracket Positioning

3.2.5.5.1. Heat Map Distances between Brackets and Teeth

3.2.5.5.1.1. When a tooth or the corresponding bracket are selected, a separate panel should display the heat map distances between the brackets and teeth showing how the bracket is mounted on the tooth in different parts of the contact zone.

3.2.5.5.1.2. The said heat map shall display front tooth projection and the contact area of the bracket to the tooth.

3.2.5.5.1.3. The contact area must be colored with shades: the color of each point of the zone should display the distance between the tooth and the bracket at any given point.

3.2.5.5.1.4. Varying shades should cover the distance range from -1.0 mm (bracket-tooth interference) to 1.5 mm (bracket-tooth too distant).

3.2.5.5.2. Displaying Bracket Positioning Relative to the Tooth

3.2.5.5.2.1. When a tooth or the corresponding bracket are selected, a separate panel should display the bracket mounted on the tooth from an occlusal perspective, enabling visual analysis of the position of the bracket relative to the tooth.

3.2.5.5.3. Displaying Bracket Information

3.2.5.5.3.1. When a bracket is selected, a separate panel should display information about the bracket.

3.2.5.5.3.2. Information about the bracket should include the bracket catalog number, provided by the bracket vendor.

3.2.5.5.3.3. In case bracket positioning is deemed erroneous, information on the positioning of the bracket should also include a description of the cause of the perceived error.

3.2.5.5.4. Displaying Tooth Information

3.2.5.5.4.1. When a tooth or a bracket are selected, a separate panel should display the ADA number of the tooth.

Page 26: SRS

Software Requirements Specification

24f

3.2.5.5.5. Displaying Information about the Movement of a Particular Tooth

3.2.5.5.5.1. When a tooth is selected, a separate panel should display numerical information about the movements of the selected tooth from the initial position to the final. This information is required by the user to determine the clinical feasibility of moving the tooth given the state of the patient's bone.

3.2.5.5.5.2. Information on the movement of the selected tooth should be displayed only when working with a Tx Placement Plan or a Tx Placement Plan Modification.

3.2.5.5.5.3. Information on the movement of the tooth should include the following:

Rotation angle in degrees;

Angulation angle in degrees;

Inclination angle in degrees;

In/out shift in mm;

Extrusion/ intrusion shift in mm;

Mesial/distal shift in mm.

3.2.5.5.5.4. When the pre-treatment 3D Model is displayed (not the Tx Placement Plan or Tx Placement Plan Modification) zero values should appear for all movement parameters.

3.2.5.5.6. Displaying Information on Teeth Movement

3.2.5.5.6.1. When working with a Tx Placement Plan or Placement Plan Modification, the user should be able to view a table indicating the different moves from the initial position to the final for all teeth. This information is required by the user to determine the clinical feasibility of moving the teeth given the state of the patient's bone.

3.2.5.5.6.2. A table presenting such data should include the following numerical values of the parameters for each tooth:

Rotation angle in degrees;

Angulation angle in degrees;

Inclination angle in degrees;

In/out shift in mm;

Extrusion/intrusion shift in mm;

Mesial/distal shift in mm.

3.2.5.5.6.3. When the pre-treatment 3D Model is displayed (not the Tx Placement Plan or Tx Placement Plan Modification) zero values should appear for all movement parameters.

Page 27: SRS

Software Requirements Specification

25f

3.2.5.6. Measuring Tools

3.2.5.6.1. Use of measuring tools shall not in any way affect the position of teeth, brackets, or Wires.

3.2.5.6.1. Measuring Teeth Width

3.2.5.6.1.1. The user should be able to measure the width of each individual tooth.

3.2.5.6.1.2. The width of the tooth should be calculated as the distance between the mesial and distal extremes of the tooth.

3.2.5.6.1.3. The user must be able to designate the mesial and distal extreme points of any tooth on any location in that tooth.

3.2.5.6.1.4. After that, for each tooth, the system should visually display the endpoints connecting their line and length of line in millimeters.

3.2.5.6.1.5. The user will be able to modify the mesial and distal extreme points of the teeth by redrawing of points, lines and counting distances.

3.2.5.6.2. Measuring Arch Length

3.2.5.6.2.1. The user should be able to measure the desired arch length separately for each jaw.

3.2.5.6.2.2. The length of each arch should be calculated as the total distance between the nodal points of the arch.

3.2.5.6.2.3. The user should be able to shift the nodal point of the arch on the occlusal plane, thereby changing the intended curvature of the arc.

3.2.5.6.2.4. The system must visually display the resulting arch of its nodal points and the total distance in millimeters.

3.2.5.6.2.5. By moving the user node points, new measurement should be made by redrawing points, arcs and counting the total distance.

3.2.5.6.2.6. Moving the nodal points of the arch should only affect measurement results and will not impact the final form taken by the arch, post-treatment.

3.2.5.6.3. Measuring Arch Width

3.2.5.6.3.1. The user should be able to measure the width of the arch in defined areas, separately for each jaw.

Page 28: SRS

Software Requirements Specification

26f

3.2.5.6.3.2. For the purposes of measuring arch width the system must visually display:

three auxiliary lines arranged on a plane, to measure the width of the arch in designated locations;

a fourth auxiliary line, also located on a plane perpendicular to the arch and the third line, for measuring the distance between the third line and the central point of the arch at the point of inflection.

3.2.5.6.3.3. Prior to starting the measurement, lines should be located by default as follows (see figure):

The first three lines are parallel to each other;

The end of the fourth line should be placed at the center point of inflection in the place of the arch;

Distances between the first three lines must be equal.

Figure 2 – The initial position of the measuring lines

3.2.5.6.3.4. The user must be able to freely move the ends of the first three lines of the arch on the occlusal plane. In the fourth line, the user must be able to move only one of its ends, the second end has to be automatically positioned on the third line so that the third and fourth lines are always perpendicular.

Page 29: SRS

Software Requirements Specification

27f

3.2.5.6.4. Measuring Cross Section

3.2.5.6.4.1. The user must be able to measure the distance in the vertical cross section plane perpendicular to the frontal plane of the oral cavity, along lines perpendicular to the frontal plane. In particular, the user must be able to measure the size of the sagittal fissure.

3.2.5.6.4.2. The system must visually display the measured values in the two 3D Scenes:

In the first stage (frontal view default) the system should display a vertical section line and the distances between the plane sections and the center of the oral cavity, in millimeters;

In the second stage (left view default), the system should display a user-defined section, a line whose length is measured on said plane, its extreme points and the distance between them in millimeters.

3.2.5.6.4.3. The user should be able to specify the location of the section, setting its distance from the geometric center of the mouth. Specifying the location of the section should be a vertical movement from the cut-off in the first stage.

3.2.5.6.4.4. The measurement should be done by specifying the user endpoints along a line perpendicular to the frontal plane, the distance between which is to be calculated.

3.2.5.6.4.5. When moving one of the end points, the second point has to be automatically positioned on the same horizontal level so that the angle of the line does not change.

3.2.5.6.4.6. The user should be able to change the position of the line along which the measurement is made in the vertical plane.

3.2.5.6.4.7. By moving the user endpoints, redrawing of points, lines, must be made and the length recalculated.

3.2.5.7. Editing Bracket Positions

3.2.5.7.1. General Functionality Requirements for Editing Positions

3.2.5.7.1.1. The system should allow the user to modify the Placement Plans provided by the Exceed Center. Modifications must not be made in the original Placement Plans but instead in an editable copy created.

3.2.5.7.1.2. Placement Plan Modification should be created automatically every time a user attempts to edit a Placement Plan (see also Section 3.2.5.7.1).

3.2.5.7.1.3. The system should not allow to edit a Placement Plan or a Placement Plan Modification that have already been approved by the user.

3.2.5.7.1.4. When working with a Rx Placement Plan, the system should allow the user to only modify the position of the brackets.

Page 30: SRS

Software Requirements Specification

28f

3.2.5.7.1.5. When working with a Tx Placement Plan, the system should allow the user to modify the position of brackets (in the mesio-distal plane only), teeth and wires.

3.2.5.7.1.6. When working with a Tx Placement Plan, a modification in the position of brackets and teeth should be construed as a modification to the final position of brackets and teeth.

3.2.5.7.1.7. When working with a Tx Placement Plan for the final position of the teeth and brackets (user-defined) as well as the initial position of the teeth (in the original 3D Model), the initial position of the brackets should be automatically calculated.

3.2.5.7.1.8. When working with a Tx Placement Plan, a modification of the position of the wire should be construed as a change in the final position of the wire, which should lead to a change in the final position of the brackets attached to the wire (see 3.2.5.7.5).

3.2.5.7.1.9. When working with a Tx Placement Plan, the system should provide the ability to modify only in "Edit" mode (see 3.2.5.2). When trying to change position of elements in "Animation" mode, the system should display an appropriate message.

3.2.5.7.1.10. In the course of moving the brackets and teeth, the system must dynamically and continuously redraw them in accordance with the requirements of visualization of brackets and teeth: allocate the intersection of teeth, identify incorrect position of brackets, etc. (see 3.2.5.3).

3.2.5.7.1.11. The system should allow the user to undo any modifications to the movements of brackets, teeth and wires.

3.2.5.7.2. Modifying Bracket Position When Working With a Rx Placement Plan

3.2.5.7.2.1. When working with a Rx Placement Plan, any modifications concerning the position of the brackets relative to the teeth.

3.2.5.7.2.2. When working with a Rx Placement Plan, the system should allow the user to perform a calculation of the recommended position of the bracket on the tooth (auto-installed).

3.2.5.7.2.3. Calculation of the recommended position of the bracket on a tooth should be based on the shape of the tooth, the geometry of the bracket and the calculation method that best fits the general preferences of the clinician in placing brackets pre-treatment.

3.2.5.7.2.4. The system should allow the user to select the desired method of calculation.

3.2.5.7.2.5. The system should allow a user to move the bracket on the surface of the tooth.

3.2.5.7.2.6. When moving a bracket on the tooth, the bracket should maintain maximum contact points with the tooth surface.

3.2.5.7.2.7. The system should allow a user using a computer mouse to indicate which side of the bracket center has to be pressed to achieve maximum contact with the tooth surface.

Page 31: SRS

Software Requirements Specification

29f

3.2.5.7.2.8. The system should provide the user with the ability to rotate the bracket with respect to its axis perpendicular to the tooth surface.

3.2.5.7.2.9. When a bracket is moved, the information displayed in the visual analysis tools for the position of the brackets will also be updated (see 3.2.5.5).

3.2.5.7.3. Modifying Bracket Positions When Working with a Tx Placement Plan

3.2.5.7.3.1. When working with a Tx Placement Plan, any change in the position of the brackets should be construed as a change in the position of the brackets relative to the tooth crown.

3.2.5.7.3.2. A change in the position of brackets can only be made on the position of the teeth post treatment. The system must automatically recalculate the position of the brackets on the basis of the final position of the teeth (user-defined) on the teeth in the initial 3D Model, pre-treatment

3.2.5.7.3.3. The system should provide the user with the following options for moving a bracket:

Move the bracket together with the tooth (tooth moves after the bracket);

Move the bracket independently from the tooth (tooth remains in place).

3.2.5.7.3.4. Moving the bracket should always be limited to mesio-distal drifting on the wire plane.

3.2.5.7.3.5. When a bracket is moved, the information displayed in the visual analysis tools for the position of the brackets will also be updated (see 3.2.5.5).

3.2.5.7.4. Modifying Teeth Positions When Working with a Tx Placement Plan

3.2.5.7.4.1. Modifying teeth position should be enabled only when working with a Tx Placement Plan (see in section 3.2.5.7.1).

3.2.5.7.4.2. When working with a Tx Placement Plan, any modification to the position of the teeth should be construed as a change in the final position of the teeth.

3.2.5.7.4.3. Modifying the position of the teeth should lead to a re-calculation of the position of the brackets on the basis of the final position of brackets and the initial position of the teeth on the 3D Model.

3.2.5.7.4.4. When modifying tooth position, the corresponding brackets should not move.

3.2.5.7.4.5. The system should provide the user with two models for tooth movement:

Mode 1 - Along the wire plan;

Mode 2 - Free spatial movement.

Page 32: SRS

Software Requirements Specification

30f

3.2.5.7.4.6. "Free movement" mode should be carried out by moving the tooth mouse and using appropriate guides. The user will not be able to modify or change the numerical parameters responsible for tooth position.

3.2.5.7.4.7. When working in any plane (facial, occlusal, etc.) in "Free movement" mode, the user should be allowed to grab the mouse and drag the tooth, thereby moving it in the plane to a new position.

3.2.5.7.4.8. Tooth movement guides should display when the tooth is selected (see 3.2.5.4.1).

3.2.5.7.4.9. With the exception of the occlusal projection, when working in all other projections (front, left, etc.), in the "Free movement" mode, the following visual guides shall be displayed:

a point lying on the edge of the tooth root – located on the intersection of the root axis and the gingival edge;

virtual handle/s for modifying the angle of the tooth, allowing the tooth to angulate in the current projection plane around a specified point (the edge of the tooth root remains fixed);

virtual handle/s for moving the tooth up and down along the root axis, allowing tooth extrusion/intrusion.

3.2.5.7.4.10. When working in the occlusal projection, in the "Free movement" movement mode, a virtual handle shall be displayed, allowing rotation of the tooth around its root axis.

3.2.5.7.5. Modifying Wire Position When Working with a Tx Placement Plan

3.2.5.7.5.1. Modifying wire positions should only be enabled when working with a Tx Placement Plan.

3.2.5.7.5.2. A wire movement should result in a synchronized displacement of the brackets mounted on the wire.

3.2.5.7.5.3. By movement of the wire, the user must be able to:

Elevate or lower all brackets connected to a single jaw at the same time – this may be necessary when brackets collide with teeth or brackets of the opposite jaw;

Change the angle of the wire plane on which the braces are placed.

3.2.5.7.5.4. Moving the wire must be carried out with the help of special visual guides.

Page 33: SRS

Software Requirements Specification

31f

3.2.5.8. Approval /Rejection of a Placement Plan or Placement Plan Modification

3.2.5.8.1. The user should be able to make a decision - to approve or reject the Placement Plan generated by the Exceed Center (see 3.2.4.3).

3.2.5.8.2. The user should be able to approve or reject the Placement Plan, regardless of whether created by the eXceed Center or modified by the user. Approval of the original Placement Plan and any ensuing Placement Plan Modification must be made available.

3.2.5.8.3. In the event the user has to comment on necessary revisions to the Placement Plan, This should provide the ability to indicate the brackets and/or teeth positioning errors.

3.2.5.8.4. When approval/rejection occurs, the following information is to be transmitted via the Data Exchange Server:

Comments on the Placement Plan;

Modification of the Placement Plan, if created by the user;

3.2.5.8.5. Uploading data to the server must be in accordance with the requirements set forth in section 3.2.4.8.2.

3.2.5.8.6. The system should not allow the user to approve or reject a Placement Plan or Placement Plan Modification without an active connection to the Internet (see the connection. Internet and Data Exchange Server Connectivity).

3.2.5.8.7. Following approval/rejection of the Placement Plan, the status of the Order shall change accordingly (see 3.2.4.3).

3.2.6. Additional Information to the User

3.2.6.1. When the system is launched, but no orders are opened, additional information should be displayed:

How to get started with the system;

General information about the system.

3.2.7. Localization

3.2.7.1. The system should support the localization of the graphical interface in English.

3.2.7.2. The system should support the localization of the graphical interface in Russian.

3.2.7.3. The system should allow the user to change the interface language before the opening of any order, and in the course of working with the Placement Plans.

Page 34: SRS

Software Requirements Specification

32f

3.3. Logical Database Requirements

EDS should operate with data organized in accordance with the data model ES. The main entities that must operate EDS, and the relationships between them are shown in the following diagram.

Figure 3 – Data model concept diagram

Each user can register any number of patients. For each patient, the user/doctor places multiple orders.

Execution of each order is based on the original patient records provided by the user upon order submission. (EDS should not do work with source documents - work with data entities is carried out by the DPO; allowing completeness of the data model.)

Each request may correspond to one (usually) or more 3D Models of the patient. If digitization has revealed modeling errors (e.g. missing or overlapping surfaces), the 3D Model is rejected and a revised 3D Model is requested. In this case, the request may correspond with several 3D Models, one of which is correct, and the other - erroneous.

Each 3D Model has its own unique number under the order. Model designation is formed from the reduction of "DM" (for digital model) and the model number, e.g., "DM 1".

Each Order can be matched by any number of Placement Plans prepared by the Exceed Center. Each Placement Plan corresponds with a distinct stage of communication between the Exceed Center and the user. Having a dedicated Placement Plan for each stage of the communication allows the doctor to compare plans, for easily tracking changes produced by the Exceed Center.

Placement Plans can be of two types: Rx Placement Plan and Tx Placement Plan (see 2.2.).

Each Placement Plan has a unique number within the order. Numbering plans is independent of the 3D Model number. Rx Placement Plan designation consists of the "Rx"

Page 35: SRS

Software Requirements Specification

33f

abbreviation and plan running number, for example, "Rx 1", "Rx 2" etc. Similarly, Tx Placement Plans shall be labeled "Tx 1" "Tx 2, etc.

When a revision is necessary, users shall have the ability to create their own Placement Plan Modifications and perform the required changes. Each Placement Plan Modification has a unique number, based on the name of the original Placement Plan revised and the number of revisions. For example "Rx 1.1" – will be the 1st revision of "Rx 1" and "Tx 2.3" shall be the third revision of "Tx 2"

3.4. Design Constraints

No specific design constraints have been identified.

3.5. Software System Attributes

3.5.1. Performance

3.5.1.1. It is assumed that the EDS shall not have a simultaneous operation of more than one user.

3.5.1.2. The EDS system should display lists for each user demands, comprising at least 100 orders in less than 5 seconds.

3.5.1.3. The system must support the loading of EDS data with Data Exchange Server volume of at least 10 MB/ per Order.

3.5.1.4. Rendering 3D Scenes should be carried out without delays detectable by a human observer (drawing each 3D Scene should take up to 0.04 seconds).

3.5.2. Reliability

Under any circumstance, operation on work orders should not lead to any violation of data integrity.

3.5.3. Availability

3.5.3.1. The procedure for updating the system should provide the ability to operate the system without any interruption, in both events of a successful and/or an unsuccessful update (for example, an Internet connection failure).

Page 36: SRS

Software Requirements Specification

34f

3.5.3.2. The system must provide the ability to interrupt overly prolonged operations (such as the system update, uploading Order data from the server in the event of a slow Internet connection).

3.5.4. Security

3.5.4.1. The system must distinguish between data access Orders for Data Exchange Server via password authentication of users.

3.5.4.2. Unauthorized users should not have access to data on the Data Exchange Server.

3.5.5. Maintainability

No specific maintainability requirements have been identified.

3.5.6. Portability

The portability of the system to different platforms to be carried out by means of virtualization. The system should correctly perform in the virtual environment.

WINDOWS version 7.0 or higher should act as the host operating system.