Introduction:
The sub system on which the report will be based on is Document Services & Digital ID. The system will be handling applications for passports, tax file numbers, and working with children checks and digital identification apart from mails. This subsystem is focused on this section of the system.
Complex Use Cases:
Use Case One: Trusted Digital Identity Framework
The use case associated with external actor is ‘Trusted Digital Identity Framework’. This use case is about verifying within the system. In order to create a digital id, customer will first go to the website and then click on register. Once, the register request is clicked, customer will see a form where all the data need to be entered. The customer have to enter the first name, middle name (if any) and last name. Then for each documents such as Australian Passport, New Zealand Passport, International Passport with a valid Australian Visa, Australian Driver License, Medicare Card, Proof of Age card, Tertiary student card or Keypass ID card, individual sections will be provided. Customer will input the unique identification number in each document in respective pages.
As the name is already provided, it is not required to provide in each page. Different data is present in different documents that is all the documents has different input criteria. Customer has to provide issue date for driving license number, customer has to provide reference number in order to validate the medicare card, and many more for individual documents. Once, all the data is submitted, to the system, customer will receive a token number through email which will be used at the time of hard copy verification. This token number will be used as a reference to the request submitted by the customer. Once the data is verified, customer will receive a receipt in the mail as well as hard copy which will have information like the name of the post office branch, postcode of the branch, a reference no, a unique sequence number, ID of the Australia Post staff, date and time of verification. In case the verification fails due to some unexpected reason, customer can reinitiate another request and current request and token will become invalid.
Use case name: Trusted Digital Identity Framework
Scenario: Create online Digital ID
Triggering event: Citizens of Australia can sign up for Digital ID
Brief description: Organization can verify the identity digitally instead of using individual documents
Actors: Staff, Customer
Related use cases: Necessary Documents, Passport Application, Tax File Number and Police Check Clearance
Stakeholders: Australia Post, Customer
Preconditions: Trusted Digital Identity Framework must be available
Document verification service must be available
Postconditions: Customer must get a receipt
Customer must receive a unique Digital ID
Customer can verify documents using Digital ID
Flow of activities: Actor System
Click on register Redirect user to a form
Input name and address Verify if name and address are valid
Input data for each document Verify if entered data is valid
Re-enter correct data If not then show error
Receive token as reference If data is valid
Exception conditions: Documents are incomplete
Unique identification number for any document is wrong
Activity Diagram:
Sequence Diagram:
Screen Design:
Test Plan:
Use Case 2: Receipt
This use case is for an internal staff of Australia Post. Name of this use case is receipt. The staff verify the identity of the person who has submitted a request for registration. The process of verification is out of scope because it is done manually but the input of the staff is very vital for the whole process. The staff checks the documents and decide whether the input documents and data are valid. If it is valid then user is registered into system and provided a receipt. This receipt contains all the required information like the unique Digital ID.
Use case name: Receipt
Scenario: Create online Digital ID
Triggering event: Staff
Brief description: Once it all has been done by the staff member, the system will generate the receipt with some details- Branch of the post office, Postcode, Reference number, Unique sequence number, Date and Time of verification.
Actors: Customer, Staff
Related use cases: None
Stakeholders: Australia Post Staff, Customer
Preconditions: Trusted Digital Identity Framework must be available
Documents must be available for check
Postconditions: Customer must get a receipt
Customer must receive a unique Digital ID
Flow of activities: Actor System
Staff request for documents of a specific request System shows all the documents uploaded by a customer order by document category
Staff check and mark documents as valid or invalid If document is marked as invalid, customer is informed through mail
Customer receive receipt If document is valid
Exception conditions: Uploaded document has corrupted
System is down
Activity Diagram:
Sequence Diagram:
Conclusion:
The report has successfully shown the logical and modelling requirements for developing the TFID system. It is assumed that the system will generate token for the user to check for request status because it is essential to have a unique key to track each process. As the customer side needs more focus and actions, the diagrams for external actor is much more elaborative. The screen is also generated for the customer.
Bibliography:
Felderer, M., & Herrmann, A. (2019). Comprehensibility of system models during test design: a controlled experiment comparing UML activity diagrams and state machines. Software Quality Journal, 27(1), 125-147.
Kharmoum, N., Ziti, S., Rhazali, Y., & Omary, F. (2019). AN AUTOMATIC TRANSFORMATION METHOD FROM THE E3VALUE MODEL TO UML2 SEQUENCE DIAGRAMS: AN MDA APPROACH. International Journal of Computing, 18(3), 316-330.
Septian, I., Alianto, R. S., & Gaol, F. L. (2017). Automated test case generation from UML activity diagram and sequence diagram using depth first search algorithm. Procedia computer science, 116, 629-637.
Viswanathan, S. E., & Samuel, P. (2016). Automatic code generation using unified modeling language activity and sequence models. IET Software, 10(6), 164-172.
