ASSIGNMENT-ISAD

SOKOINE UNIVERSITY OF AGRICULTURE

FACULTY OF SCIENCE

DEPARTMENT OF INFORMATICS

COURSE NAME: INFORMATION SYSTEM ANALYSIS AND DESIGN
COURSE ANTE: INF 300

                                                                Group assignment:
                                                                       Participants

S/n	Name	Registration Number	Degree-Program
1	ELIAS, JACKSON	EDU/D/10/T/0266	EDU(IM)
2	NGAVATULA, NEEMA	INF/E/10/T/0031	INF
3	HUSSEIN, SALMA	INF/D/10/T/0004	INF
4	HASHIM, OMARY	INF/E/10/T/0023	INF
5	FRANCIS, DEUS	INF/D/10/T/0046	INF
6	JOEL, ALEX	INF/E/10/T/0044	INF
7	MWOMBEKI, ODILO	EDU/E/10/T/0283	EDU(IM)
8	ABEID, KITIBIO	EDU/E/10/T/0077	EDU(IM)
9	MASELE, DOGAN	EDU/D/10/T/0262	EDU(IM)
10	MLAWA, TADEI	EDU/M/10/T/0192	EDU(IM)
11	MOHAMED, RASHID. S	INF/D/10/T/0045	INF

Task:  SRS of The EasyDrive School of Monitoring case study

INSTRUCTOR;   Dr. C. Sanga                 

SUBMISSION DATE:  21^TH JANUARY 2013

TABLE OF CONTENTS

1. Introduction. 2

1.1 Purpose of the system.. 2

1.2 Document convention. 2

1.3 Intended audience. 2

1.4 Project Scope. 2

1.5 Reference. 2

2.0 Overall Descriptions. 3

2.1 Product perspective. 3

2.2 Product features. 3

2.3 User Classes and Characteristics. 3

2.4 Operating Environment 3

2.5 Design and Implementation constraints. 3

2.6 User documentation. 4

2.7 Assumptions and Dependencies. 4

3.0 System features. 4

4.0 External Interface Requirements. 4

4.1 User interfaces. 4

5. Non-functional Requirements. 6

5.1 Performance requirements. 6

5.2 Safety requirements. 6

5.3 Security requirements. 6

5.4 System quality attributes. 6

5.5 Project documentation. 6

6.0 Supporting Information. 11

7.0 Glossary. 15

 

 

 

1.0  INTRODUCTION

The SRS is produced at the end of the analysis task. The function and performance allocated to software as part of the system engineering and refined by establishing a complete information description, a detailed functional description, a representation of system behavior, indication of performance requirements and design constrains, appropriate validation criteria and the other information related to requirements. This SRS is technical specification of requirements of EasyDrive School of Motoring system. This specification describes what the proposed system should do and how it will do it. It also describes complete external behavior of proposed system.

1.1 PURPOSE OF THE SYSTEM

The purpose of this system is to improve communication and sharing of information between offices, employees and clients at   easy drive school of motoring. Also, this system will reduce the amount of paper work at this school. (This is the first release (version 1) of easy driving school of motoring database system).

1.2 Document convention

Throughout this SRS document, the font style used is: font name-Times new Roman, font size-12pt, line spacing-1.5.

1.3 Intended audience

This system is intended to support the members of Easy Drive school of Motoring, including staff members, clients and other non-staff members.

1.4 Project Scope

The development of this system at easy driving school of motoring will minimize the use of papers to store necessary information for the organization. It is meant for use by the developers and will be the basis for validating the final delivered system.

 

 

1.5 References

1.      http://brainmass.com/business/management/377157 Accessed on 18/01/2013

2.      Thomas M. and Connolly Carolyn e. Begg (1999) System analysis and Design in Software Engineering, Scotland: University of the west ofScotland.

3.      Silberschatz, H( 1997) Database System Concepts (3rd ed.)McGraw-Hill

4.      http://www.hotcourses.com/uk-courses/driving-courses-easy-drive-school-of-motoring/16180339/0/322374/ZX.2/Z,Y,Q,R,T,U,V,C/any/county/united+kingdom/all/list.htm accessed on 18/01/2013.

5.      http://www.studentoffortune.com/question/1081026/Case-study-Easy-Drive-school-of-Motoring. Accessed on 20/01/2013.

6.      Sachin, K (2007) software requirement specifications, Template-Start writing SRS for your project.http://www.sachinkraj.wordpress.com/2013/01/01/ software-requirement-specification-SRS-template-start-writing-srs-for-your-project. Accessed on 19/01/2013

2.0  OVERALL DESCRIPTIONS

 

2.1 Product perspective

The development of this system is not a replacement development but it is a new development (version 1) that aims at solving a problem of paper work at EasyDrive School.

2.2 Product features

The system will enable a user to:

v  Login into system.

v  Update the information.

v  View information.

v  Search for information in the database system.

2.3 User Classes and Characteristics

This system will be accessed and used by different users with different characteristics, below are the users and their characteristics.

v  System administrator: will be able to-view all information, modify, update and delete information in the database.

v  Staff: will be able to view part of the information in the database and edit (update) just part of the database.

v  Normal user (client or normal staff member): will be able to view only part of the database information.

2.4 Operating Environment

·         This system will under windows operating system platform (all Windows XP versions, all Windows Vista versions and all Windows 7 versions).

·         The database management system (DBMS) used are MySQL and SQL Server.

·         This system will run under normal computer specification (at least 20GB HDD, 128MB RAM, and 1.6GHZ processor)

2.5 Design and Implementation constraints

  E-R Diagram

 Context Diagram

Database server for EasyDrive School system is;

v  MySQL Server

After the delivery of this software system, there will be on field training for users (staffs and system administrator).

 2.6 User documentation

The Easy Drive School of motoring Database system will have user documentation (user manual guide) which will direct the users on how to use the system. These documents will be available online and hard copy document for insuring availability of the information.

2.7 Assumptions and Dependencies

The system will depend on the availability of Windows operating system (any), MS-access. Therefore if these software components miss, the system will not work.

3.0 SYSTEM FEATURES

This part of system features has been mentioned above (2.2) in the part of product features

A user whose identity has been verified will be able to retrieve and access information through the system at class time and out of class. The client is free to ask for a particular instructor or change of instructor at any stage of learning drive.

4.0  EXTERNAL INTERFACE REQUIREMENTS

4.1 USER INTERFACES

The Easy Drive school of Motoring database system will have good user interface which will enable system users to the database easily. The user interface will show necessary directives which will help the user on how to access data in a database.

THE LOGIN FORM.

 

CLIENT’S REGISTRATION FORM

INSTRUCTOR’S REGISTRATION FORM

5.0 NON-FUNCTIONAL REQUIREMENTS

 5.1 Performance requirements

The Easy Drive School of motoring Database System will have good performance that will help users to easily access information and sharing information. The system will be faster such that the execution time will be minimal. Also, the system will have minimal or no errors and if the errors occur the system will alert the user on the required command.

5.2 Safety requirements  

This system will require safe environment which is free from viruses.

5.3 Security requirements

The Easy Drive School of motoring Database system should be secured from unauthorized access, that is, only authorized users will have access to the database. This will be ensured through authentication of the users that will involve use of combination of user name and password. This will avoid unauthorized editing, changing or deleting of data from the system.

5.4 System quality attributes

The Easy Drive School of motoring Database system will have high quality in the sense that it will meet the requirements of users and its maintenance will be possible.

5.5 Project documentation

The Easy Drive School of motoring Database system will have the project documentation which will enable the other software developers to develop this system depending on the new user requirements.

6.0 SUPPORTING INFORMATION

6.1  Data Flow Diagrams

 

6.2  Data Dictionary

ClientApplicationDetail=clientID+ClientName+ClientSex+DateOfBirth+ClientContactAddress+

Nationality+MaritalStatus+Age.

ClientID=integer+ {Legal character} +Special character e.g. (year-nationality-SNo)

Integer= {0-9}

Legal character {A-Z/a-z}

Special character {-}

ClientName=ClientFName+ClientMiddleName+ClientSurname

ClientFName= {Legal character}

ClientMiddleName= {Legal character}

ClientSurname= {Legal character}

ClientSex= [Female, Male]

DateOfBirth= {Day} + {month} + {year}

Day=interger from 1 to 31

Month= [Legal month character, interger for particular month]

Legal month character= [January… December]

Interger for particular month= [1, 2, 3, 4… 12]

ClientContactAddress=PhoneNumber+PostalAddress+ZipCode

PhoneNumber= {CountryCode} +ClientPersonNumber

ClientPersonNumber= {interger}

CountryCode=plus sign digits that identify the country e.g+255 for Tanzania

PostalAddress= {integers} + {Legal character}

ZipCode= {CountryCode} +StateNo+CityNo+BlockNo+HouseNo

StateNo= {interger}

CityNo = {interger}

BlockNo = {interger}

HouseNo= {interger}

Nationality= {Legal character}

MaritalStatus= [Single, Married, widowed, divorced]

Age= {Interger}

VerifiedForm=ClientRecords+ {FormID}

FormID= {Interger} **every verified form has an ID to specify qualified client to be interviewed

ClientInterview= {Instructor} + {FormID} +SeriesOfQuestions

Instructor=InstructorID+Title+InstructorFName+ (InstructorMiddleName) +InstructorSurName

InstructorID= {Legal character} + {Interger}

Title= [Mr, Mrs, Miss, Dr, Prof]

InstructorFName= {Legal character}

InstructorSurName {Legal character}

SeriesOfQuestion= [OralQuestion, WrittenQuestion, OralQuestion+WrittenQuestion]

Lessons= {LessonCode} + {LessonName} +LessonInstructor+LessonDuration+LessonStart+LessonEnd

LessonCode= {interger} + {Legal character}

LessonInstructor= {Instructor}

LessonDuration=NumberOfWeek

NumberOfWeek={interger}

LessonStart=Date to begin the lesson

Date to begin the class= {Day} + {month} + {year}

LessonEnd=Date to end the lesson

Date to end the lesson= {Day} + {month}+{year}

PaymentRecord= {PaymentReceipt} + {LessonPaid}

PaymentReceipt=ReceiptNo+ {ClientID} + {ClientFName} + (ClientMiddleName) +

{ClientSurName}+Amount

ReceiptNo= {Integer}

Amount= {Integer}

LessonPaid= {LessonCode} +{LessonName}

ManagementRecord={PaymentReceipt}+{LessonPaid}+{InstructorID}+{InstructorFName}+(InstructorMiddleName)+{InstructorSurName}+ClientProgress

Car=Car-model +Car-color+Capacity+RegNo

Car-model= {Legal character}

Car-color= {Legal character}

Capacity=Tonnes

Tonnes= {integer} + {Legal character}

RegNo= {integer} + {Legal character}

DrivingTest=TestDate+TestTime+TestName+TestResult+TestCentre+{Instructor}

TestDate= {Day} + {month} + {year}

TestTime= {Integer}

TestNumber= {Integer}

TestResult=TestMarks +Remarks

TestMarks= {Integer}

Remarks= {Legal character}

TestCentre=RoomNumber

RoomNumber= {Integer}

ClientProgress= {LessonID} + {LessonName} +LessonGrade

LessonGrade= [A, B⁺, B, C, D, E]

License=LicenseNo+ {ClientFName} + (ClientMiddleName) + {ClientSurName} +LicenseClassification

LicenseClassification=[class A, Class B, Class C,Class D, Class E]

7.0  GLOSSARY

7.1  Database: A centrally held collection of data that allows access and manipulation by one or more users

7.2  Data flow diagram (DFD): A diagram that illustrates how data moves through an information system.

7.3  Database management system (DBMS): a software system that facilitates the creation and maintenance and use of an electronic database

7.4  Data Dictionary: is a structured repository of data about data.

7.5  ERD: Graphical representation which describes the relationships between entities and their attributes.

7.6  Context Diagrams: General description of how information flows in the school. Including internal and external entities.