lauraschiatti / trackme Goto Github PK

Standards compliance
Hardware limitations
Any other constraint

All use cases must be drawn:
Sequence diagram

Data4Help

• UC2. Show requests

• UC1. Manage requests (UC3. Accept a request & UC4. Reject a request)

• UC5. Notify third party

• UC6. Sign up

• UC7. Login

• UC8. Send a request

• UC9. Access individual data

• 10. Subscribe to data

• 11. Access bulk data

• 12. Anonymize data

• 13. Show subscribed third parties

AutomatedSOS

• 15. Receive individual’s data
• 16. Validate health status
• 17. Contact health-care service

Track4Run

• Sign up
• Login
• Send Data4Help request
• Manage invitations
• Accept invitation
• Reject invitation
• Enroll in the run
• Create a run
• Define running circuit
• Send invitation
• Track runners’ location
• Send invitation to all the T4R participant users
• Select participants and send invitations

• Component diagram
• Class diagram

Top-down or Bottom-up strategy.

• Implementation plan
• Integration and testing

A high view of the system (D4H, T4R, ASOS) are mostly Service Oriented Architecture
A detailed level view for each service: MVC

Model all use cases.

Re-define data subscription view
Re-define notifications for 3rd parties

Requirements Analysis and Specification Document (RASD)

-- way of collecting data --> /sync endpoint

RASD

• Specify how the subscription is done.
  • When a third party searches for a SSN, there is a checkbox to subscribe to that user, or not. Add this to the bulk data as well
  • update all the diagrams and descriptions
• Specify the way D4H creates the requests for ASOS
• Specify the notification services for T4R and ASOS in the UC and decriptions.

Add traceability matrix in order to have all the goals, requirements and use cases relationships in one table.

domain model (class diagrams and statecharts)

Matching between requirements and components

Deployment diagram

High level architectural design

A.1 User Interfaces -> web site style
A.2 Hardware Interfaces -> we dont have any
A.3 Software Interfaces -> description of the interface we have to do in order to receive data from the devices, the interfaces related to the trhid party companies, the interface to communicate with the health care service, etc.
A.4 Communication Interfaces

===============
T4R interfaces: organizers can build the path of a run --> not individuals, T4R is a third party

spectators: interface for visualizing the position of runners only during the run

individuals: can enroll to an available run only if he is not enrolled to another run which takes place at the same date and time

• Purpose
• Scope

--> Use cases are related to some requirements (Keep track of this relationship through proper identifiers)

• Use case diagrams
• Use case specification
• Traceability matrix
• Activity diagrams
• Sequence diagram
• Scenarios

- Add acronyms to the list

Any assumption we have to make in order to run our services. Also, specify all the constraints we must consider (should include for example, that the Healthcare service has an interface that let us communicate to them)

Example:

• Constraints
  The mobile application is constrained by the system interface to the GPS navigation system within the mobile phone. Since there are multiple system and multiple GPS manufacturers, the interface will most likely not be the same for every one of them. Also, there may be a difference between what navigation
  features each of them provide.
  The Internet connection is also a constraint for the application. Since the application fetches data from the database over the Internet, it is crucial that there is an Internet connection for the application to function.
  Both the web portal and the mobile application will be constrained by the capacity of the database. Since the database is shared between both application it may be forced to queue incoming requests and therefor increase the time it takes to fetch data.

• Assumptions and dependencies
  One assumption about the product is that it will always be used on mobile phones that have enough performance. If the phone does not have enough hardware resources available for the application, for example the users might have allocated them with other applications, there may be scenarios where the application does not work as intended or even at all.
  Another assumption is that the GPS components in all phones work in the same way. If the phones have different interfaces to the GPS, the application need to be specifically adjusted to each interface and that would mean the integration with the GPS would have different requirements than what is stated in this specification

• Explain in detail world-only and shared phenomena (also a diagram)

- Scope: Bound the scope (define the limits) of the application by considering assumptions
What the is and is not intended to do:
AutomatedSOS notifies to the healthcare system but does not keep track of ambulance arrival...

What they are be able to do on the systems, what they cannot do (under which constraints), characteristics in general

• Users wearing the Trackme devices (individuals)
• ASOS individuals
• Track4Run Participants
• Track4Run Organizers
• Track4Run spectators
• third party companies

CRON