Skip to content

SRS

Jump to bottom
James Butler edited this page Sep 30, 2022 · 43 revisions

1. Introduction to Document

1.1. Purpose of Product

The conversation catcher is used to record a conversation and convert it into structured text that can be analysed to extract the main and important ideas of the conversation.

1.2. Scope of Product

One specific use case would be to use the app to automatically take minutes of a meeting and record for example what was said in a development meeting.

2. General Description of Product

2.1. Context of Product

Conversation catcher is a mobile app that can be used in corporate environments to automatically create minutes for any meeting. This app can also be used as a personal tool to record and summarise any conversation in a structured manner which allows a user to store the key ideas of important conversations.

2.2. Product Functions

The app allows users to record a conversation/meeting or upload a recording to the app. This recording will be translated and summarised in the app to produce a pdf that the user can view. This pdf can be downloaded and shared with other users. Additionally, an idea can be searched and all conversations where that idea was discussed will be included.

2.3. Use Case Diagrams

Use case diagrams for our system:
image image
image image

2.4. User Characteristics

The users of the system are people who wish to convert a recording to a pdf. One specific use case would be to use the app to automatically take minutes of a meeting and record for example what was said in a development meeting. Another would be a student who records their online lecture and uses the app to convert what was said to a pdf that they can then use to make notes based on the lecture.

2.5. User stories

Users:

  • As a user, I want to be able to upload audio recordings, such that the recording can be summarised and returned as a pdf.
  • As a user, I want to be able to record a conversation such that the recording can be summarised and returned as a pdf.
  • As a user, I want to be able to update my email and password such that if I get a new email or forget my password it is easy to change.
  • As a user, I want to be able to change the colour scheme of the app, such that I can personalise the app to my liking.
  • As a user, I want to be able to view all my pdfs in a user-friendly manner such that it is easy to identify the conversations that I saved.
  • As a user, I want to be able to delete the pdfs of conversations that I do not need anymore.
  • As a user, I would like to be able to rename my pdfs to allow me to easily find them again.
  • As a user, I want to be able to share the pdfs of my conversations with friends and colleagues so that they can easily view shared meetings/conversations.
  • As a user, I want to be able to set up a list of friends or colleagues to which the pdf of a conversation will be automatically shared such that distribution of meeting summaries are easy. The app should also notify a user when this happens.

Participant:

  • As a participant in a conversation, I want my contribution to be recorded.

2.5. Constraints

  • The technology used should not have any constraints in terms of licences.
  • The translation service should be loosely coupled with system design so that it can easily be integrated into other platforms.

2.6. Assumptions and Dependencies

We assume that the speech that is given to convert to text we assume that the audio is of good enough quality and what is said is of a good enough qaulity that we can use if for functionality like summarising it.

3. Specific Requirements

3.1. External Interface Requirements

3.1.1. User Interfaces

3.1.2. Hardware Interfaces

3.1.3. Software Interfaces

3.2. Functional Requirements

  • 1.) The system will be able to receive an audio file as input.
    • 1.1. The system will allow users to record an audio file.
    • 1.2. The system will allow users to upload an audio file.
  • 2.) The system will allow users to search their library
    • 2.1. The system will allow users to search by name of pdf
    • 2.2. The system will allow users to search for a specific idea.
  • 3.) The system will return a text summary of a meeting or conversation.
    • 3.1. The system will return the summary in a readable format such as a pdf.
      * 3.1.1 The system will display the text/pdf in the application for easy access.
    • 3.2. The system will allow the user to save the text/pdf.
      * 3.2.1. The system will allow users to save text/pdf on the cloud.
      * 3.2.2. The system will allow users to save text/pdf on the device.
    • 3.3. The system will allow users to delete the text/pdf.
    • 3.4. The system will allow users to share the pdf with others so that all parties have access to it.
    • 3.5. The system will indicate the tone used when converting an audio file to text.
    • 3.6. The system will highlight the most important points.

3.3. Quality Requirements

  • Usability:
    • The UI must be easily navigable and intuitive.
      • This is such that extensive labels are not necessary.
      • It should use intuitive and commonly used icons on buttons.
      • It should use intuitive gestures e.g. Scrolling.
    • The UI must be accessible for users that have disabilities.
      • The buttons should be large with clear borders to assist those with bad vision.
      • The metadata in components should be usable by screen readers to assist those without sight.
    • The UI should be responsive.
      • The UI transitions should not have any delay greater than 200ms.
  • Reliability:
    • There should be sufficient error handling.
      • Error recovery should take less than 5 seconds.
      • If an error occurs due to the system, errors should be given to the user explaining the issue.
      • If an error occurs due to the user, notifications should be given explaining the correct usage of the app.
      • No raw error messages from the code should be shown to the user.
    • Requests that the client makes to the server should always be received and processed.
      • No request should be discarded.
      • The client should get a response that corresponds to the request.
  • Scalability:
    • The system should be able to handle 100 concurrent user requests.
      • The database needs to handle at least 100 documents per user.
        • Document based databases are scalable.
      • Each service should be able to handle 10 concurrent user requests.
        • Multiprocessing.
        • Queues.
    • The translation unit and other services need to be loosely coupled.
      • This is to allow the translation unit to be used in other similar projects.
  • Availability:
    • The server should have a 95% uptime.
    • Every sent request should get a response from the server in a timely manner, i.e. less than 30 seconds.
      • A timer should be activated on each request sent.
      • If no response has been received before the timer reaches 0, the request should be resent.
  • Autonomy:
    • Once a user has made or uploaded a recording, it should be automatically sent to the API, where it will be processed by the various services without user guidance.
    • The result of the recording processing should be added to the database automatically and the new PDF should become viewable on the user's app.

3.4. Domain Model

domain model1

3.5. Subsystems

  • Client
    • UI
      • Authentication
        • Login
        • Signup
      • Home
        • Record
      • Settings
      • PDF Page
    • Recorder System
  • Server
    • PDF Manager
      • PDF Converter
    • Speech to Text
    • Summarizer
    • User Management
    • Database

3.6. Traceability Matrix

image

3.7. Architectural requirements and design documentation

Overview of architecture

image

Model View Controller

  • MVC is used for the frontend design to increase the usability and responsiveness of our app.
  • Easily expandable because units are loosely coupled which increases scalability.
  • It supports the use of test driven development because tests for different units can be developed independently from one another.
  • There is a separation of concerns that makes the code more maintainable.
  • The use of MVC increases usability by allowing for multiple views which support a more dynamic UI. This allows the system to be more responsive to user input.

Service Oriented

  • It increases reliability because services can be tested and implemented as separate units.
  • It increases scalability because independent services can change their throughput dynamically.
  • The Service Oriented Architecture allows for loose coupling between services as required by our clients.
  • Allows for easy maintenance.
  • Availability is increased because if one service is down it wont affect any other services.
  • Allows for increased autonomy because service consumers do not need to know the inner workings of a service to use the service.

Client-Server

  • Increases scalability because the server size can be easily expanded as it is necessary.
  • Increases availability because the server can be run on the cloud and accessed remotely from multiple platforms.
  • Increases reliability because taking and restoring backups are easy.

3.8. Deployment Model

image

Clone this wiki locally