REPORT software engineering PROJECT PLANT INFORMATION MANAGEMENT

HANOI UNVERSITY OF SCIENCE AND TECHNOLOGY SCHOOL OF ELECTRICAL AND ELECTRONICS ENGINEERING REPORT Software Engineering PROJECT: PLANT INFORMATION MANAGEMENT Advisor : Assoc Prof Thi-Lan Le 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 Context and Current Situation .1 1.2 Requirements 1.2.1 Functional requirements 1.2.2 Non-functional requirements: CHAPTER 2: SYSTEM DESIGN 2.1 Use Case 2.1.1 System requirements .3 2.2 Detailed usecase 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 i TABLE LIST Table 2.1 Deriving Use Cases from System Requirements Table 2.2 Mapping: System requirements to Use cases ii 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 Login /Logout U6: Log in Change password Update my profile Employee Admin U7: Log out Search Modify plant information Modify employee 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 Initiator Initiator’s Goal Participants Usecase 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 Search information Database Search informaton(UC-4) Add new plant information, remove, update plant information Database Modify plant information Add new employee account, remove, update information Database Employee Admin Admin (UC-5) Modify employee information (UC-6) Table 2.1 Deriving Use Cases from System Requirements Requiremen t UC1 REQ1 X UC2 UC3 UC4 UC5 UC6 UC7 X X REQ2 X REQ3 X REQ4 X REQ5 X X REQ6 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 The set of valid accounts stored in the system database is nonempty The application displays the menu of available functions; On the application screen, the menu choices are “Login” or “Logout” Preconditions: 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: Admin/Employee selects the menu “Login”/ “Logout” include::AuthenticateUser (UC-7) 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 To be positively identified by the system (at the first interface) Actor’s Goal: Participating Actors: Preconditions: Database The set of valid accountstored in the system database is nonempty None worth mentioning Postconditions: Flow of Events for Main Success Scenario: System prompts the actor for identification Tenant/Landlord supplies a valid identification account 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 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 Admin/Employee supplies a valid identification account Same as in Step 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 nonempty Postconditions: The new account information is saved to the database Flow of Events for Main Success Scenario: Admin/Employee select the menu “Change password” Admin/Employee enter old password Then, enter a new password System verifies that the password is changed Flow of Events for Extensions (Alternate Scenarios): 2a Admin/Employee enters an invalid old password System detects error, marks a failed attempt, and signals to the actor Admin/Employee supplies a valid password Same as in Step 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: The user login to the app by his/her valid key and select menu item “Profile” The system identifies the user by his/her key and shows their profile on the screen The user manages his/her profile as he/she wants and chooses to save 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 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 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 options to Admin account: Add, Change, Delete -Show only option to Employee accounts Postconditions: The modified data is saved to the database Flow of Events for Main Success Scenario: Admin picks 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 10 2.3 Activity diagram: 2.3.1 Login: 2.3.2 Change password: 11 2.3.3 Search information: 12 2.3.4 Modify plant information: 2.3.5 Modify employee information: 13 14 2.4 Class diagram: 15 REFERENCE [1] https://www.guru99.com/non-functional-requirement-type-example.html#3 [2] 16 ... update information Database Update my profile(UC-3) Admin Search information Database Search informaton(UC-4) Add new plant information, remove, update plant information Database Modify plant information. .. Search Modify plant information Modify employee information 2.1.1 System requirement: REQ1: Unlock when valid password REQ2: Modify plant information at runtime REQ3: Modify employee information. .. 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