Analysis Report: System Design for SAP HANA ERP at Australia Post
VerifiedAdded on 2022/12/21
|14
|1984
|2
Report
AI Summary
This report presents a comprehensive system design for the implementation of SAP HANA ERP within Australia Post. It meticulously outlines both functional and non-functional requirements, utilizing the FURPS+ framework to ensure a robust and efficient system. A detailed stakeholder analysis identifies internal, external, operational, and executive stakeholders, accompanied by a targeted questionnaire designed to gather specific operational requirements. The report includes a domain model class diagram to represent the system's data structure and relationships, alongside use case descriptions, a use case diagram, an activity diagram, and a system sequence diagram to visually depict system processes and interactions. The analysis aims to provide a clear understanding of the proposed system's architecture and functionality, ensuring alignment with the business needs of Australia Post.

Running head: SYSTEM DESIGN
System Design
Name of the Student:
Name of the University:
Author Note
System Design
Name of the Student:
Name of the University:
Author Note
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

1
SYSTEM DESIGN
Table of Contents
Functional and Non-Functional Requirements................................................................................2
Function Requirements................................................................................................................2
Usability Requirements...............................................................................................................2
Reliability Requirements.............................................................................................................2
Performance Requirements..........................................................................................................2
Security Requirements.................................................................................................................3
FURPS+.......................................................................................................................................3
Design Constraints...................................................................................................................3
Implementation requirements..................................................................................................3
Stakeholder Analysis.......................................................................................................................3
Internal Stakeholders...................................................................................................................4
External Stakeholders..................................................................................................................4
Operational Stakeholders.............................................................................................................5
Executive Stakeholders................................................................................................................5
Questionnaire...................................................................................................................................5
Open Ended Questionnaire..........................................................................................................5
Close Ended Questionnaire..........................................................................................................6
Domain model class diagram...........................................................................................................6
Use Case description........................................................................................................................7
Fully developed use case description..............................................................................................7
Use Case Diagram...........................................................................................................................8
Activity Diagram.............................................................................................................................9
System Sequence Diagram............................................................................................................10
Bibliography..................................................................................................................................11
SYSTEM DESIGN
Table of Contents
Functional and Non-Functional Requirements................................................................................2
Function Requirements................................................................................................................2
Usability Requirements...............................................................................................................2
Reliability Requirements.............................................................................................................2
Performance Requirements..........................................................................................................2
Security Requirements.................................................................................................................3
FURPS+.......................................................................................................................................3
Design Constraints...................................................................................................................3
Implementation requirements..................................................................................................3
Stakeholder Analysis.......................................................................................................................3
Internal Stakeholders...................................................................................................................4
External Stakeholders..................................................................................................................4
Operational Stakeholders.............................................................................................................5
Executive Stakeholders................................................................................................................5
Questionnaire...................................................................................................................................5
Open Ended Questionnaire..........................................................................................................5
Close Ended Questionnaire..........................................................................................................6
Domain model class diagram...........................................................................................................6
Use Case description........................................................................................................................7
Fully developed use case description..............................................................................................7
Use Case Diagram...........................................................................................................................8
Activity Diagram.............................................................................................................................9
System Sequence Diagram............................................................................................................10
Bibliography..................................................................................................................................11

2
SYSTEM DESIGN
SYSTEM DESIGN
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

3
SYSTEM DESIGN
Functional and Non-Functional Requirements
Function Requirements
The functional requirements of the SAP HANA ERP system for the Australia-Post
organization are:
Database Services: The in-memory services would be provided by the system that would be
helpful of the organization in handling the transactions which are high speed and very helpful for
the multi tired storage system.
Advanced Analytics: The system should provide the organization with the option to process the
text, graphs and the series in time that would be helpful for deriving the results that would be
helpful for the business of the organization.
Data Access: The data access features in the system can be managed easily with the help of the
external and internal data access which can be replicated with the help of the system that would
be provide quality information suitable for the business of the organization.
Administration: The tool to be used for the project would be helpful in administrative set up and
monitoring the major business procedures of the organization.
Security: The project would be helpful for organization in encrypting the existing servers of the
organization and providing a secured communication for the organization.
Usability Requirements
The SAP HANA System provide supercomputing features to the users and the system
would be expected to deliver a conventional IT environment for the ERP implementation for the
Australia Post organization.
Reliability Requirements
The system used for the implementation of the SAP HANA should be reliable enough
and provides the uninterrupted services as a brief interruption would trouble the decision making
in the system.
SYSTEM DESIGN
Functional and Non-Functional Requirements
Function Requirements
The functional requirements of the SAP HANA ERP system for the Australia-Post
organization are:
Database Services: The in-memory services would be provided by the system that would be
helpful of the organization in handling the transactions which are high speed and very helpful for
the multi tired storage system.
Advanced Analytics: The system should provide the organization with the option to process the
text, graphs and the series in time that would be helpful for deriving the results that would be
helpful for the business of the organization.
Data Access: The data access features in the system can be managed easily with the help of the
external and internal data access which can be replicated with the help of the system that would
be provide quality information suitable for the business of the organization.
Administration: The tool to be used for the project would be helpful in administrative set up and
monitoring the major business procedures of the organization.
Security: The project would be helpful for organization in encrypting the existing servers of the
organization and providing a secured communication for the organization.
Usability Requirements
The SAP HANA System provide supercomputing features to the users and the system
would be expected to deliver a conventional IT environment for the ERP implementation for the
Australia Post organization.
Reliability Requirements
The system used for the implementation of the SAP HANA should be reliable enough
and provides the uninterrupted services as a brief interruption would trouble the decision making
in the system.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

4
SYSTEM DESIGN
Performance Requirements
The hardware used for the implementation of the project the should be able to deliver the
required performance that would be helpful in providing the results within the required time.
Security Requirements
The data used for the analysis with the help of the SAP HANA servers should be
encrypted and an encryption technique should be used for the development of the system security
features.
FURPS+
Design Constraints
The design of the should be efficient so that the users would be able to operate without
much hassle in the system.
Implementation requirements
The system implemented should be able to integrated efficiently the features of SAP
HANA with that of the business functionalities of the Australia Post.
Stakeholder Analysis
The stakeholders of the project for the SAP HANA ERP implementation of the Australia
Post organization are identified in this part of the report. The stakeholders have also been
analyzed and their categorizations have been accordingly. The stakeholder map provided below
has been used for the categorization and identification of the stakeholders as per their roles in the
system.
SYSTEM DESIGN
Performance Requirements
The hardware used for the implementation of the project the should be able to deliver the
required performance that would be helpful in providing the results within the required time.
Security Requirements
The data used for the analysis with the help of the SAP HANA servers should be
encrypted and an encryption technique should be used for the development of the system security
features.
FURPS+
Design Constraints
The design of the should be efficient so that the users would be able to operate without
much hassle in the system.
Implementation requirements
The system implemented should be able to integrated efficiently the features of SAP
HANA with that of the business functionalities of the Australia Post.
Stakeholder Analysis
The stakeholders of the project for the SAP HANA ERP implementation of the Australia
Post organization are identified in this part of the report. The stakeholders have also been
analyzed and their categorizations have been accordingly. The stakeholder map provided below
has been used for the categorization and identification of the stakeholders as per their roles in the
system.

5
External Internal
Owner, Sponsor Finance manager, board of directors
Users, IT staffs, Data analysts System Analysts, project manager,
Database administrator
Operations Executives
SYSTEM DESIGN
Internal Stakeholders
The internal stakeholders of the system are:
Stakeholders Descriptions
Finance manager The finance manager handles the finances which are related
directly to the systems and hence they are the internal
stakeholders.
Board of Directors The board of directors make the decision on system
development.
System Analyst The system analyst would be analyzing the main
functionalities of the system.
Project Manager The project manager is linked directly with the development of
the system.
Database Administrator The database administrator would be performing the
administrations on the system.
External Stakeholders
The external stakeholders of the system are:
External Internal
Owner, Sponsor Finance manager, board of directors
Users, IT staffs, Data analysts System Analysts, project manager,
Database administrator
Operations Executives
SYSTEM DESIGN
Internal Stakeholders
The internal stakeholders of the system are:
Stakeholders Descriptions
Finance manager The finance manager handles the finances which are related
directly to the systems and hence they are the internal
stakeholders.
Board of Directors The board of directors make the decision on system
development.
System Analyst The system analyst would be analyzing the main
functionalities of the system.
Project Manager The project manager is linked directly with the development of
the system.
Database Administrator The database administrator would be performing the
administrations on the system.
External Stakeholders
The external stakeholders of the system are:
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

6
SYSTEM DESIGN
Stakeholders Descriptions
Owners The owners would not be working on the system, they would
only be linked with revenues of the system.
Sponsors The sponsors would be sponsoring the system development,
however, they would be receiving the benefits from the
system.
Users The users in the system would be the main stakeholders for
whom the system is being developed.
IT Staffs The IT staffs would be performing the support duties in the
system and hence, they would be linked directly with the
system.
Data Analysts The data analyst would be performing the analysis on the
system and hence, they would be end users.
Operational Stakeholders
The operational stakeholders of the system are:
Stakeholders
Users
IT staffs
Data Analysts
System Analysts
Database Administrator
Project Manager
Executive Stakeholders
The executive stakeholders of the system are:
Stakeholders
Owner
Finance Manager
Sponsor
SYSTEM DESIGN
Stakeholders Descriptions
Owners The owners would not be working on the system, they would
only be linked with revenues of the system.
Sponsors The sponsors would be sponsoring the system development,
however, they would be receiving the benefits from the
system.
Users The users in the system would be the main stakeholders for
whom the system is being developed.
IT Staffs The IT staffs would be performing the support duties in the
system and hence, they would be linked directly with the
system.
Data Analysts The data analyst would be performing the analysis on the
system and hence, they would be end users.
Operational Stakeholders
The operational stakeholders of the system are:
Stakeholders
Users
IT staffs
Data Analysts
System Analysts
Database Administrator
Project Manager
Executive Stakeholders
The executive stakeholders of the system are:
Stakeholders
Owner
Finance Manager
Sponsor
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

7
SYSTEM DESIGN
Board of Directors
Questionnaire
The questionnaire is developed for gathering the requirements of the system. This would
be helpful in understanding the requirement of implementation for SAP HANA ERP for the
Australian Post Organization. The questionnaire is targeted towards the data analysts who would
be working in the company. These would be helpful for the understanding of the requirements of
the system.
Open Ended Questionnaire
What are the difficulties in the current system?
What are the benefits that you are looking for in the newly developed system?
What are the aspects of ERP that you are looking forward to in the system that is to be
developed?
What are your views on the Current ERP development of the organization?
How are you going to utilize the system for the benefit for both you and your company?
Close Ended Questionnaire
Do you think the development of the system would be beneficial for the workers in your
organization?
Do you think the system would be helpful for the organization?
Will you be able to perform all the business procedures in the system which would be
developed?
Will the developed system be helpful in improving the business procedures of the
company?
SYSTEM DESIGN
Board of Directors
Questionnaire
The questionnaire is developed for gathering the requirements of the system. This would
be helpful in understanding the requirement of implementation for SAP HANA ERP for the
Australian Post Organization. The questionnaire is targeted towards the data analysts who would
be working in the company. These would be helpful for the understanding of the requirements of
the system.
Open Ended Questionnaire
What are the difficulties in the current system?
What are the benefits that you are looking for in the newly developed system?
What are the aspects of ERP that you are looking forward to in the system that is to be
developed?
What are your views on the Current ERP development of the organization?
How are you going to utilize the system for the benefit for both you and your company?
Close Ended Questionnaire
Do you think the development of the system would be beneficial for the workers in your
organization?
Do you think the system would be helpful for the organization?
Will you be able to perform all the business procedures in the system which would be
developed?
Will the developed system be helpful in improving the business procedures of the
company?

8
SYSTEM DESIGN
Domain model class diagram
The class diagram has been used here for the representation of the classes in the system.
The attributes for each of the classes has also be included in the diagram. From the above
diagram, it could be observed that the major classes of the system are the clients, letters,
addresses, the staff, post and the admin. It could be analysed that any one admin could post
several posts and any one staff could post several posts. Any one client could have one letter and
any one post could have several posts. Any one client could have several addresses and all the
classes are associated among one another.
Use Case description
Use Case Descriptions
Login The admin or the staff would be able to login to the system.
Register The admin would be adding new staffs into the system.
Manage Details The details of the staffs would be access by the administrator.
Delete Users The admin would be able to delete the account of the users.
Close Accounts The staff accounts can be closed with the help of the administrator.
Report The report of the businesses would be made available to the
admin.
View Details The details of business would be viewed by the admin
SYSTEM DESIGN
Domain model class diagram
The class diagram has been used here for the representation of the classes in the system.
The attributes for each of the classes has also be included in the diagram. From the above
diagram, it could be observed that the major classes of the system are the clients, letters,
addresses, the staff, post and the admin. It could be analysed that any one admin could post
several posts and any one staff could post several posts. Any one client could have one letter and
any one post could have several posts. Any one client could have several addresses and all the
classes are associated among one another.
Use Case description
Use Case Descriptions
Login The admin or the staff would be able to login to the system.
Register The admin would be adding new staffs into the system.
Manage Details The details of the staffs would be access by the administrator.
Delete Users The admin would be able to delete the account of the users.
Close Accounts The staff accounts can be closed with the help of the administrator.
Report The report of the businesses would be made available to the
admin.
View Details The details of business would be viewed by the admin
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

9
SYSTEM DESIGN
Logout The staffs and the admin would be able log out of the system.
Fully developed use case description
Use Case Name Create Users
Scenario The administrator would be creating a new user for the new staff
into the system.
Triggering Event The inclusion of a new staff in the system.
Brief Description The administrator would be creating a new user for the new staff
into the system.
Actors The admin, the staff
Related Use Cases Manage Details
Stakeholders Users, Administrator
Preconditions Login
Post conditions Manage Details
Flow of Activities Users System
1. Login
2. Create new user
3. View details
1. Authenticate
2. Store details
3. Show details
Exception Conditions The admin would not be authenticated if they are provided with
the incorrect details.
SYSTEM DESIGN
Logout The staffs and the admin would be able log out of the system.
Fully developed use case description
Use Case Name Create Users
Scenario The administrator would be creating a new user for the new staff
into the system.
Triggering Event The inclusion of a new staff in the system.
Brief Description The administrator would be creating a new user for the new staff
into the system.
Actors The admin, the staff
Related Use Cases Manage Details
Stakeholders Users, Administrator
Preconditions Login
Post conditions Manage Details
Flow of Activities Users System
1. Login
2. Create new user
3. View details
1. Authenticate
2. Store details
3. Show details
Exception Conditions The admin would not be authenticated if they are provided with
the incorrect details.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

10
SYSTEM DESIGN
Use Case Diagram
The use case diagram here portrays the major actors of Australia posts. The major
activity performed in the system by both the admin and staff actors in the system. from the above
image, it could be observed that the major use cases of the system are the login, register, manage
details, delete user, close account, report, view details and logout. The main actors of the system
are the staff and the admin. The use cases of admin could be categorised as login, register,
manage details, delete user, close account, report, and logout. The use case of the staff could be
categorised as login, report, view details and logout.
SYSTEM DESIGN
Use Case Diagram
The use case diagram here portrays the major actors of Australia posts. The major
activity performed in the system by both the admin and staff actors in the system. from the above
image, it could be observed that the major use cases of the system are the login, register, manage
details, delete user, close account, report, view details and logout. The main actors of the system
are the staff and the admin. The use cases of admin could be categorised as login, register,
manage details, delete user, close account, report, and logout. The use case of the staff could be
categorised as login, report, view details and logout.

11
SYSTEM DESIGN
Activity Diagram
The activity diagram has been used here to provide the details of the flow of activities
throughout the system. The main lanes in the system are the Users, admin and system. From the
above image, it could be observed that the main activities included in the system are displayed.
The actors are the user, admin and the system. The activities start when any user logs on into the
system. If the login details are correct then details would be recorded and if the login details are
not authentic then it would prompt the user to register. The main activity of the system is to view
the details and then manage them.
SYSTEM DESIGN
Activity Diagram
The activity diagram has been used here to provide the details of the flow of activities
throughout the system. The main lanes in the system are the Users, admin and system. From the
above image, it could be observed that the main activities included in the system are displayed.
The actors are the user, admin and the system. The activities start when any user logs on into the
system. If the login details are correct then details would be recorded and if the login details are
not authentic then it would prompt the user to register. The main activity of the system is to view
the details and then manage them.
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide
1 out of 14
Related Documents

Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
Copyright © 2020–2025 A2Z Services. All Rights Reserved. Developed and managed by ZUCOL.