Anda di halaman 1dari 24

Software Requirements Specification

For

Practical Training Allocation System


Version 1.0
Prepared by 1. HANSON, WILLIAM 2007-04-02407 2. KEHENGU, MOSES 2007-04-05021 3. LUOGA, JOHN 2007-04-02252 4. MAGESA, EMMANUEL 2007-04-01531 5. MBESA, BARAKA 2007-04-02392 6. OMARI, MUSSA 2007-04-01674 7. NDIMBAU, BABU 2006-04-00215 8. NGALAWA, ISABELLA B. 2007-04-00218 9. NKWAVANO, LAWRENCE 2007-04-04726 10. PORPHANCE, PROSPECTIVE 2007-04-02097 11. SADIKI, AMANI 2007-04-00324 12. SIMON, SIXBERT 2007-04-04210 13. STEPHEN, ESTHER 2007-04-01171 14. WILLIAM, BARAKA 2007-04-01001 15. NALITOLELA, PETER 2007-04-02697 16. PATUKA, JIMMY 2007-04-00742

Page i

Software Requirements Specification for practical training allocation system

Table of Contents
Table of Contents .......................................................................................................................... ii Acronym: ........................................................................................................................................1 1. Introduction..............................................................................................................................2
1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 4.1 4.2 5.1 5.2 5.3 Purpose.................................................................................................................................... 2 Intended Audience and Reading Suggestions............................................................................ 2 Project Scope ........................................................................................................................... 2 Product Perspective.................................................................................................................. 2 Product Features ...................................................................................................................... 3 User Classes and Characteristics .............................................................................................. 3 Operating Environment ............................................................................................................ 3 Design and Implementation Constraints ................................................................................... 4 User Documentation................................................................................................................. 4 Assumptions and Dependencies ............................................................................................... 4 Context: ................................................................................................................................... 5 User functional requirements:................................................................................................... 5 System functional Requirements: ............................................................................................. 6 Uses case diagram.................................................................................................................... 7 Actors Description ................................................................................................................... 7

2. Overall Description..................................................................................................................2

3. Functional requirement...........................................................................................................5

4. Requirement analysis...............................................................................................................7 5. Design Documents..................................................................................................................11


User interfaces. ...................................................................................................................... 11 Class Diagram:....................................................................................................................... 12 Codes generated from the classes ........................................................................................... 13

Page ii

Acronym:
FR Functional Requirement PT Practical Training UD User Documentation UFR User Functional Requirement

Page 1

1. Introduction
1.1 Purpose
This document identifies the requirements of Practical Training Allocation System. This SRS document describes the functional and non-function requirements of the system.

1.2 Intended Audience and Reading Suggestions


This document is intended for the project managers, developers, testers, marketing staff as well as the end users of the system. Some sections may not be propriety for some groups like the system requirements for the end user, but it should be easy to follow.

1.3 Project Scope


The software is designed for allocating the students to various locations where their practical training can be conducted. It will register all students together with their allocation status. The software control things like over allocation of students, under allocation of students and double allocation. The system will also keep the records of the students and the companies that provide the training.

2. Overall Description
2.1 Product Perspective
The PRACTICAL TRAINING ALLOCATION system (PT allocation system) originates from the problem of difficult in allocating student center for doing their Practical Training course. The problems start from deficiency of centers to under allocation of those few centers where by a company or an institute provide a certain number of posts available and the department send fewer student in regard to the number of post given. The other problem was double allocation in which a single student may be allocated more than once. Another problem was over allocation of student in one company or institute. Also the system rise in order to eliminate the problem of memory lost and easy querying of the reports submitted to the PT coordinator. This is the first version of the system and is self contained system meaning it can run on its own.

Page 2

2.2 Product Features


The system shall be able to register students and companies/institutes and keep the history of these entities. It shall be able to allocate the students to the post in the respectively companies automatically as well as control the over-allocation, under-allocation and multiple allocation. The system shall have a way of accessing the database and be able to generate reports to show a list of students and their respective allocated centers.

2.3 User Classes and Characteristics


Users of the PT allocation are categorized into two classes based on privilege levels. Administrator: The administrator is the one responsible to register students as well as companies. He/she shall be able to update the database from time to time when need arise, and shall be able to query the report of the whole system, approve post applied by student and update the system. Supervisor: These will check the list of students assigned to them for supervision during the practical training. The Practical training coordinator is responsible for allocating students their supervisor. Student: Students will be able to login and view their respective status of allocation, comment and choose a place for practical training. They should have the ability to send information if he/she has got a place for practical training apart those available in the system

2.4 Operating Environment


OE-1: OE-2: OE-3: The Practical Training Allocation System shall operate with any standard web browser like Microsoft Internet Explorer, Netscape Navigator, Opera and Mozilla Firefox. The System shall operate on a web server like Apache HTTP Web server. The System shall permit user access from anywhere where internet services is available.

Page 3

2.5 Design and Implementation Constraints


Constraint 1 The software design should make use of web based applications (technologies). This will require the browsers and web servers application program specifically Apache HTTP Server be installed. Constraint 2 The software should be platform-independent; which implies that users working with all types of operating systems should be able to run the software on their respective Environments. Thus crossplatform languages should be used in implementation, the examples of which are XML and HTML. Constraint 3 MySQL Database Management System (DBMS) should be used and PHP as a scripting language for security purposes. Constraint 4 For security reasons, encryption algorithms should be used such as the harsh share one algorithm which is one way i.e. it scrambles the password and provide no means to reverse it to have the original. Java language shouldnt be used because its not secure enough.

2.6 User Documentation


UD 1: The first time a new user accesses the system and on user demand thereafter, the system shall provide an online tutorial to allow users to effectively use the system services. UD 2: The system shall provide an online hierarchical and cross-linked help system in HTML that describes and illustrates all system functions.

2.7 Assumptions and Dependencies


AS 1: The students who can access and use the system are the ones who have to undertake the Practical Training. AS 2: The students shall be able to access the system and choose or give information about their Practical allocation places. And there should be a deadline beyond which, the system will allocate them automatically.

Page 4

3. Functional requirement
3.1 Context:
The PT allocation system is designed to work in department of computer science, where its intended users are: - Students, who can apply or upload for PT centers, view their allocated centers, and submit PT report to their respective supervisors. PT supervisors see the list of their students, receive their PT reports. PT coordinator, act as administrator of the system responsible for keeping track of PT allocation process, and ensuring smooth conduction of PT by coordinating the all other users.

3.2 User functional requirements:


UFR - 1: PT allocation software shall provide log in procedures for each visiting user, where it should prompt for user authentication and respond accordingly to user privilege level or denies access for unauthorized users. UFR - 2: PT allocation software shall be able to publish the list of all available PT centers where students can apply and dynamically update the list of centers together with the list of students eligible for PT in order to prevent over or multiple allocations. PT allocation software shall provide facilities where students can provide some information about the PT centers which they have obtained by themselves, out of those published posts in the system.

UFR - 3:

UFR - 4: PT allocation software shall keep track of allocating supervisors to students. UFR - 5: PT allocation software shall be able to support files transferring necessary for report and weekly book log submission.

Page 5

3.3

System functional Requirements:

FR 01: System shall provide facilities for the new user (PT coordinator, students, and PT supervisor) to be registered. FR 02: System shall provide a form where a registering user can fill his/her particulars; Name and Registration number for students or ID number and name for staffs. Also the choice of username together with password. FR 03: System shall possess an algorithm of verifying the information submitted by user to see whether they match the list of eligible users from computer science department database. FR 04: System shall possess algorithm which will encrypt users passwords and save them in a database. FR 05: System shall assign each user a privilege level of the service he/she can access on system. FR 06: System shall provide facilities for checking the username and password of user trying to log in if are valid. FR 07: System shall provide a menu to each successfully log in user which correspond his/her assigned privilege level FR 08: System shall ask for re entering of password and username or registering first, for unsuccessfully log in. FR 09: System shall keep track of allocating PT centers to students FR 10: System shall publish a list of available PT centers for student to choose. FR 11: System will be implemented based on first come first serve policy, the system shall decrement vacancies by one, whenever a student choose a particular PT center, and disallow student from choosing when there is no more vacancies. FR 12: Once the student has select the PT center, the system must remove his/her name from the list of students not yet allocated FR 13: PT allocation software shall provide facilities where students can upload PT centers which had obtain by him/her, out of the published posts. FR 14: Once the student log in successful to the system, the system software shall provide the interface that has a form to submit the information about the PT post he/she got. FR 15: Once the information about the PT post obtained entered, the system shall provide algorithm to upload that information to the PT coordinator interface. FR 16: System shall enable the PT coordinator to approve the information about PT post submitted by the student. FR 17: If the details about PT post submitted are correct, the system shall be able to have an algorithm to transfer the name of the student to the list of those students already allocated to PT posts. FR 18: System shall provide facilities for students to submit their PT reports. FR 19: System shall provide facilities for students to submit filled logbooks on weekly basis. FR 20: System shall provide facilities for PT coordinator to transfer necessary PT documentations such as logbooks, arrival declaration letter etc. to students.

Page 6

4. Requirement analysis
4.1 Uses case diagram

4.2 Actors Description


The following actors are defined so far in the analysis phase of the PT Allocation System.

PT_Coordinator Element Description Example Details A person who works for the computer science department and responsible for allocating other users. PTCoordinator is allowed to register student and allocating supervisors to students.

Page 7

PT_Supervisor Element Description Example Details A person who also works for the department of computer science and responsible for supervising student during their practical training. PT_Supervisor is responsible for monitoring the participation of the student at their respective PT center and assessment of the PTreport and log books

Student Element Description Example Details A Student is a registered person by the coordinator eligible for practical training. A Student can create an account, select the pt_center and can read information issued by pt_coordinator

Use Cases Description Use case 1: Login Login Element Actor Trigger Details PT_coordinator, PT_supervisor and Student When actors want to use system functionalities/services and they are not being logged in. PreThe actors have not login successful, the system has to inform them to re-try login if Condition the actors are already members or to register if they want to access the system for the first time. PostThe actors can successful login to the system and be able to access their particular Condition interfaces and do anything according to their privileges. Normal 1: The actor fills-in the username and password, and submits them. Event 2: The system validates the login information entered. Flow 3: The system accepts an actor as a valid user, and provides the particular interface otherwise the system prompts the actor to re-enter the login information or sign up.

Page 8

Use case 2: Registration Registration Element Actor Trigger PreCondition PostCondition Normal Event Flow Details PT_Coordinator When submission of information concerning the companies, students and supervisors is completed. The student or PT_Supervisor not registered, so when he/she wants to access the PT allocation system is considered as the user with no priorities. The student or PT_Supervisor is registered and has the valid information that will help him/her to login. And the registered company can now be allocated with students. 1: The PT_Coordinator fills the registration form and submits it 2: The system validates the inputs. 3: The system accepts a student or PT_Supervisor as a valid user, giving necessary login information to be used. 4: The PT_Coordinator also registers companies where prospective students are going to do their practical training.

Use case 3: Allocation Allocation Element Actor Trigger Pre-Condition PostCondition Normal Event Flow Details PT_Coordinator, Student Student picked a center from the available list and a PT_Coordinator has picked a supervisor for particular students. The student is not allocated, so he/she cannot do his/her practical training that is known to the department of computer science, and he/she is not going to be supervised The student allocated successful, and he/she is going to do his/her practical training as well as be supervised. 1: The PT_Coordinator allocates the valid student (who submitted the information about the PT center he/she got) to that PT center or from those available in the system itself and his/her supervisor. 2: The system dynamically adds the name of the allocated student to the list of those already been allocated. 3: The student who successful login to the system, selects the PT center and the system dynamically allocate him/her as well as add his/her name to the list of those already been allocated. 4: PT_Coordinator then allocate the supervisor to a particular student(s).

Page 9

Use case 4: Information Publication Information Publication Element Actor Trigger Pre-Condition PostCondition Normal Event Flow Details PT_Coordinator, Supervisor The availability of news that is to be known to the users of information. Information are not publicized, the users cannot get necessary information concerning the practical training allocation. When information publicized, a student can know precisely what is going on about the practical training e.g.; when is going to commence and finish. 1: The PT_Coordinator or a Supervisor submits the information about the practical training on the system 2: The system uploads the information into the database 3: The users access the uploaded information once logged in to the system.

Page 10

5. Design Documents.
5.1 User interfaces.
Login form: Enter your username and password to login into system Username: Password: Login Forgot username or password?

Administrative panel: WELCOME TO THE ADMINISTRATIVE PANEL OF PRACTICAL TRAINING SYSTEM News and Allocate Information automatically Companies Database Record Management Students and supervisor Generate Extras reports

Company name:

SEARCH COMPANY

ENTER DETAILS ABOUT THE NEW COMPANY Name: Location: Number of posts: Type of company:

Private Public ADD COMPANY ADD COMPANY

Page 11

Student Panel: WELCOME STUDENT DETAILS ABOUT THE CENTER OBTAINED ELSEWHERE PT Center Selection Allocation Status Submit Information Student Name: Registration Number: Company Name: Location/Address: Type of company: Other company details:

Public Private

News and Information SUBMIT

5.2 Class Diagram:

Page 12

5.3 Codes generated from the classes


Company.h

Page 13

Coordinator,Supervisor,Student.cpp

Page 14

NewsInfo.h

Page 15

Student.h

Page 16

Supervisor.h

Supervisor.h

Page 17

Student.cpp

Page 18

Coordinator,supervisor,student.cpp

Page 19

NewsInfo.cpp

Page 20

Coordinator.cpp

Page 21

Company.cpp

Page 22

Anda mungkin juga menyukai