hams

8/13/2019 Hams

http://slidepdf.com/reader/full/hams 1/12

SYSTEM ANALYSIS

Introduction

This section presents the analysis, design, and implementation of the proposed Hostel

Accommodation Management System (HAMS).

System Analysis

Functional and Non-Functional Requirements

(1) Functional Requirements

Functional requirements are statement of service that the system should provide ho the

system should react to particular input and ho the system should !ehave in particular

situation. The Functional requirements for HAMS are as follos

F" The system shall allo user to register for an account.

F# The system shall allo student to apply for a room.

F$ The system shall allo student to vie his%her room application status.

F& The system shall allo student to provide their payment details.

F' The system should have the a!ility to handle multiple clients requests.

F The system shall allo user to edit his%her accounts personal details.

F* The system should allo the Administrator to allocate rooms to students for a

specified period of time.

F+ The system should allo the Administrator to verify payment details.

8/13/2019 Hams


F The system shall allo the Administrator to create accounts for non-student users

(eg. arden and other administrators) and delete accounts.

F" The system shall allo arden to report students misconducts

F"" The system should allo the Administrator to vacate students from allocated

rooms.

F"# The system should allo the /arden to e0change room allocations.

F"$ The system should !e a!le to generate different reports

These reports are

• 1oom allocation report

• Student 2ayment report.

(2) Non-Functional Requirements

Non-functional requirements define the overall qualities or attributes of the resulting system.

Non-functional requirements place restrictions on the product being developed, the

development process, and specify external constraints that the new system must meet.

The following are Non-Functional requirements identified for H!".

3F" Security4 The passord for user account should contain a mi0ture of

alphanumeric, special sym!ols and should !e at least + characters long.

3F# 2erformance4 The system should give response in a reasona!le amount of time.

8/13/2019 Hams


3F$ 1egulatory4 The system should 5eep records a!out tenant for the period of time

specified in 1ecord Management Act of the country.

3F& Safety4 The integrity of the system should be ensured against accidental or malicious

damage.

3F' #sability$ The system should be user friendly through informative error messages,

help facilities, better user interfaces.

3F 2orta!ility4 The system should !e a!le to run in different platforms li5e /indos

family of 6perating systems and different flavors of 7inu0 6perating System.

3F* Maintaina!ility4 The system should !e easy to maintain and upgrade to neer

versions

3F+ 8apacity requirement4 The system should !e a!le to serve at least " per day

3F 2rivacy4 The system should not disclose personal details to unauthori9ed user

3F" :nteropera!ility4 The system should !e a!le to integrate ith other e0ternal related

systems.

4.2.2 System Modelling with Use ases

The use case model describes the functionality of the system in terms of the action performed by the

user of the system %the actor& and a description of how the system responds to those actions.

8/13/2019 Hams


#se cases which portray system requirements captured in requirements determination are the primary

driver

of ob'ect oriented analysis and design %(()*& %+acobson et al, &. use case represents a

particular functionality or functional requirement of a software system. There are two forms of use

case deliverables$ use case diagram and written use case description.

(!) Use ase "iagrams

#se case diagrams, derived from system requirements, depict interactions between use cases and

relevant actors, together with relationships among use cases. Figure , Figure and Figure ./

illustrate this.

Use ases

The following use cases have been identified from the functional requirements above$

. 0ogin

. 0ogout

/. 1reate new user account

2. 3iew user account details

4. 5dit user account

6. *elete user account

7. apply for a room

8. room llocation

. 3iew room allocation reports

8/13/2019 Hams


9. 3iew students payment report

. edit room allocation

. :eset password

/. ;enerate reports

8/13/2019 Hams


(#) $ist o% &ctors

Role "escri'tion

"tudent :egistered user who applies for room and submit required

details

<arden :egistered user who can edit room allocations and provide

details about room status.

dnistrator :egistered user user with privileges for performing "ystem

administration duties in the system.

8/13/2019 Hams


ui rimsUseCases

uc rimsUseCaseUsers

8/13/2019 Hams


registered user

8/13/2019 Hams


uc administrateOrganizationalStructure

Figure 4.3 Administrate RIMS Organizational Structure Use Case Model

(c) Use ases ritten "escri'tion

*escribing individual use cases in detailed textual format is the first step in the stepwise process to

8/13/2019 Hams


develop the analysis class diagram. The most important piece of information included in a written

use case is the flow of events that describes the main success scenario of actions required for

successful completion of the use case. n approach available for developing use case descriptions

from system requirements %:olland ) chour, 8&, as well as templates available to use in writing

use case descriptions %1oc=burn, 7, 999&, are used in the analysis of :>!" for Higher

5ducations >nstitutions in Tan?ania as detailed below.

(i) Use ase Scenarios

scenario describes a sequence of steps that are executed in order to fulfil the goal the use case is

supposed to deliver.

8/13/2019 Hams


Table 4.7 Use Case !e"osit ne# "ublication

Table 4.2 Use Case: Login

Use ase ! $ogin *escription The system should be able to control different access levels by

capturing username and password of the user and granting a user appropriate access and privileges toresources. ctors !inimal user, depositor, 5ditor, and :>!" administrator ssumptions #ser has

been registered with the system. "cenarios & #ser clic=s login button & "ystem displays loginscreen /& #ser provides username and password, and clic=s login button 2& "ystem verify the

username and password 4& "ystem grants the appropriate access and privileges to its resources. 6&

!ain user area screen is presented. 5xtensions /a& #nable to login due to invalid username or

password, notify the user including error message to re-login /b& #nable to login if account does notexist@ notify the use to contact the system administrator for new account creation

Table 4.3 Use Case: Create new user account

Use ase 2 reate new user account *escription The :>!" administrator is responsible for

creating a new user account in the system, assigning account type, and defining account detailsctors :>!" dministrator ssumptions :>!" dministrator is logged into the system.

"cenarios & :>!" dministrator clic=s create new user account button on the system

administration screen. & "ystem displays new user screen requesting new account username and

password. /& :>!" administrator enters the requested username and password then clic=s create button. 2& "ystem displays specify account type screen 4& :>!" administrator selects account

type from available account type options and clic=s net button. 6& "ystem displays accountdetails screen. 7& :>!" administrator enters account details and su#mit 8& "ystem verifies if all

mandatory data has been entered and stores the data & "ystem displays successful added newaccount message 9& 5nd of use case

Table 4.4 Use Case: View own account details

Use ase * +iew own account details *escription 1urrent users are able to view own account

details. ctors !inimal #ser, *epositor, 5ditor, :>!" dministrator ssumptions #ser islogged into the system "cenarios & #ser clic=s 'ro%ile button. & system displays account details

for current user /& end of use case

Table 4.5 Use Case: Edit user account

Use ase 4 ,dit user account *escription :>!" dministrator should be able to edit user

details including changing user type. ctors :>!" dministrator ssumptions :>!"administrator is logged into the system "cenarios & :>!" dministrator clic=s search user

button & "ystem displays search user screen with several user search options. /& :>!"

administrator enters user search =eyword%s& and su#mits. 2& "ystem returns search result that

matches the supplied =eyword%s&. 4& :>!" dministrator pic=s the user from the result. 6&"ystem displays administer user screen allowing :>!" administrator to ma=e changes to user

account as appropriate. 7& :>!" administrator ma=es necessary changes and su#mits. 8&"ystem processes the request and updates the account & "ystem displays successful update

message 9& 5nd of use case. 5xtensions 2& No match with the supplied =eyword%s&, notify the:>!" dministrator suggesting to try another =eyword%s&.

Table 4.6 Use Case: Delete user account

Use ase "elete user account *escription :>!" administrator should be able to delete any

account as may be required from the system. ctors :>!" dministrator ssumptions :>!"

dministrator is logged into the system and administration screen is displayed. "cenarios &

:>!" administrator clic=s search user button. & "ystem displays search user screen withseveral user search options. /& :>!" administrator enters user search =eyword%s& and su#mits.

2& "ystem returns search result that matches the supplied =eyword%s&. 4& :>!" dministratorpic=s the user from the result. 6& "ystem displays the user account view screen. 7& :>!"

administrator selects the delete button 8& system requests confirmation for deletion & :>!"

administrator confirms deletion 9& "ystem chec=s whether the user account has pending

publication waiting to be deposited, and commits deletion. & "ystem displays successfuldeletion message. 5xtensions & :>!" administrator declines deletion, use case restart. 9&

#nable to delete user account since user account has pending deposit@ notify the systemadministrator that pending deposit has to be cleared first.

8/13/2019 Hams


Use ase "e'osit new 'u#lication *escription The system will support electronicsubmission of publication by registered users with privileges that include deposit.

ctors *epositor, editor, :>!" administrator ssumptions #ser is logged into the system"cenarios & #ser selects the manage 'u#lication tab. & "ystem displays manage publication

screen /& #ser selects new item button 2& "ystem displays new publication screen 4& The user

specifies publication type %i.e. article in a 'ournal, chapter in a boo=, conference paper, etc& and

clic=s net. 6& "ystem displays publication details screen. 7& #ser enters desired publicationdetails information, i.e. title, abstract, authors, publication details, date, etc and clic=s net. 8&

"ystem displays uploads file screen & #ser browses and attachAs the file and clic=s u'loadbutton to upload the file. 9& "ystem uploads the file and shows uploaded file. & #ser clic=s

net. & "ystem displays sub'ect catalogue screen. /& #ser pic=s sub'ect%s& associated with thepublication from the sub'ect catalogue list and clic=s the de'osit button 2& "ystem validates

inputs to ensure that mandatory information is provided 4& "ystem stores the data and displays

successful message to the user. 5xtensions 2& "ystem detects that mandatory publication

information is missing. B "ystem informs the user that mandatory item information is missing. B#se case resumes to previous step with prompts on the first field with error. 6-/& "ave for

later submission. B "ystem saves publication in pending area for later submission

hams

Documents