KINGDOM OF SAUDI ARABIA

Ministry Of Higher Education Imam Mohammed Bin Saud Islamic University Faculty of Computer and Information Sciences

Information System Department

Web-Based Disease Forecasting System for Palm Trees in KSA

Submitted by:

Submitted to: Dr. waleed Rashaida

Sep 2012

Chapter Four: System Analysis

4.1 Overview:

This chapter will explain system analysis by viewing system requirement in functional and nonfunctional requirements, Process modeling by showing state diagram, sequence diagram, and activity diagram, and finally showing the class diagram of Risk management system

4.2 Information Gathering Techniques:

The important step for building knowledge for a new system or to develop an existing system is information gathering. There are many techniques for information gathering. In our project, we used questionnaires, and checking features of systems that handle risk management such as: BWise Risk Management [4], and SAP [5], and we found these systems provides a complex scenarios and a lot of data entry needed for risk management life cycle, which is no need for small business, or a lot of these fields are an extra for these types of business size. . 4.2.1 Summary In information gathering phase, no application provide a mini-solution for small business to handle risk management , so building of a website that will help management to take the right dissection , to handle risk which is a danger in the future, by make it simple and confidant at the same time 4.3 : User Requirements:

4.3.1 Functional Requirement:

1. Users should be able to use the web application from several Web

browser supporting HTML 3.2 (or later) and cookies.

2. Users would be able to view a complete list of posted risks . 3. Users should be able to search for risks by related attributes, such as risk

rank, risk name, or risk description.

4. Users should be able to select any risk and view the status of this risk

4.3.2 Nonfunctional Requirement:

1. Auditor would be able to modify the Risk contents.

2. Huge amount of users would be able to run the application at same time. 3. The performance of the application must not reduce with an increase in the number of goods or services offered.

4.4: System Requirements:

4.4.1 Functional Requirements 1. User Login 2. User Logout 3. User can Update his user info
4. Auditor cans Rise Risk.

5. Auditor can create solution plan. 6. Auditor can attach Documents for a risk . 7. Auditor can flow their raised risks. 8. Auditor can read Admin notifications. 9. Manager Accept/Reject raised risk. 10. Manager asks for declaration request. 11. Manager can read Admin notifications. 12. Manager can view attached documents. 13. Manager can view report of any risk. 14. Manager can request a plan from auditors.
15. Admin can send notifications for users.

 Use Case Diagram

Login

Manage Department

Manage Users Request Declaration Approve Risk View Document Accept Risk Plan

Manag er

Admin

Rise Risk

Send Declaration Send Risk Plan Send Document

Auditor

Trace Risk

Logout

Figure 4.1 : use case diagram

Use case description:

Use Case Description System: Risk management system . Use Case name: Login Primary actor: Admin Secondary actor: Auditor and Manager Use Case Description: Through this case all users can enter to the system to Use case number: Priority (H,M,L):H 1 Student Group ID:

getting all services that introduced by system.

Pre-conditions: User must have a valid username and password . Post-conditions: -

Use Case Description System: Risk management system Use Case name: Manage Department Primary actor: Admin Secondary actor: Use Case Description: Admin can add/edit/delete Department on system. Pre-conditions: Admin must login. Department name must not be duplicated Post-conditions: If basic flow is successful, Selected Department managed Student Group ID: Use case number: Priority (H,M,L):H 2

Use Case Description System: Risk management system Use Case name: Manage users Primary actor: Admin Secondary actor: Use Case Description: Admin can add/edit/delete users. Pre-conditions: Admin must login. Post-conditions: If basic flow is successful, User account managed Student Group ID: Use case number: Priority (H,M,L):H 3

Use Case Description System: Risk management system Use Case name: Request Declaration Primary actor: Manager Secondary actor: Use Case Description: Manager can request a declaration from auditors Pre-conditions: User must login. Raised risk must be selected Post-conditions: If basic flow is successful, Message notification will be viewed (successful operation ) Student Group ID: Use case number: Priority (H,M,L):H 4

Use Case Description System: Risk management system Use Case name: Accept Risk Primary actor: Manager Secondary actor: Use Case Description: Pre-conditions: User must login. Raised risk must be selected Post-conditions: If basic flow is successful, Message notification will be viewed (successful operation ) Student Group ID: Use case number: Priority (H,M,L):H 5

Manager can Accept raised risk

Use Case Description System: Risk management system Use Case name: View Documents Primary actor: Manager Secondary actor: Use Case Description: Student Group ID: Use case number: Priority (H,M,L):H 6

Manager can view sent document which is related with a

specific risk.
Pre-conditions: User must login. Raised risk must be selected Post-conditions: If basic flow is successful, Message notification will be viewed (successful operation )

Use Case Description System: Risk management system Use Case name: Accept Risk Plan Primary actor: Manager Secondary actor: Use Case Description: Accept risk plan which is sent from Auditors Pre-conditions: User must login. Approved Raised risk must be selected Plan for that risk must be selected Post-conditions: If basic flow is successful, Notify message will be viewed Plan is accepted Student Group ID: Use case number: Priority (H,M,L):H 7

Use Case Description System: Risk management system Use Case name: Rise Risk Primary actor: Auditor Secondary actor: Use Case Description: Auditor can raise risk to manager to approve. Pre-conditions: User must login. Post-conditions: If basic flow is successful, Risk will be sent to Manager Student Group ID: Use case number: Priority (H,M,L):M 8

Use Case Description System: Risk management system Use Case name: Send Declaration Primary actor: Auditor Secondary actor: Use Case Description: Auditor can send a declaration of risk which is requested Student Group ID: Use case number: Priority (H,M,L):M 9

form Manager
Pre-conditions: User must login. User Must Select Declaration Request Post-conditions: If basic flow is successful, notification message will be viewed that (Successful operation )

Use Case Description System: Risk management system Use Case name: Rise Risk Plan Primary actor: Auditor Secondary actor: Use Case Description: Auditor can send a plan for that risk when it approved by Student Group ID: Use case number: Priority (H,M,L):M 10

Manager
Pre-conditions: User must login. User Must Select Approved Risk. Post-conditions: If basic flow is successful, notification message will be viewed that (Successful operation )

Use Case Description System: Risk management system Use Case name: Send Document Primary actor: Auditor Secondary actor: Use Case Description: Auditor can send a Document for selected risk Pre-conditions: User must login. User Must Select a Risk. Post-conditions: If basic flow is successful, notification message will be viewed that (Successful operation ) Student Group ID: Use case number: Priority (H,M,L):M 11

Use Case Description System: Risk management system Use Case name: Trace Risk Status Primary actor: Auditor, Manager Secondary actor: Admin Use Case Description: Manager, and Auditor can View and trace of raised risk , Student Group ID: Use case number: Priority (H,M,L):M 12

and the status of that , Admin can view all risks status
Pre-conditions: User must login. User Must Select a Risk. Post-conditions: If basic flow is successful, Risk details will be viewed .

Use Case Description System: Risk management system Use Case name: Logout Primary actor: Admin Secondary actor: Seller, Visitor Use Case Description Through this case Seller and admin can exit from the Student Group ID: Use case number: Priority (H,M,L):H 13

system.
Pre-conditions: User must login Post-conditions: system will redirect to login page

4.4.2 Nonfunctional Requirements 1. Security 2. Performance 3. Privacy 4. Efficiency 5. Support two language Arabic & English 6. Support multi extended files 7. Support more than color for background 8. Easy to use and logical sequence 9. Availability online 24 hours / 7 days

4.5

Process Modeling :

4.5.1 Activity Diagram: Auditor can identify risk then he can attach a document to that risk , after that this risk will be sent to manager to review , if manager accept the risk request , manager will ask for risk plan , else auditor need to identify that risk with more details. After risk plan sent to manager , manager will decide if it suitable and applicable , if this plan is approved , it will be sent for implementation , else auditor need to create other plan and send it again As shown in figure 4.2

Figure 4.2: Risk activity diagram

4.6 Data Modeling :Class Diagram :

Figure 4.3 : Class Diagram

4.6 Behavior modeling

Searching for a risk:

users will insert by keyboard any part of item name, if this part located in risks table, this item will be retrieved and viewed to user. Rise Risk Auditor will insert new Risk name , and risk details , system will ask if user need to attach document , then if auditor attach a document , this document will be saved in database , and linked with that risk , if this document is already there for selected risk , message will appear (this document is already inserted ) , else the document will be inserted and assigned for this risk.
Adding new Auditor :

Admin will insert Auditor information, if Email is located in users table , message then message will appear (this user is already inserted, try other Email ), else if Username is located in users table then message will appear (this user is already inserted, try other username), else Auditor user will be inserted , and will be ready to use.

4.6 Conclusion :
In this chapter explained Requirements specification and System analysis of the system. The most important tasks that were doing in this phase were the gathering of functional/non-functional requirements. Based on the functional requirement, by generated the Use case diagrams and explained them in detail. Also creating process modeling and describe in details based on this team analysis , by creating activity diagram , then this chapter descript data modeling by creating class diagram and view all possible class that would be used to create this system , in behavior modeling descript the most important behavior could be happen in this system .