BACKGROUND Your business case has been accepted and project is moving forward into the next phase of the SDLC. Preliminary investigation with intensive fact finding has been carried out with the aim of understanding the requirements better. A series of techniques were deployed for elicitation. Below is the list of requirements elicited. Business processes, assumptions and constraints are documented together with the list of requirements gathered and listed below. Complete this assignment using the given requirement sets and complete the tasks as listed. You are a business analyst for this project and are tasked to prepare the 'Requirement Package'. ELICITED REQUIREMENTS: For you to use in your Requirement Definition Report: Analyse the below information to fulfil the tasks assigned within the Analysis Phase of the SDLC (in no particular order): a. Health portal to include all functional requirements for individuals seeking medical care and those offering medical services. This should also include staff in the Ministry as well as support staff. Stakeholders are in line to proceed with a portal to include patients, medical provider as well as associates from Ministry of Health to have a 'one system for all portal for this project. Individual seeking medical care is someone who has a National Health Index (NHI) and who is 18 years and older. Individual under 18 years old will need a parent/guardian to be given proxy to their access. NHI is a unique data for each individual who seek medical care in New Zealand. b. Priority granted to centralise a health care portal for every person in New Zealand, both receiving and offering medical services. Personalisation is given high priority, to allow full control of the look and feel of the portal. While simplicity is a key objective for the portal, allowing user the ability to engage in customisation is also a key requirement. Examples of this may include adjusting font size for visually impaired users, audible caption that can be read back to the user and also a system that is rich in information for all users. Settings of customisation will be managed within each profile of an NHI holder. c. Each user can maintain account details and personal profile in the system but medical records of each NHI holder will have read only access for medical results of the NHI holder from tests or notes/comments created by medical staff. This is classified as electronic health record (EHR). Log is created and recorded when access or updates of EHR is performed. d. Portal should be available in both desktop and handheld devices. Functions are mostly available in multiple environments, but some functions are only available either in desktop or handheld only. Each iteration or release will need to be fully tested in test environments before it is deployed in production environment. A search function is available to all users. Additional access for medical providers to search medical databases and references. e. For access availability of handheld devices, biometric information can be managed by each account holder. Diagnostic devices will also use biometrics to authenticate users. When a biometric measurement device is connected, all collected data is captured and stored in the cloud solution. f. Dietary, allergy, medical history and test results are stored under personal biodata. This can only be updated and verified by medical providers. Reports can be generated and updated at any time when required. Reminders can be sent out by medical providers if required. g. Portal will have a dashboard unique to individual for all users. Medical providers and medical assistants can manage individuals' EHR via the dashboard. Dashboard can include monitoring of progress of individuals, types of procedures, usage of medical equipment as well as rostering schedules. Customisation of dashboard is restricted to types of users. h. All government-held information should have a protective marking or classification to ensure it is treated securely. Namely, the Government Security Classification System sets out the 'level of classification that should be applied to official government-held information, and a 'level' is allocated depending on the level of risk if the information were released or compromised. Data restriction tags are assigned to types of information stored within the system. Verifications of records and data security tags are recorded and stored centrally for the use of Ministry of Health. i. The Privacy Act requires agencies to take reasonable steps to protect that information from unauthorised disclosure or access by using: i. SEEMail or password-protected attachments ii. Government Communications Security Bureau (GCSB)-encrypted access iii. Encryption in transit (for example, Transport Layer Security (TLS) for email transfer) iv. RealMe login authentication. j. Due to the sensitivity of the information stored in the systems, all individuals' medical information must use GCSB-encrypted access to protect the data sensitivity and privacy. When there are operations that require medical related activities to be performed or off-site workings, encryption is applied to mobile devices communicating over public infrastructure, the Internet or non-agency-controlled networks. RealMe login authentication can be deployed as an alternative. k. Routine daily backups of data will be performed automatically to multiple cloud environment to maintain data security. Reports of maintenance and security patches are managed by Ministry of Health. Scheduling of medical providers and assistance are also accessible via portal to better manage resources and scalability of deploying the accurate balance of staff across the 4 regions. 1. Health portal will be deployed to all public health care providers regionally with single sign on (SSO). All end-users can be authenticated using NHI, date of birth and other personal details. m. Aims to improve and incorporate the new requirements to allow monitoring of performance of all health providers by the Ministry of Health. It will also enhance connectivity from all health providers (e.g., medical centres, clinics, hospitals etc) to the Ministry to ensure thorough and uniform communications nationwide. n. Reports can be requested, generated compiled to improve the andardization of services across the country. Medical assistants can manage the schedules of medical providers to assist and maintain administrative matters for their assigned medical providers. Medical assistants may include therapists, nurses, supervisors and specialised worker who work closely with medical providers offering medical care to NHI holders. 0. HealthNZ portal will be compatible with all operation systems for devices inclusive of handheld hardware. p. Access to the HealthNZ portal will be a multi-tier access control list (ACL). Current roles in are list below: Patient individuals receiving medical care Medical Provider individuals offering medical care Medical Assistant - individuals assisting medical providers MOH staff - staff from the Ministry of Health Admin staff-administrative staff with specific access Access coordinator - administrators with full access to maintain roles 4. Add-on functions include: Chatbot, live sessions, virtual diagnostics, online breakout room and online consultation with nurses etc. These can be added onto the portal via customisations. Requests of add-ons are handled by admin staff. r. Personalisation and customisation allow individuals to customise their profile. Some profiles are editable (e.g., preferred name, contact number, pictures) while some information is non- editable (e.g., medical history, legal name, allergies, history of treatments, or on-going treatments or conditions). Verification of all changes will need to be validated as security measure. s. Access coordinators have full access to all key functions of the portal. This role maintains the ACL for the portal accordingly. t. Chatbots to answer simple questions will available 24/7 and will operate along with healthline with 0800 numbers. It is powered by rules and Artificial Intelligence (AI) with a knowledge base on health questions. Chatbots will be available 24/7, from any location, via all types of hardware. The knowledge base is continuously added via AI technology. The knowledge base is built by both medical and MOH staff. u. Video chats can be requested by patients or medical providers and a notification will be issued with a code for all requested parties to join the chat. v. Recalls or reminders for medicines, tests or follow ups will be posted on the portal together with test results conducted for each individual. w. Live events and webinars are new services to be included. These services are only available for medical providers and assistants. This feature will improve communication, collaboration and discussions of medical issues amongst medical staff that are located across the region. Live events and webinars scheduling will need to be requested and confirmed before the events can be advertised. Event codes will be issued once confirmation is received. Date, time and duration will need to be provided for each request. x. Recordings of all online events will be available automatically. There is a 5 Gb limitation of each file. Notification is sent to admin staff after each recording is published. y. My_Notes is a feature for all users to create as questions or advice that is private to each user. This feature supports multiple file types (e.g. pictures, videos or downloads). All files will be automatically backed up every 12 hours. Virus scans of all files will be done daily. This requirement is to offer reliability, sustainability, and security of the existing and new features. z. A search engine is also built in to allow all users to search using keywords for items they have access to within the health portal. This feature is needed to allow for improvement in building up knowledge bases and information management for each user for their topic of interest. TASKS 1. Requirements Definition Report (40 marks) You are required to prepare a requirements definition report by: a. Re-writing the system requirements (above) to meet the requirements definition format. b. Re-organise the re-written system requirements into functional (FR) and non- functional requirements (NFR). 2. User Story (20 marks) Using the format of a user story, pick 2 out of 3 (of the options below) and prepare a set of user stories: a. Staff from Ministry of Health b. Medical staff* c. Patient/guardian of patient* As a , I wanteed to so that /in order to" NOTE: you are exp to create at least 3 separate user stories for EACH of the 2 chosen actors. *can be specific (e.g., GP, surgeon, nurse, child, elderly etc.) or as generic medical staff, patient/guardian. 3. Use Case Model (60 marks) a. Draw a Use Case Model from your Requirements Definition Report. Model functional requirements (FR) only. Only model use cases with actors. b. Insert your use case model into the correct section in the template. Your model must be clearly legible - please also include a link to the original UCM if created on Draw.io 4. Use Case Documentation (30 marks) a. Write the use case documentation for one main use case from your model from Task 3. Your documentation is expected to be detailed and well thought-out. 5. Activity Diagrams (30 marks) a. Draw an activity diagram to demonstrate the process for the use case documented in Task 4. If your use case includes many branching activities, focus on the main activity. b. Insert your activity diagram into the correct section in the template. Your diagram must be clearly legible. BACKGROUND Your business case has been accepted and project is moving forward into the next phase of the SDLC. Preliminary investigation with intensive fact finding has been carried out with the aim of understanding the requirements better. A series of techniques were deployed for elicitation. Below is the list of requirements elicited. Business processes, assumptions and constraints are documented together with the list of requirements gathered and listed below. Complete this assignment using the given requirement sets and complete the tasks as listed. You are a business analyst for this project and are tasked to prepare the 'Requirement Package'. ELICITED REQUIREMENTS: For you to use in your Requirement Definition Report: Analyse the below information to fulfil the tasks assigned within the Analysis Phase of the SDLC (in no particular order): a. Health portal to include all functional requirements for individuals seeking medical care and those offering medical services. This should also include staff in the Ministry as well as support staff. Stakeholders are in line to proceed with a portal to include patients, medical provider as well as associates from Ministry of Health to have a 'one system for all portal for this project. Individual seeking medical care is someone who has a National Health Index (NHI) and who is 18 years and older. Individual under 18 years old will need a parent/guardian to be given proxy to their access. NHI is a unique data for each individual who seek medical care in New Zealand. b. Priority granted to centralise a health care portal for every person in New Zealand, both receiving and offering medical services. Personalisation is given high priority, to allow full control of the look and feel of the portal. While simplicity is a key objective for the portal, allowing user the ability to engage in customisation is also a key requirement. Examples of this may include adjusting font size for visually impaired users, audible caption that can be read back to the user and also a system that is rich in information for all users. Settings of customisation will be managed within each profile of an NHI holder. c. Each user can maintain account details and personal profile in the system but medical records of each NHI holder will have read only access for medical results of the NHI holder from tests or notes/comments created by medical staff. This is classified as electronic health record (EHR). Log is created and recorded when access or updates of EHR is performed. d. Portal should be available in both desktop and handheld devices. Functions are mostly available in multiple environments, but some functions are only available either in desktop or handheld only. Each iteration or release will need to be fully tested in test environments before it is deployed in production environment. A search function is available to all users. Additional access for medical providers to search medical databases and references. e. For access availability of handheld devices, biometric information can be managed by each account holder. Diagnostic devices will also use biometrics to authenticate users. When a biometric measurement device is connected, all collected data is captured and stored in the cloud solution. f. Dietary, allergy, medical history and test results are stored under personal biodata. This can only be updated and verified by medical providers. Reports can be generated and updated at any time when required. Reminders can be sent out by medical providers if required. g. Portal will have a dashboard unique to individual for all users. Medical providers and medical assistants can manage individuals' EHR via the dashboard. Dashboard can include monitoring of progress of individuals, types of procedures, usage of medical equipment as well as rostering schedules. Customisation of dashboard is restricted to types of users. h. All government-held information should have a protective marking or classification to ensure it is treated securely. Namely, the Government Security Classification System sets out the 'level of classification that should be applied to official government-held information, and a 'level' is allocated depending on the level of risk if the information were released or compromised. Data restriction tags are assigned to types of information stored within the system. Verifications of records and data security tags are recorded and stored centrally for the use of Ministry of Health. i. The Privacy Act requires agencies to take reasonable steps to protect that information from unauthorised disclosure or access by using: i. SEEMail or password-protected attachments ii. Government Communications Security Bureau (GCSB)-encrypted access iii. Encryption in transit (for example, Transport Layer Security (TLS) for email transfer) iv. RealMe login authentication. j. Due to the sensitivity of the information stored in the systems, all individuals' medical information must use GCSB-encrypted access to protect the data sensitivity and privacy. When there are operations that require medical related activities to be performed or off-site workings, encryption is applied to mobile devices communicating over public infrastructure, the Internet or non-agency-controlled networks. RealMe login authentication can be deployed as an alternative. k. Routine daily backups of data will be performed automatically to multiple cloud environment to maintain data security. Reports of maintenance and security patches are managed by Ministry of Health. Scheduling of medical providers and assistance are also accessible via portal to better manage resources and scalability of deploying the accurate balance of staff across the 4 regions. 1. Health portal will be deployed to all public health care providers regionally with single sign on (SSO). All end-users can be authenticated using NHI, date of birth and other personal details. m. Aims to improve and incorporate the new requirements to allow monitoring of performance of all health providers by the Ministry of Health. It will also enhance connectivity from all health providers (e.g., medical centres, clinics, hospitals etc) to the Ministry to ensure thorough and uniform communications nationwide. n. Reports can be requested, generated compiled to improve the andardization of services across the country. Medical assistants can manage the schedules of medical providers to assist and maintain administrative matters for their assigned medical providers. Medical assistants may include therapists, nurses, supervisors and specialised worker who work closely with medical providers offering medical care to NHI holders. 0. HealthNZ portal will be compatible with all operation systems for devices inclusive of handheld hardware. p. Access to the HealthNZ portal will be a multi-tier access control list (ACL). Current roles in are list below: Patient individuals receiving medical care Medical Provider individuals offering medical care Medical Assistant - individuals assisting medical providers MOH staff - staff from the Ministry of Health Admin staff-administrative staff with specific access Access coordinator - administrators with full access to maintain roles 4. Add-on functions include: Chatbot, live sessions, virtual diagnostics, online breakout room and online consultation with nurses etc. These can be added onto the portal via customisations. Requests of add-ons are handled by admin staff. r. Personalisation and customisation allow individuals to customise their profile. Some profiles are editable (e.g., preferred name, contact number, pictures) while some information is non- editable (e.g., medical history, legal name, allergies, history of treatments, or on-going treatments or conditions). Verification of all changes will need to be validated as security measure. s. Access coordinators have full access to all key functions of the portal. This role maintains the ACL for the portal accordingly. t. Chatbots to answer simple questions will available 24/7 and will operate along with healthline with 0800 numbers. It is powered by rules and Artificial Intelligence (AI) with a knowledge base on health questions. Chatbots will be available 24/7, from any location, via all types of hardware. The knowledge base is continuously added via AI technology. The knowledge base is built by both medical and MOH staff. u. Video chats can be requested by patients or medical providers and a notification will be issued with a code for all requested parties to join the chat. v. Recalls or reminders for medicines, tests or follow ups will be posted on the portal together with test results conducted for each individual. w. Live events and webinars are new services to be included. These services are only available for medical providers and assistants. This feature will improve communication, collaboration and discussions of medical issues amongst medical staff that are located across the region. Live events and webinars scheduling will need to be requested and confirmed before the events can be advertised. Event codes will be issued once confirmation is received. Date, time and duration will need to be provided for each request. x. Recordings of all online events will be available automatically. There is a 5 Gb limitation of each file. Notification is sent to admin staff after each recording is published. y. My_Notes is a feature for all users to create as questions or advice that is private to each user. This feature supports multiple file types (e.g. pictures, videos or downloads). All files will be automatically backed up every 12 hours. Virus scans of all files will be done daily. This requirement is to offer reliability, sustainability, and security of the existing and new features. z. A search engine is also built in to allow all users to search using keywords for items they have access to within the health portal. This feature is needed to allow for improvement in building up knowledge bases and information management for each user for their topic of interest. TASKS 1. Requirements Definition Report (40 marks) You are required to prepare a requirements definition report by: a. Re-writing the system requirements (above) to meet the requirements definition format. b. Re-organise the re-written system requirements into functional (FR) and non- functional requirements (NFR). 2. User Story (20 marks) Using the format of a user story, pick 2 out of 3 (of the options below) and prepare a set of user stories: a. Staff from Ministry of Health b. Medical staff* c. Patient/guardian of patient* As a , I wanteed to so that /in order to" NOTE: you are exp to create at least 3 separate user stories for EACH of the 2 chosen actors. *can be specific (e.g., GP, surgeon, nurse, child, elderly etc.) or as generic medical staff, patient/guardian. 3. Use Case Model (60 marks) a. Draw a Use Case Model from your Requirements Definition Report. Model functional requirements (FR) only. Only model use cases with actors. b. Insert your use case model into the correct section in the template. Your model must be clearly legible - please also include a link to the original UCM if created on Draw.io 4. Use Case Documentation (30 marks) a. Write the use case documentation for one main use case from your model from Task 3. Your documentation is expected to be detailed and well thought-out. 5. Activity Diagrams (30 marks) a. Draw an activity diagram to demonstrate the process for the use case documented in Task 4. If your use case includes many branching activities, focus on the main activity. b. Insert your activity diagram into the correct section in the template. Your diagram must be clearly legible