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 system should react to particular input and ho the

the system should !ehave in particular

situation. The Functional requirements for HAMS are as follo s F" F# F$ F& F' F) F* The system shall allo user to register for an account. The system shall allo student to apply for a room. The system shall allo student to vie his%her room application status. The system shall allo student to provide their payment details. The system should have the a!ility to handle multiple clients( requests. The system shall allo user to edit his%her account(s personal details. The system should allo specified period of time. F+ The system should allo the Administrator to verify payment details. the Administrator to allocate rooms to students for a

F,

The system shall allo

the Administrator to create accounts for non-student users

(eg. arden and other administrators) and delete accounts. F". F"" The system shall allo The system should allo rooms. F"# F"$ The system should allo the /arden to e0change room allocations. The system should !e a!le to generate different reports These reports are 1oom allocation report Student 2ayment report. arden to report students( misconducts the Administrator to vacate students from allocated

(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 pass ord 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.

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 /indo s

family of 6perating systems and different flavors of 7inu0 6perating System. 3F* Maintaina!ility4 The system should !e easy to maintain and upgrade to ne er

versions 3F+ 3F, 8apacity requirement4 The system should !e a!le to serve at least ".... per day 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.

#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

,9. 3iew students payment report ,,. edit room allocation ,.. :eset password ,/. ;enerate reports

(#) $ist o% &ctors

Role "tudent

"escri'tion :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.

ui rimsUseCases

uc rimsUseCaseUsers

registered user

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

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.

Table Table 4.4 4.3 4.5 Use Use Case: Case: View Create Editown user new account account user account details Table 4.6 Use Case: Delete user account Use Use Use ase ase ase 42 ,dit * +iew reate user own new account account user *escription account details *escription *escription :>!" dministrator The 1urrent :>!" users administrator should are able be able tois view to responsible edit own user account for Table 4.2 Use Case: Login details creating details. including a ctors new user !inimal changing account #ser, user intype. *epositor, the system, ctors 5ditor, assigning :>!" :>!" dministrator account dministrator type,ssumptions and defining ssumptions :>!" account #ser details is administrator logged ctors :>!" into the is logged dministrator system "cenarios the system ssumptions ,& #ser "cenarios clic=s :>!" ,& 'ro%ile dministrator :>!" button. dministrator is .& logged system clic=s into displays the search account user details Use ase - "elete userinto account *escription :>!" administrator should be able tosystem. delete any Use ase ! $ogin *escription The system should be able to control different access levels by button "cenarios for current .& "ystem ,& user :>!" displays /& end dministrator of search use case user clic=s screen create with new several user user account search button options. on /& the :>!" system account as may be required from the system. ctors :>!" dministrator ssumptions :>!" capturing username and password of theand user and granting a user appropriate access and privileges administrator administration enters user.& search "ystem displays new and user su#mits screen . 2& requesting "ystem returns new account search result username that dministrator is screen. logged into the =eyword%s& system administration screen is displayed. "cenarios ,& and to resources. ctors !inimal user, depositor, 5ditor, and :>!" administrator ssumptions #ser has matches password. the /& supplied :>!" =eyword%s&. administrator 4& enters :>!" the dministrator requested username pic=s the and user password from the then result. clic=s 6& create :>!" administrator clic=s search user button. .& "ystem displays search user screen with been registered with the system. "cenarios ,& #ser clic=s login button .& "ystem displays login "ystem button. displays 2& "ystem administer displays user specify screen account allowing type :>!" screen administrator 4& :>!" administrator to ma=e changes selects to account user several user search options. /& :>!" administrator enters user search =eyword%s& and su#mits. screen /& #ser provides username and password, and clic=s login button 2& "ystem verify account type from as appropriate. available account 7& :>!" type administrator options and ma=es clic=s ne)t necessary button. changes 6& "ystem and displays su#mits .account 8& the 2& "ystem returns search result that matches the supplied =eyword%s&. 4& :>!" dministrator username and from password 4& "ystem grants the access and privileges to resources. 6& "ystem details processes screen. 7&the :>!" request administrator and updates enters the appropriate account account -& details "ystem and displays su#mit successful 8& "ystem update verifies if all pic=s the user the result. 6& "ystem displays the user account view screen. 7&its :>!" !ain user area screen is presented. 5xtensions /a& #nable to login due to invalid username or message mandatory ,9& data 5nd has of use been case. entered 5xtensions and stores 2& No the match data -& with "ystem the supplied displays =eyword%s&, successful added notify new the administrator selects the delete button 8& system requests confirmation for deletion -& :>!" password, notify the user including error message to re-login /b& #nable to login if account does not :>!" account dministrator message ,9& suggesting 5nd of use tocase try another =eyword%s&. administrator confirms deletion ,9& "ystem chec=s whether the user account has pending exist@ notifywaiting the use to to be contact the system administrator for ,,& new account creation publication deposited, and commits deletion. "ystem displays successful deletion message. 5xtensions -& :>!" administrator declines deletion, use case restart. ,9& #nable to delete user account since user account has pending deposit@ notify the system administrator that pending deposit has to be cleared first.

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

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 ne)t. 6& "ystem displays publication details screen. 7& #ser enters desired publication details information, i.e. title, abstract, authors, publication details, date, etc and clic=s ne)t. 8& "ystem displays uploads file screen -& #ser browses and attachAs the file and clic=s u'load button to upload the file. ,9& "ystem uploads the file and shows uploaded file. ,,& #ser clic=s ne)t. ,.& "ystem displays sub'ect catalogue screen. ,/& #ser pic=s sub'ect%s& associated with the publication 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

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