· Web view2020-06-02 · Software Design Document : Corre. TABLE OF CONTENTS. A

Software Design Document : Corre

TABLE OF CONTENTS ABSTRACT ...................................................................................................................................... 3

1.1. PURPOSE OF SYSTEM ............................................................................................................. 4 1.2. SCOPE OF SYSTEM ................................................................................................................. 4 1.3. DEVELOPMENT METHODOLOGY ............................................................................................ 4 1.4. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS .................................................................... 4 1.5. OVERVIEW OF DOCUMENT .................................................................................................... 5

2. CURRENT SYSTEM ..................................................................................................................... 5

3. PROJECT PLAN ........................................................................................................................... 5 3.1. PROJECT ORGANIZATION .......................................................................................................

5 3.2. SOFTWARE AND HARDWARE REQUIREMENTS ......................................................................... 5 3.3. WORK BREAKDOWN ...............................................................................................................

5 3.4.RISK ANALYSIS ........................................................................................................................ 6 3.3. COST ANALYSIS ...................................................................................................................... 6

4. REQUIREMENTS OF SYSTEM .................................................................................................... 7 4.1. FUNCTIONAL AND NONFUNCTIONAL REQUIREMENTS ............................................................. 7 4.2. PERSONAS .............................................................................................................................. 8 4.3. USE CASE DIAGRAM ......................................................................................................... 10 4.4. REQUIREMENTS ANALYSIS ................................................................................................... 11

5. SOFTWARE ARCHITECTURE ................................................................................................... 11 5.1. OVERVIEW ...........................................................................................................................

11 5.2. SUBSYSTEM DECOMPOSITION .............................................................................................. 12 5.3. PERSISTENT DATA MANAGEMENT ........................................................................................ 13

6. OBJECT DESIGN ....................................................................................................................... 13 6.1. OBJECT INTERACTION ......................................................................................................... 13

7. TESTING PROCESS ................................................................................................................... 15

8. GLOSSARY ................................................................................................................................ 15

9. APPENDIX ................................................................................................................................. 15 9.1. APPENDIX A – GANTT CHART .............................................................................................. 15 9.2. APPENDIX B – USE CASES ................................................................................................... 16 9.3. APPENDIX C – USER INTERFACE STORYBOARD DESIGNS ..................................................... 299.4. APPENDIX D – COST ANALYSIS …………………………….................................................... 31

Page 2 of 37

ABSTRACT In a world that's continuously moving and exponentially busy sometimes we lose sight of

the things that really matter, connection to others and health. In most situations we find ourselves exceling in one while neglecting the other at that time. We now have the solution, Corre. Corre is a fitness application for Android Smartphones that allows its users to connect and share results, ultimately promoting and inspiring healthier communities and lifestyles. With features such as run results, sharing capabilities, and profile features, Corre covers all the bases.

Page 3 of 37

1. INTRODUCTION

1.1. PURPOSE OF SYSTEM The purpose of this software is to promote healthy lifestyles through activity that users can view

and participate in either solo, within their community or beyond. This application is designed to inspire, develop, and maintain individuals that currently have healthy lifestyles or have the desire to want to start living healthily. On the individual level, Corre can track running activity, calculate results of recent and all runs, and provide additional health related information. On a macro-scale, Corre connects other individuals using the application permitting them to share their progress, inspire each other, and run ‘together’.

1.2. SCOPE OF SYSTEM This software aims to aid users in maintaining a healthy lifestyle by helping them keep track of

their exercise goals, as well as lessening the burden of keeping track of their run details. This will be achieved by capturing and displaying total distance and time of any run. Specifically, it will allow the user to create a profile that fits an individual users exercise goals, then allowing users to share and export their run results to share with others. The user will then be able to connect a device like a smart watch, to make the run easier in tracking additional details such as pulse.

Trying to exercise can be time consuming for those who have busy schedules or large families. This software will have the benefit of allowing the user to maintain organization and save time in their daily lives by automating the running process.

The software we are developing will support:

Firebase for account and profile information A set of user screens Google maps API External Fitness Hardware such as Smart Watches

The user will be allowed to:

Manually start/stop runs Export run reports to the internet Create a profile based on preferences Connect external devices Communicate within the application

Page 4 of 37

1.3. DEVELOPMENT METHODOLOGY Agile development is a set of values, principles, and beliefs that help teams make better decisions. The methodology isn't a process or a plan. It’s a compass to help guide teams to higher standard of software development. The agile approach profitless practices over others and is clearly laid out. The main goal is to deliver quality software packages to the customer as early as possible. The customer is involved along the route to delivery. Deliver often, and have them give feedback, and welcome any changes.

Following in importance to producing quality software, the agile method prioritizes people, and ensuring your team is well looked after. It is important to offer an environment that fosters openness and trust. Praise often, defend your team, openly discuss problems, and resolve them on a timely manner. We want small teams of engaged individuals with each team producing at its highest quality. Lastly the agile approach focuses on change and development. The ability to adapt to change comes from adopting a comprehensive and developed team through growth and reflection. Looking back and reflecting on past accomplishments and mistakes reach higher standards, bring attention to excellence, allows others to learn from that excellence. Attention to faults and mistakes, adjust procedures, and discuss.

1.4. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

Actors (Primary and Secondary): External entities that interact with the system. UI: User Interface, the part the end user sees. Deliverable: Work product for client. GPS: Global Positioning System

1.5. OVERVIEW OF DOCUMENT The rest of the document to follow outlines the project in depth, defining roles, responsibilities,

processes, functionality, and methodology of Corre. The functions of the application are discussed further with corresponding documentation.

2. CURRENT SYSTEM Not Applicable

3. PROJECT PLAN

3.1. PROJECT ORGANIZATION Anthony K. Editor

Andrew M. System Architect

Austin M. Leader

Page 5 of 37

Hendrik O. Minute Keeper

Eli S. Secretary/Diary Keeper

3.2. SOFTWARE AND HARDWARE REQUIREMENTS Hardware: Android Smartphones, GPS Sensor, Camera, Cell phones, Smart watches.

Software: Android Studio, GPS, Database, Camera Capabilities, MS Word, Pencil

3.3. WORK BREAKDOWN Task # Task Description Duration Dependencies

1 Project Plan Get to know team members, brainstorm, assign roles, decide project topic

3 days

6 Create use cases Identify use cases, assign use cases to team members, each team member develops their assigned use cases

8 days 1

10 Review and completion of use cases

Present use case diagrams to professor, correct use cases

5 days 6

13 Development of Personas

Complete 12 days 10 (M1) (D1)

17 Present SRD to class, submit SRD to professor

1 day 13

18 Software Divide project into subsystems, 2 days 17 Architecture identify objects, complete design

document, 22 Object Design Transition of software models into

source code. 18 days 17

30 Implementation Database design. Interface Layer, Application Layer and Storage Layer coding.

40 days 27 (M3)

35 Testing Process Subsystem, System and Evaluation tests. Creation of the User’s Guide.

16 days 27

40 Creation of FD Complete FD create Power Point presentation.

23 days 30, 35 (M4) (D3)

45 Presentation of FD Present and submit the FD. 1 day 40

M – Milestone D – Deliverable

Page 6 of 37

3.4 RISK ANALYSIS

Figure 1: Risk Table Analysis

3.5 COST ESTIMATE

Figure 2: Cocomo Cost Analysis. Refer to Main.csv and Phases.csv for further

detail.

Page 7 of 37

4. REQUIREMENTS OF SYSTEM

4.1. FUNCTIONAL AND NONFUNCTIONAL REQUIREMENTS Functional: The system we are proposing will need access to a database, the smartphone’s GPS, camera, and other active users using the application. The system must be able to read and write to the database to add and maintain lifetime totals. The system must be able to measure distance and time. System must allow user to communicate through chat channels; and will store chats in the database for retrieval upon request.

Create Account Delete Account Change Profile Picture Connect Device Start Run Export Run Report View Inbox Send Message Recover Password Edit Profile

Non-functional: Usability: The application will be designed as simple as possible for the users to navigate and use the application. 95% of all users will be able to complete representative tasks without requiring assistant. Reliability: The application will be tested and run before it is published to everyone. There will be 1 support button on any interface to report problems. Availability: The application only has 1 profile assigned to 1 phone.Measurability: Both recorded run times and run distances will be recorded with at least 99% accuracy.

Page 8 of 37

4.2. PERSONAS

Page 9 of 37

Figure 3: Personas

Page 10 of 37

4.3. USE CASE DIAGRAM

Figure 4: Use Case Diagram

This figure depicts the interaction between the actors and the previously described use cases. A

description for each actor follows.

Actors:

Runner: This is the user who has downloaded Corre to their Android Smartphone with access to client

functions

Support Staff: This is Corre Support Team. Their functions are viewing and responding to messages as

well as deleting other users.

Page 11 of 37

Secondary Actors:

Firebase: Maintains all of the account, run and profile information.

Google Maps API: Maintains all information about run, location and speed.

External Hardware (watch): Allows for a device to be connected like a smart watch.

4.4. Requirements Analysis

After identifying the client’s requirements, we, as system designers, can devise the most appropriate

solution. By using the use cases to capture all potential requirements, the team will device the most

suitable software architecture, which meets the user’s needs. This will ensure the attainment of

customer’s expectations as well as providing a functional final product.

5. Software Architecture

5.1. Overview

After evaluating and analyzing the main structure and functionalities of our project, the proven, and

highly utilized three-tier architecture was chosen for our project. The selection of a three-tier

architecture will allow our team to effectively divide the work during our implementation phase. A team

member’s area of expertise will dictate which part of the system they’ll work with; this way our team

takes full advantage of our multidisciplinary aspects.

Figure 5: Layered Architecture Diagram

Page 12 of 37

5.2. Subsystem Decomposition

Figure 6: Class Diagram

Page 13 of 37

5.3 Persistent Data Management

Figure 7: E/R Diagram

Page 14 of 37

Figure 9: E/R Diagram

6. Object Design6.1 Object InteractionUse Cases expressed in Sequence Diagram: Set Up Acct, Get Profile, Read/Send Messages, Run, Save Run, and Get Run Report respectively.

Page 15 of 37

7. Testing Process

Test Case ID: T001 Developed by: Austin Meyer

Test Priority (Low/Medium/High): Med Development date: 10/15/2019

Module Name: Profile Test Executed by: <Name>

Test Title: Bio Length

Testing Tool: Android Smartphone Test Execution date: <Date>

Description: Enter specified parameters to the Profile’s Bio field

Pre-conditions: None

Dependencies: Profile

Step Test Steps Test Data Expected Result Actual Result Status (Pass/Fail)

1 Enter Profile Module from Menu Displays ProfileUI

2 Access the Bio button Opens Text Data Field Entry

3 Enter 100 Characters

Qwertyuioplkjhgfdsazxcvbnm,./?><MNBVCXZASDFGHJKL:”}{POIUYTREWQ|\`1234567890-=+_)(*&^%$#@!~1234567890

Acceptable Entry, Text Field closes and returns to ProfileUI

4 Enter 101 Character

Qwertyuioplkjhgfdsazxcvbnm,./?><MNBVCXZASDFGHJKL:”}{POIUYTREWQ|\`1234567890-=+_)(*&^%$#@!~12345678901

Data Field won’t accept any more characters after the 100th, any attempt to put more characters will have some twitter-like red ‘x’ signifying that limit has been reached.

Page 16 of 37

Post-conditions:




Test Title: Profile Pic Change


Description: Upload a new photo onto Profile in Corre

Pre-conditions: Permissions to phone’s photos

Dependencies: Profile


1 Enter Profile Module from Menu Displays ProfileUI

2 Access the Photo button Opens Data Field Entry

3 Choose photo.jpeg to upload and submit photo.jpeg

Data Entry closes with Successful Submission, return to ProfileUI with new photo in old photo spot

4 Choose photo.gif to upload and submit photo.gif


5 Choose photo.bmp to upload and submit photo.bmp


Post-conditions:

Page 17 of 37




Test Title: Profile UI Responsiveness Test


Description: Profile UI opens no longer than 0.8 seconds after being activated from menu, for testing purposes a screen displaying time it takes for UI to upload

Pre-conditions: In any UI other than Profile’s UI

Dependencies: None


1 Access ProfileUI from Menu Bar

ProfileUI displays in less than 0.8 seconds

2

3

4

Post-conditions:

Page 18 of 37

8. Glossary

PA – Primary User; client

WU- Warm-up

9. Appendix

9.1. Appendix A – Gantt Chart

Page 19 of 37

Figure 11: Gantt Chart

9/15 9/30 10/15 10/31 11/15 11/30

Figure 11: Sequence Diagram

9.2. Appendix B – Text Use Cases

Text Use Cases

Use Case ID: C01 - Create AccountScenario:Actor: RunnerPre-conditions:

1. Corre is successfully downloaded on Android phone2. The device doesn’t already have a profile created

Description:1. Use Case Begins: when RUNNER activates “Corre”2. The system will check to see if the precondition 2 is true, and then provides the

RUNNER with a template for data entry (See appendix A).3. The RUNNER enters the following data: name, email.4. The system will initiate a Friends List, Location (by GPS), Best Time, Results, Points,

and Exp. Level. The system run text use case Change Goal5. RUNNER will complete text use case Change Goal6. Use Case Ends: when System saves profile and delivers the RUNNER to Main Interface

Post-conditions:1. A unique profile is created specifically for the device.

Alternative Courses of Action:1. 1. Terminating Corre

Exceptions:1. None

Related Uses Case:1. None

------------------------------------------------------------------------------------------------------------Decision Support:Frequency:

1. Low. Initial account set-upCriticality:

1. High. Allows the Runner an identity to use the appRisk:

1. High.Constraints:Non-functional requirements:Data Integrity:

1. Data accuracy of .01% is required to maintain integrity.Usability:

1. Maximum of 6 fields to keep sign-up simple and useable.------------------------------------------------------------------------------------------------------------Modification History:Owner: Andrew M.Initiation date: 2/13/2019Date last modified: 10/1/2019

Page 20 of 37

Use Case ID: C02 – Recover PasswordScenario:Actor: RunnerPre-conditions:

1. Runner is on Create Account/Log In interface screen2. Runner has a preexisting account3. Runner has forgotten password

Description:1. Use Case Begins: when RUNNER clicks on the “Forgot Password” on the Create

Account/Sign in Interface 2. The system will load the Forgot Password interface and provide a textbox for user input.3. The RUNNER enters their email and sends the request for authentication by selecting

“Reset Password” button. 4. The system shall send an authentication request to Firebase database. Then notifies the

RUNNER if the request was submitted correctly. 5. Use Case Ends: when Firebase sends an email to user email for password

reset Post-conditions:

1. The password for RUNNER account has been changed in Firebase databaseAlternative Courses of Action:

1. In step D.2 user can exit and return to Create Account/ Sign In interface by selecting Back button.

2. In step D.4 if no email is inputted by RUNNER, system will display error message3. In step D.5 if email inputted by RUNNER is not a valid address to existing account,

an error message will be returned to userExceptions: 1. The help link on the CS web page is not active. 2. After the user enters the required data the send button is not active.Related Uses Case:

1. None.------------------------------------------------------------------------------------------------------------Decision Support:Frequency:

1. On average 2 requests are made weekly by Runner.Criticality:

1. High. Runner will need password to access account.Risk:

1. High. Implementing this use case employs Firebase authenticationConstraints:Non-functional requirements:

1. Measurability: Password must be at least 8 characters long------------------------------------------------------------------------------------------------------------Modification History:Owner: Andrew M.Initiation date: 09/24/2019Date last modified: 10/1/2019

Page 21 of 37

Use Case ID: C03 Terminate Account

Pre-conditions:1. Corre installed on Android phone2. Runner Logged-in Corre account.

Description:1. Use Case Begins: when RUNNER activates Corre and navigates

through Access Control to Terminate Account UI and Activates “Terminate Account” Button.

2. System will locate all files related to user account for deletion and ask for user login information.

3. RUNNER Enters Login information and Password4. System verifies Login Name and Password, Requests RUNNER to

verify Terminate account5. RUNNER press “Accepts” (True) or “Deny” (False) button to

Terminate account.a) If pre-condition 7 is False. System return user to Screen, Use

Case Ends if 8 is Trueb) If pre-condition 7 is True System creates Temporary

Recovery file6. System Notifies RUNNER Length of 30 day account recovery.7. User pushes Ok Button8. Use Case Ends: System Returns user to create account screen.

Post-conditions:

1. User deletes Corre from Device:2. System stores profile for x amount of days for auto-deletion /

Cool of periodAlternative Courses of Action:

1. Re-activate account.Exceptions:

1. noneRelated Uses Case:

1. Create Account ------------------------------------------------------------------------------------------------------------Decision Support:Frequency:

1. Low. Runner will use when terminating accountCriticality:

1. High. Risk:

1. HighConstraints: Non-functional requirements:

Page 22 of 37

1. One Account Gets Suspended2. Suspension Lasts for 30 days

Measurability: 1. none

Utility: 1. None

------------------------------------------------------------------------------------------------------------Modification History:Owner: Hendrik OInitiation date: 9/24/2019Date last modified: 9/30/2019

Use Case ID: C04 - Update Profile PictureScenario:Actor: RunnerPre-conditions

1. RUNNER has a preexisting account2. RUNNER has images on phone3. RUNNER is currently on the Profile interface screen

Description:1. Use Case Begins: when RUNNER clicks on the pre-existing “Profile Pic”.2. The system will load the Forgot Password interface and provide a textbox for user input.3. The RUNNER enters their email then send the request for authentication by selecting

“Reset Password” button.4. The system shall send an authentication request to Firebase database then notify the

RUNNER if the request was submitted correctly.5. Use Case Ends: when Firebase will send email to user email for password reset

Post-conditions: 1. The password for Runner account has been changed in Firebase databaseAlternative Courses of Action:

1. In step D.2 user can exit and return to Create Account/ Sign In interface by selecting “Back” button.

2. In step D.4 if no email is inputted by Runner, system will display error message3. In step D.5 if email inputted by Runner is not a valid address to existing account, an error

message will be returned to userExceptions:

1. The help link on the CS web page is not active.2. After the user enters the required data the send button is not active.

Related Uses Case:1. None.


1. On average 2 requests are made weekly by CS user.Criticality:

Page 23 of 37

1. High. Allows the CS user to report any problems encountered with either computer software or hardware in the CS department.

Risk: 1. High. Implementing this use case employs Firebase authentication

Constraints:Non-functional requirements:

1. Measurability: There will only be 1 profile picture displayed------------------------------------------------------------------------------------------------------------Modification History:Owner: Andrew M.Initiation date: 09/24/2019Date last modified: 10/1/2019

Use Case ID: C05 - Edit ProfileScenario:Actor: RunnerPre-conditions:

1. RUNNER has an active account 2. RUNNER is at the Profile Interface

Description:1. Use Case Begins with System displaying RUNNER’s “Profile” information2. RUNNER selects “Biography”3. System presents a text box with an edible version of what is already written4. RUNNER adds, modifies or deletes information and exits the text box5. Use Case Ends when System saves and presents runner’s updated “Biography”

Alternative Courses of Action:1. Exiting the text box presented by System thus cancelling the modification

Exceptions:1. None

Related Uses Case:1. None


1. Low. Initial account set-upCriticality:

1. High. Allows the Runner an identity to use the appRisk:

1. High.Constraints:Non-functional requirements:

1. Reusability - Each account will have 1 Bio2. Measurability - The biography will host 100 Character Max

Page 24 of 37

------------------------------------------------------------------------------------------------------------Modification History:Owner: Austin M.Initiation date: 2/13/2019Date last modified: 9/24/2019

Use Case ID: C06 – View ProfileScenario:Actor: Runner Pre-conditions:

1. RUNNER has signed up for CorreDescription:

1. Use Case Begins: when RUNNER selects the “Profile" tab2. Use Case Ends: when System displays “Profile” Interface

Alternative Courses of Action:1. None

Exceptions:1. None

Related Uses Case:1. Run Report


1. Moderate. Runner may be as active in viewing profile as much as anything elseCriticality:

1. Moderate. This will determine who the Runner wants to connect with, which could directly affect how much pleasure or dissatisfaction with the app.

Risk: 1. High. Although it is a familiar concept, we are implementing a new feature on a platform

new to our team.


1. Availability: Profiles should be displayed in less than 0.8 seconds.2. Measurability: Profiles have at most 1 picture, 1 name, and 1 biography.

------------------------------------------------------------------------------------------------------------Modification History:Owner: Austin M.Initiation date: 2/13/2019Date last modified: 9/25/2019

Page 25 of 37

Use Case ID: C07 - Connect Device Scenario:Actor: RunnerPre-conditions:

1. Devices Bluetooth is turned on.Description:

1. Use Case Begins: when RUNNER selects “Connect” Device2. Device looks for available Bluetooth signals, then lists them.3. RUNNER selects device or backs out.4. Use Case Ends: Device saves accessory, start gathering information and closes menu.

Alternative Courses of Action:1. Close menu.

Exceptions:1. Bluetooth isn’t turned on.2. Device doesn’t have functional Bluetooth.

Related Uses Case:1. None.

------------------------------------------------------------------------------------------------------------Decision Support: Frequency:

1. Low. Only when user has new device or first setting up the wayCriticality:

1. High. Vital to all users with smartwatchesRisk:

1. Medium. The core app can function without these features, but it could alienate a certain group of users.


1. Usability - Connects at most 1 device------------------------------------------------------------------------------------------------------------Modification History:Owner: Anthony K.Initiation date: 2/13/2019Date last modified: 10/1/19

Use Case ID: C08 - Start RunScenario:Actor: Runner Pre-conditions:

1. Corre is successfully downloaded and installed.2. Corre profile has been set up.

Description:1. Use Case Begins: when RUNNER selects the “Run” button2. The system will then prompt the RUNNER to set either a time goal, a distance goal, or a

free-run, or Run together with the same options

Page 26 of 37

3. If “Time Goal” is selected, then the system will ask how long the RUNNER would like to run for.

4. If “Distance Goal” is selected, the system will prompt the Runner to enter the distance desired

5. If free-run is selected the system begins to initialize the run6. The system transitions to the map and run statistics screen7. RUNNER has the option to select “Pause” or “Stop” when in the Run mode8. If “Pause” is selected, the system will pause time and stop recording location9. If “Stop” is selected, the system will stop timing & location recording and save the

runners profile10. The system will send the RUNNER to a summary screen11. Use Case Ends: After summary screen is closed. The RUNNER is returned to main

screen Post Conditions:

1. Run data has been appropriately updated2. System has recorded the run data

Alternative Courses of Action:1. In step D.2 if no choice is made, free run is default2. In step D.2 the runner has the option to cancel run

Exceptions:1. Run button does not activate the run feature2. System does not save the run data

Related Use Case: None------------------------------------------------------------------------------------------------------------Decision Support:Frequency:

1. High. Runners on average will use this once per day.Criticality:

1. High. Main function of the Corre app, allows users to begin their run.Risk:

1. High. Implementing this use case requires GPS system technology and accurate time keeping.


1. NoneMeasurability:

1. Distance will be measured every 1 second------------------------------------------------------------------------------------------------------------Modification History:Owner: Ryan F.Initiation date: 2/13/2019Date last modified: 10/2/2019

Page 27 of 37

Use case ID: C09 Get Run Report

Pre-conditions:1. Corre is successfully downloaded and installed.2. RUNNER logged-in Corre User Account.3. RUNNER running Corre App

Description:1. Use case begins: when RUNNER selects “Run Report” in UI2. The system access User Firebase Run Report File.3. If Run report data is not “Null” User interface will display Date, distance and time

Chronologically within list format. 4. End Use case: if 3 is True5. If Run Report is “Null “ UI will display “ No runs Recorded, Please start a run for

reports to be stored here” 6. Use Case Ends: if 5 is True

Post Condition:1. None

Alternative Courses of Action:1. Close and restart Corre

Exceptions:1. Report button does not activate get Report2. System can’t access firebase Run Report File.

Related Use Case:

1. Start Run2. Export Run Report


1. High. Runners are expected to use after each run.Criticality:

1. Med, User compares Run Progress.Risk:

1. Low, Retrieves data, Constraints:Non-functional requirements:

1. Measurability- Time is logged in 00:00:00 precision and distance is measured to 0.00 precision

2. Utility – Report displays 5 most recent runs and their stats------------------------------------------------------------------------------------------------------------Modification History:Owner: Hendrik OInitiation date: 9/24/2019Date last modified:10/1/2019

Page 28 of 37

Use Case ID: C10 - Export Run ReportScenario:Actor: RunnerPre-conditions:

1. Runner has signed up and logged into the application.2. Runner has navigated to the Support Screen

Description:1. Use Case Begins When user clicks “export run report” button from support screen2. The system will create a save file dialog box.3. The user will enter the name and location the file will be saved and press the save button.4. Use Case Ends when system will write all run information in plain text and save it to the

location specified by the user.Post Conditions:

1. A file will be on the user device at the location selected.Alternative Courses of Action:

1. In step D.3, the user can cancel the exportExceptions:

1. Not enough disk spaceRelated Uses Case:

1. None------------------------------------------------------------------------------------------------------------Decision Support:Frequency:

1. On average 1 rune report is exported per day.Criticality:

1. Medium. Allows the runner to share their run when they want to.Risk:

1. Low. Implementing this use case employs standard web-based technology.


1. Usability - System should export run report within 5 seconds------------------------------------------------------------------------------------------------------------Modification History:Owner: Ryan FultonInitiation date: 2/13/2019Date last modified: 10/2/2019

Use Case ID: C11 - View Inbox FeatureScenario:

Page 29 of 37

Actor: RunnerPre-conditions:

1. Corre is successfully downloaded and installed.2. Corre profile has been established and device registered.

Description:1. Use Case Begins: When RUNNER selects “Inbox” button.2. The system will then prompt the RUNNER to select the unviewed message within the

system.a. If the RUNNER exits the inbox without viewing the unread message, it remains

flagged as unread for the actor.3. Use Case Ends: When RUNNER exits Inbox.

Post Conditions:1. Message history data has been appropriately updated

Alternative Courses of Action:1. Close and restart Corre

Exceptions:1. System does not save message history.

------------------------------------------------------------------------------------------------------------Decision Support: Frequency: 1. High. Users are expected to send and receive 2 messages per-day per RUNNER.Criticality:

1. High, a main function of the Corre app. Risk:

1. High, implementing this use case requires high storage capacity and accurate time keeping.


1. Usability - Inbox should display with 5 seconds.2. Utility – Inbox displays the 10 most recent messages history

-------------------------------------------------------------------------------------------------------------Modification History: Owner: Eli S.Initiation date: 9/30/2019Date last modified: 10/1/2019

Use Case ID: C12 Send MessageScenario: Actor: RunnerPre-conditions:

1. RUNNER has signed up and logged into the application.2. RUNNER has navigated to the Support Screen

Description:1. Use Case Begins: when RUNNER selects “Contact Support”2. System returns a screen for chatting3. RUNNER enters a message to send to Support Team and hits “send”

Page 30 of 37

4. Use Case Ends: when system sends message to Support and displays it in real time on screen


High. runners are expected to send upwards of 2 messages dailyCriticality:

2. Moderate. With the features to select run with friends on other activities or screens some runners may hardly use the chat feature. While some runners may be looking for more partners and setting up groups for running. The chat feature may need to expand

Risk: 1. High. Although it is a familiar concept, we are implementing a new feature on a platform

new to our team.


1. none Availability:

1. The runner should be able to send messages in a reliable manner with a success rate of 99 of 100 messages, with an expectation 100 messages a day to a few a week.

Scalability: 1. The chat feature could grow into a feature that links many RUNNERs of Corre for races

and marathons. It has the potential for large scale multi-person messaging.Measurability:

1. Message to be sent will have a maximum limit of 140 characters.------------------------------------------------------------------------------------------------------------ Modification History: Owner: Eli S.Initiation date: 9/30/2019Date last modified: 10//1/2019

Page 31 of 37

9.3. Appendix C – User Interface Designs

Figure 12: User Interfaces

Page 32 of 37

9.3. USER INTERFACE STORYBOARD DESIGN

Figure 13: Storyboard

Page 33 of 37

9.4 APPENDIX D – COST ANALYSIS

9.4.1 Phases

Project Name CorreTotal Size 70000Total Effort 318.1584

Overall Schedule (%)Schedule (Months) Effort (%) Effort Staff

Plans And Requirements 20.79% 4.767007 7.00% 22.27109Product Design 26.40% 6.051902 17.00% 54.08694Programming 46.42% 10.64218 56.81% 180.7538Integration and Test 27.19% 6.233412 26.19% 83.31774

EFFORTPlans and Requirements Product Design

Programming

Integration and Test PERSONNEL

Requirements Analysis 10.15655 6.760867 7.230151 2.082944 Requirements AnalysisProduct Design 3.830164 22.17564 14.4603 4.165887 Product DesignProgramming 1.090356 7.138349 102.1259 31.48716 ProgrammingTest Planning 0.823566 3.081829 9.39543 2.499532 Test PlanningVerification and Validation 1.603055 3.893133 14.81804 24.24894 Verification and ValidationProject Office 2.918441 5.735469 11.39125 6.083931 Project OfficeCM/QA 0.668133 1.352173 11.749 6.665419 CM/QAManuals 1.180832 3.949473 9.583715 6.083931 Manuals

Module Name User InterfaceTotal Size 10000Total Effort 48.72292




Programming


Page 34 of 37


Module Name Data ManagmentTotal Size 15000Total Effort 67.35888




Programming



Module Name Running/WorkouTotal Size 20000Total Effort 89.81184



Page 35 of 37


Programming



Module Name CommunityTotal Size 25000Total Effort 112.2648




Programming



9.4.2 – Main

Page 36 of 37

Page 37 of 37

Module Name

Source Lines of Code

Effort Adjustment Factor Nominal Person-Months Estimated Person-Months Productivity

Module Size EAF NOM Effort DEV EST Effort DEV PROD

User Interface 10000 1.085 44.90592 48.72292Data Managment 15000 1 67.35888 67.35888Running/Workou 20000 1 89.81184 89.81184Community 25000 1 112.2648 112.2648

CorreTotal SLOC Schedule

Total Nominal Person-Months

Total Estimated Person-Months

Total Estimated Productivity

Optimistic 21.35723 251.4732 254.5268Most Likely 70000 22.92749 314.3414 318.1584Pessimistic 24.6132 392.9268 397.6981

Cost Driver Rating VL L N HProductRequired Software Reliability RELY 0.82 0.92 1Database Size DATA 0.9 1Documentation Match to Lifecycle Needs DOCU 0.81 0.91 1Product Complexity CPLX 0.73 0.87 1Required Reusibility RUSE 0.95 1PlatformExecution Time Constraint TIME 1Main Storage Constraint STOR 1Platform Volatility PVOL 0.87 1PersonnelAnalyst Capability ACAP 1.42 1.19 1Applications Experience APEX 1.22 1.1 1Programmer Capability PCAP 1.34 1.15 1Platform Experience PLEX 1.19 1.09 1Language and Tool Experience LTEX 1.2 1.09 1Personnel Continuity PCON 1.29 1.12 1ProjectUse of Software Tools TOOL 1.17 1.09 1Required Development Schedule SCED 1.43 1.14 1Multisite Development SITE 1.22 1.09 1UserUser-Defined 1 USR1 1 1 1User-Defined 2 USR2 1 1 1

Precedentedness PREC 6.2 4.96 3.72Development Flexibility FLEX 5.07 4.05 3.04Architecture/Risk Resolution RESL 7.07 5.65 4.24Team Cohesion TEAM 5.48 4.38 3.29Process Maturity PMAT 7.8 6.24 4.68

Date post:	06-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

· Web view2020-06-02 · Software Design Document : Corre. TABLE OF CONTENTS. A

Documents