REPORT software engineering PROJECT PLANT INFORMATION MANAGEMENT

Use Case: U1: Login/ Logout U2: Change password U3: Update my information U4: Search information U5: Modify plant information U6: Modify employee U7: Authenticate User U6: Log in U7: Log

HANOI UNVERSITY OF SCIENCE AND TECHNOLOGY

SCHOOL OF ELECTRICAL AND ELECTRONICS ENGINEERING

REPORT

Software Engineering

PROJECT:

PLANT INFORMATION MANAGEMENT

Students: : Nguyễn Trường An 20193201

Vũ Tống Minh Hiếu 20193218

Đỗ Khôi Nguyên 20193234 Bàn Thị Thủy 20193239

TABLE OF CONTEN

TABLE OF CONTENT i

TABLE LIST ii

CHAPTER 1: INTRODUCTION 1

1.1 Context and Current Situation 1

1.2 Requirements 1

1.2.1 Functional requirements 1

1.2.2 Non-functional requirements: 1

CHAPTER 2: SYSTEM DESIGN 2

2.1 Use Case 2

2.1.1 System requirements 3

2.2 Detailed usecase 4

2.3 Activity diagram 10

2.3.1 Login 11

2.3.2 Change password 11

2.3.3 Search information 12

2.3.4 Modify plant information 12

2.3.5 Modify employee information 13

2.4 Class diagram 14

REFERENCE 15

TABLE LIST

Table 2.1 Deriving Use Cases from System Requirements 3 Table 2.2 Mapping: System requirements to Use cases

CHAPTER 1: INTRODUCTION

1.1 Context and Current Situation:

- Nowadays, the Fourth Industrial Revolution is built upon the Digital Revolution where human and technology are connected A number of new ways of demonstrating of its abilities have been recently found in many fields, such as: economy, physics, agriculture, … Our project is especially used in the forestry, which helps people to efficiently manage information about plants and their applications Then, we would like to apply this project in herb management

- Normally, it is really hard to find documents about herb with its exact information Books cost an arm and a leg to buy and the documents on the Internet are not sufficient Hence, this app is created in order to help people search information in an easier way Moreover, it provides a fuction that garden owners can manage their gardeners

1.2 Requirements:

1.2.1 Functional requirements:

- Admin:

o Manage the information of both plants and employees

o Add new users

o Search the data of users and plants

- Employees:

o Search information of plants

o Manage their own account: change password, update their information, etc

1.2.2 Non-functional requirements:

Scalability: add more tools for further use

Reliability: we use information from verified by many scientists

Availability: this shows how long the user can use until periodically maintenance

Capacity: up to 100000 plants

Maintainability: 75% for 24hr

Security: admin only

Manageability: define herbs in terms of diseases

Environmental: Android

Usability: friendly interfaces

CHAPTER 2: SYSTEM DESIGN

2.1 Use Case:

U1: Login/ Logout

U2: Change password

U3: Update my information

U4: Search information

U5: Modify plant information

U6: Modify employee

U7: Authenticate User

U6: Log in

U7: Log out

Login /Logout

Change password

Admin

Update my profile

Employee

Search

Modify plant information

2.1.1 System requirement:

REQ1: Unlock when valid password

REQ2: Modify plant information at runtime

REQ3: Modify employee information at runtime

REQ4: Search plant information at runtime

REQ5: Search employee information at runtime

REQ6: Change password

Admin,

Employee

Login /Logout Database Login / Logout(UC-1)

Admin,

Employee

Change password – personal account

Database Change password(UC-2)

Admin,

Employee

Change and update information

Database Update my profile(UC-3)

Admin

Employee

Search information Database Search informaton(UC-4)

Admin Add new plant information,

remove, update plant information

Database Modify plant information

(UC-5)

account, remove, update information

Database Modify employee

information (UC-6)

Table 2.1 Deriving Use Cases from System Requirements

Modify employee information

t

Table 2.2 Mapping: System requirements to Use cases

2.2 Detailed Usecase:

Use Case 1: Login / Logout

Use Case UC-1: Login /Logout

Related requirements: REQ1 stated in Table 2.2

Initiating Actor: Any of: admin, employee

Actor’s Goal: To login or logout from the app

Participating Actors: Database

Preconditions:

The set of valid accounts stored in the system database is non-empty

The application displays the menu of available functions; On the application screen, the menu choices are “Login” or “Logout”

Postconditions: If login: Users can access the application when valid account.

If logout: Screen direct to login function

Flow of Events for Main Success Scenario:

1 Admin/Employee selects the menu “Login”/ “Logout”

2 include::AuthenticateUser (UC-7)

3 Admin/Employee enter the application

Flow of Events for Extensions (Alternate Scenarios):

1a For axample, admin/employee enter invalid data

Use Case 7: AuthenticateUser

Use Case UC-7: AuthenticateUser(sub – use case)

Related requirements: REQ1 stated in Table 2.2

Initiating Actor: Any of: admin, employee

Actor’s Goal: To be positively identified by the system (at the first interface)

Participating Actors: Database

Preconditions: The set of valid accountstored in the system database is non-empty. Postconditions: None worth mentioning

Flow of Events for Main Success Scenario:

1 System prompts the actor for identification

2 Tenant/Landlord supplies a valid identification account

3 System verifies that the account is valid, and signals to the actor the account validity

Flow of Events for Extensions (Alternate Scenarios):

2a Admin/Employee enters an invalid identification account

1 System detects error, marks a failed attempt, and signals to the actor 1.1 System detects that the count of failed attempts exceeds the maximum allowed number, signals to sound AlarmBell, and notifies the Police actor of a possible break-in

2 Admin/Employee supplies a valid identification account

3 Same as in Step 3 above

Use Case 2: Change password

Use Case UC-2: Change password

Related requirements: REQ6 stated in Table 2.2

Initiating Actor: Any of: Admin, Employee

Actor’s Goal: Change personal account password

Participating Actors: Database

Preconditions: The set of valid accounts stored in the system database is

non-empty

Postconditions: The new account information is saved to the database

Flow of Events for Main Success Scenario:

1 Admin/Employee select the menu “Change password”

2 Admin/Employee enter old password Then, enter a new password

3 System verifies that the password is changed

Flow of Events for Extensions (Alternate Scenarios):

2a Admin/Employee enters an invalid old password

1 System detects error, marks a failed attempt, and signals to the actor

2 Admin/Employee supplies a valid password

3 Same as in Step 3 above

Use Case 3:

Use Case UC-3: Name / Identifier

Related requirements: REQ3

Initiating Actor: Any of admin, user

Actor’s Goal: To add/remove/change their identity information on the

system Participating Actors: Database

Preconditions: + User login successfully

+ The system displays the menu of available functions including “Profile” section

Postconditions: The system displays the new profile modified by the

admin/user on the screen and saves the new profile in the system’s memory

Flow of Events for Main Success Scenario:

1 The user login to the app by his/her valid key and select menu item “Profile”

2 The system identifies the user by his/her key and shows their profile on the screen

3 The user manages his/her profile as he/she wants and chooses to save

4 The system displays the new profile and saves it in the system’s memory

Use Case 4:

Use Case UC-4: Name / Identifier

Related requirements: REQ4, REQ5

Initiating Actor: Any of admins, users

Actor’s Goal: To search for needed information

Participating Actors: Database

Preconditions: + User login successfully

+ The system displays the menu of available functions including “Search” section

Postconditions: The system displays the searched information, the user can

use the search bar again to find other information

Flow of Events for Main Success Scenario:

The user login to the app by his/her valid key and select menu item

“Search”

The system identifies the user by his/her key and shows their profile on the screen

Flow of Events for Extensions (Alternate Scenarios):

2a Invalid searching information

Users search bar to search again or leave

If search again, back to step 2 above

Use Case 5:

Use Case UC-5: Modify plant information

Related requirements: REQ2

Initiating Actor: Only Admin

Actor’s Goal: Add/ change/ delete the plant data

Participating Actors: Database

Preconditions: -Admin account must be logged in

-3 main functions are displayed on the screen: add, change, delete Postconditions: The modified data is saved to the database

Flow of Events for Main Success Scenario:

Admin picks 1 function: Add, Change, Delete

+Add: Admin enters new data

+Change: Admin searches a plant -> Admin changes the data

+Delete: Admin searches a plant -> Admin deletes the data

Add: System saves the added information

Change: System saves the modified information

Delete: System deletes the data out of database

System shows the new data to users

Flow of Events for Extensions (Alternate Scenarios):

Admin inputs wrong type of data, example: input String in the slot of Number System: “Error! You have entered wrong type of data”

System allows Admin to re-input the data

Use Case 6:

Use Case UC-6: Modify employee information

Related requirements: REQ3

Initiating Actor: Admin, Employee

Actor’s Goal: Add/ change/ delete the employee data

Participating Actors: Database

Preconditions: -Show full 3 options to Admin account: Add, Change,

Delete -Show only 1 option to Employee accounts Postconditions: The modified data is saved to the database

Flow of Events for Main Success Scenario:

Admin picks 1 function: Add, Change, Delete +Add: Admin enters new data

+Change: Admin searches a plant -> Admin changes the data +Delete: Admin searches a plant -> Admin deletes the data Employee picks Change function:

+Change: Employee searches his/her information-> Employee changes the data

Add: System saves the added information Change: System saves the modified information Delete: System deletes the data out of database System shows the new data to users

Flow of Events for Extensions (Alternate Scenarios):

Users input wrong type of data, example: input String in the slot of Number

System: “Error! You have entered wrong type of data”

System allows Admin to re-input the data

2.3 Activity diagram:

2.3.2 Change password:

2.3.3 Search information:

2.3.4 Modify plant information:

2.3.5 Modify employee information:

2.4 Class diagram:

[1] https://www.guru99.com/non-functional-requirement-type-example.html#3

[2]