Requirements

Partner Introduction and Project Background

Our client is Dr. Kavin Raju, a doctor in the NHS, who is keen to provide a proof of concept for the use of AI and smart glasses technology in the healthcare industry for clinical documentation. Since our client is partnering with IBM and Intel, we demonstrated use cases of their products within our project, including a demonstration of using IBM’s open-source AI models like the Granite large language model and embedding mode, and showing that features like audio processing can also work on Intel NPU processors.

Requirement Gathering

Requirements were gathered by discussing with our client Dr. Raju to understand the physician perspective of the project and the aims and goals that needed to be realized with the project. We also spoke with other medical professionals like Dr. Andrew Tan to gain an understanding of what features a doctor would require in the application.

Functional Requirements

Functional Requirements
Index	Feature	Sub-Index	Requirements	Description	Reasoning	Category
1	Audio Recording	1.1	Start, stop and pause audio recording	The smart glasses must allow users to start,, and stop audio recording through touch controls or via the app.	Essential for users to control recording during interactions.	Must Have
		1.2	Transfer over the recordings to your device	Audio recording should be sent over .	Allows transcript of the conversation to be generated.	Must Have
2	Transcription	2.1	Convert speech to text	The system must convert recorded audio into text accurately using offline speech recognition.	Accurate transcription is critical for creating useful summaries.	Must Have
		2.2	Store transcripts of the coversation on your device	Transcripts should be saved locally in an easily accessible format.	Local storage ensures accessibility and offline capabilities.	Must Have
		2.3	Speaker diarization	Be able to identify which voice is speaking to differentiate between doctor and patient.	Necessary to differentiate speakers and organize data effectively.	Should Have
3	Summarisation	3.1	Summarise transcript with use LLM	Ability to take unstructured conversation and generate summarised report.	Summarisation improves efficiency and usability for clinicians.	Must Have
		3.2	Fact Check	Ability to check the accuracy of the report generated against the transcript with the use of a RAG.	Allows doctors to identify potential mistakes in the report generated.	Could Have
4	User Interaction	4.1	Access information through an application	Users should be able to access the data and reports via an application.	Provides flexibility and remote access for users.	Must Have
		4.2	Ability to edit reports and transcriptions	Users should have the capability to modify generated reports for accuracy or personalization.	Allows users to refine AI-generated content to meet specific needs.	Should Have
		4.3	Ability to create an account	Users should be able to create an account in the case for multiple doctors needing to use the same device.	Allows doctors to keep their own patient information to be safe	Should Have
		4.4	Ability to add patients	Add patients and store relevant information	Allows the doctor to keep track of meeting and patients	Should Have
5	Integration	5.1	Deployment	Product should be packaged for deployment for ease of access for users.	Facilitates smooth onboarding and use by clinicians and hospitals.	Must Have
		5.2	NPU compatibility	Allows the product to run on an NPU	Allows the models to be processed faster	Could Have
		5.3	Intel OpenVINO	Allows the product to detect Intel chips	Allows to models to process faster	Could Have
6	Security	6.1	Login and logout	System sould allow users to log in with valid username and password and allow log-out when user requests it.	Protects sensitive data and ensures secure access.	Must Have
		6.2	Password Change	System should provide option to reset a forgotten password.	Critical for maintaining accessibility and security.	Should Have
		6.3	Processed Locally	Everything must be done offline and locally.	Ensures only authorized access to sensitive data and features.	Must Have

Non-Functional Requirements
Index	Feature	Description	Reasoning	Category
1	Usability	The UI should be intuitive, with minimal training needed for clinicians.	Saves time and reduces onboarding friction for new users.	Must Have
2	Reliability	The system should function 95% of the time without crashes or critical failures.	If the app does not work most of the time, then it would waste the doctors' time and would be less efficient than the previous documentation method.	Must Have
3	Performance	Transcription and summarisation should completed quickly.	Ensures the app provides a smooth and responsive user experience.	Could Have
4	Loading	The app should startup, navigate and close quickly.	Minimises time wasted for doctors as they will be quicker in using the programme	Should Have
5	Open Source	Everything we use must be open-source	Open source projects make their code publicly available, which means anyone can inspect it for security flaws or bugs. This transparency can build trust, as users and developers alike can verify what the software is doing.	Must Have

Personas