1. Introduction

In society, today technology has improved making it easy for the system to be developed in such a way that it can capture every detail. When designing a software interface it is always good to use different types of models that will ensure the software has been designed considering every user and also nothing is to be forgotten during the design and development process. This will use different unified modeling language to represent both staff and financial management systems the way they are supposed to be before being developed.

2. Case Study taken into consideration

In this case, we are considering to design staff and financial management systems that will be performing various functions. In this case, we have a staff management system that ensures the following:

• Payments are done on time.
• Schedules are provided weekly.
• Employees records have been properly secured among many others that are common within the staff management system

The same case applies to the financial management system which has many functions but the following are being considered while making the system:

• Proper recording of cash flows.
• Analyzing both profit and loss.
• Submissions of taxes.

3. Scope

The system mainly has been set to calculate taxes according to the laws given by the government which has been integrated into the system. The system uses provides major functions to its registered customers and the information gotten is shared with the third party.

4. Package Diagram

5. Actors List and Description

Actor Type and its Stereotype

The employee is among the provided classes and its type is abstract. It represents all the employees in the staff management system.

Actor Description

The employee performs a various function which is normally the basic routines of the company.

Actor Relationships

• System users
• Accountant
• Manager
• Admin

6. Use case

Use Case	Payment
Actors	Main Admin
Description	The use case handles how the staff is being paid while using the system. In this section, the number of hours worked by each staff is first checked before any other continues to ensure that each person goes away with the required amount of money that they are supposed to be paid.
Pre-Condition	All staff should try to reach the number of hours that they are supposed to cover every week.
Post-Condition	Staffs are the ones receiving the salary.
Normal Flow of Events	1. Staff signs in as usual whenever they come or leave work.2. The system compares if the number of hours attended by staff to provide accurate detail. 3. The system confirms the number of hours 4. Staff details are saved in the database based on the number of hours they come to work. 5. The system analysis the reports and sends them to the main admin. 6. Main admin logs in to the system and checks the report first before anything is done. 7. Main admin calculates the total amount incurred and checks what in the bank as the final procedure8. Staff finally receive their payment
Alternate Flow of Event	A1. In case a staff leaves without doing a confirmation that they are leaving work and going home. Then they are supposed to talk to the system used to try and feed in their details directly to the database for recording purposes.

Use Case	Customer Registration
Actors	Customer
Description	The use case shows how new customers are registered to the system. This process occurs when someone is new to the system. And for them to be fully registered they must issue proper credentials which include the following: First name Last name passwordEmail Address Credit card number Local branch
Pre-Condition	Customer is not recognized by the system
Post-Condition	Customer is registered and recognized
Normal Flow of Events	1. Customer visits the website for the first time 2. The customer clicks on the register button and is taken to the registration page. 3. The customer enters the required personal credentials.4. Verificafication of the email is done to ensure that it is working and legit.5. User debit or credit card is also verified to ensure that it is also legit.6. Account is finally created after the debit or credit card has been verified where the user’s details will be saved.7. A link is sent to the user’s email which will help in verifying the account where the user can click and will be taken to the webpage.8. This marks a successful creation of the account since the customer is taken to the login page of the website for them to join.
Alternate Flow of Event	A1: In case the user provides an invalid email to the system they will be prompt to enter an appropriate email for them to continue to the next process. A2: Also when the credit card details are incorrect then the customer will be prompt to give the required details before creating an account with the system.

7. Use Case Diagrams 

i. Staff management

ii. Financial management 

8. Activity Diagrams

i. Staff management

ii. Financial management 

9. Interaction Overview Diagrams

10. Class Descriptions of the system

<<stereotype>> Class Name	<<entity>> Employee
Description	It represents the attribute that each employee should possess while in the system.
Relationship	Relationships: Search for task Add other employees Payment Inherited by: UserClass
Attributes	Employee_idEmployee_ful_nameEmployee_locationEmployee_emailEmployee_passwordEmployee_address
Responsibilities	The employee performs different functions while in the system. They are the people in charge of performing a daily routine. And also they can perform other activities such as:addEmployee()search()
Business Rules	Employees must provide all their credentials for security reasons.
Complexity	Medium

11. Class Diagrams of the system

i. Staff management

ii. Financial management 

12. Sequence Diagram of the system

i. Staff management

ii. Financial management 

13. User Interface

i. Employee interface 

i. Admin interface 

14. Operational Requirements of the system

Scalability – the system will be designed in such a way that it will ensure that there will still be room for upgrading the system without it interfering with how the system works.

Security – the system has put in place proper authentication protocol that will ensure unauthorized users from getting access to information from the system. Also, another security measure is that users have awarded different levels of access to the system. This prevents different users from accessing files and information that they are not supposed to view.

Reliability – the system has been made to be more reliable since it can be accessed by different types of portable devices.

15. Environmental Consideration

Below are some of the software used in the designing process and those that will be used in developing the final working system.

Implementation Tools:

• Visual Studio. NET 2019 Professional
• NetBeans

Following is a list of the languages to be used, but not limited to:

• Javascript
• Bootstrap
• Python Django or Java)
• ASP.NET
• HTML, CSS
• Ajax

16. Test Plan

Objective:

The system should be able to handle high traffic when in use and it should be able to verify every user. From which they will be able to log in and access the system properly. The systems have a suitable interface on both the staff and the financial side of the management system. The following are some of the people and procedures involved in the system

People and Procedures:

• Employees
• Accountant
• Customers
• System users
• Manager

The following are some of the processes associated with the system:

• Task management subsystem
• Financial management subsystem
• Stock updating subsystem
• Leave subsystem
• Stock ordering subsystem
• Maintenance subsystem
• Payment subsystem

Overall Acceptance Criteria:

From the system, it is only the authorized users who have access to use the system. Every user is supposed to access the files and parts of the system that they are authorized to do. Major activities being conducted via the system must be reported to the admin weekly.

Method

The system should be tested properly where each user tries to verify themselves and check if all the validations are functioning properly. Before the system is presented to the final clients it should be tested many times to ensure all capabilities have been reached.

Error report:

In case of any errors occurring in this testing phase, they should be reported and corrected as soon as possible before other major steps are considered. This is to ensure that the system is free from bugs and can be launched in the market.

.

17. Test Cases

Identification: Registration

Purpose: It is a test case for a new employee trying to register with the system.

Prerequisites: Employee should use an active email account that is not found in our system

Administrative Details:	Actions	Expected Output	Actual Output
Full Name John DoeEmail Johndoe@gmail.com LocationKapsawetPassword 012345 Confirm Password 012345 Address425-001	A new employee inputs their credentials and clicks the register button. This will try and validate the email entered before being added to the system database	The employee has successfully register themselves to the system.	The employee is redirected to the login page after a successful registration.
Full Name Tevo MarkEmail tevomark@gmail.com LocationKapsawetPassword 30302 Confirm Password 30302 Address47825-001	The employee enters an email address that is not valid after filling other entries correctly	The registration process will not be completed since the employee email is invalid	The employee is prompt with a message showing that the is invalid

References

Yue, T., Briand, L. C., & Labiche, Y. (2013). Facilitating the transition from use case models to analysis models: Approach and experiments. ACM Transactions on Software Engineering and Methodology (TOSEM), 22(1), 1-38.

Herchi, H., & Abdessalem, W. B. (2012). From user requirements to the UML class diagram. arXiv preprint arXiv:1211.0713.

Fujiwara, S., Munakata, K., Maeda, Y., Katayama, A., & Uehara, T. (2011). Test data generation for web application using a UML class diagram with OCL constraints. Innovations in Systems and Software Engineering, 7(4), 275-282.

Stikkolorum, D. R., Ho-Quang, T., & Chaudron, M. R. (2015, August). Revealing students’ UML class diagram modeling strategies with webuml and logviz. In 2015 41st Euromicro Conference on Software Engineering and Advanced Applications (pp. 275-279). IEEE.

Nikiforova, O. K. S. A. N. A., Pavlova, N. A. T. A. L. J. A., Gusarovs, K. O. N. S. T. A. N. T. I. N. S., Gorbiks, O. L. E. G. S., Vorotilovs, J. U. R. I. J. S., Zaharovs, A., … & Sejans, J. A. N. I. S. (2012, April). Development of the tool for transformation of the two-Hemisphere model to the UML class diagram: technical solutions and lessons learned. In Proceedings of the 5-the International Scientific Conference „Applied Information and Communication Technologies (pp. 11-19).

Parada, A. G., Siegert, E., & De Brisolara, L. B. (2011, November). Generating Java code from UML class and sequence diagrams. In 2011 Brazilian Symposium on Computing System Engineering (pp. 99-101). IEEE.

Ibrahim, N., Ibrahim, R., Saringat, M. Z., Mansor, D., & Herawan, T. (2011, April). Definition of Consistency Rules between UML Use Case and Activity Diagram. In International Conference on Ubiquitous Computing and Multimedia Applications (pp. 498-508). Springer, Berlin, Heidelberg.

Jha, P., Jena, P. P., & Malu, R. K. (2014). Estimating software development effort using the UML use case point (UCP) method with a modified set of environmental factors. International Journal of Computer Science and Information Technologies, 5(3), 2742-2744.

Silva, C. V., Saens, R., Del Río, C., & Villarroel, R. (2013). Aspect-oriented modeling: Applying aspect-oriented UML use cases and extending aspect-z. Computing and Informatics, 32(3), 573-593.