PROJECT ONE ON REGISTRAR SYTEM

SUBMIT TO:-Wondwossen E.

GROUP MEMBERS

NAME ID.NO

1. TEGEGN TILAHUN...................................................EVCS/0191/10

2. EYASU TADESE.........................................................EVCS/0122/10

3. MARKOS HAWARIA................................................EVCS/0253/10

4. TSIGE ARGETA.........................................................EVCS/0206/10

5. IDILU BRIHANU.........................................................EVCS/073/9

6. KEBEDE KECHELA....................................................EVCS/0146/10

DATE: 19/9/2021
Table of Contents
1.1 Purpose.................................................................................................................................1
1.2 Scope.....................................................................................................................................1
1.3 Objectives and success criteria of the project.......................................................................1
1.4 Definitions, acronyms, and abbreviations............................................................................2
1.5 References.............................................................................................................................2
1.6 Document Overview.............................................................................................................2
2. Current system..........................................................................................................................3
3. Proposed system.......................................................................................................................4
3.1 Overview...........................................................................................................................4
3.2 Functional requirements....................................................................................................5
3.3 Non-functional requirements............................................................................................5
3.3.1 User interface and human factors..............................................................................6
3.3.2 Documentation...........................................................................................................6
3.3.3 Hardware consideration.............................................................................................6
3.3.4 Performance characteristics.......................................................................................6
3.3.5 Error handling and extreme conditions......................................................................7
3.3.6 Quality issues.............................................................................................................7
3.3.7 System modifications.................................................................................................7
3.3.8 Physical environment.................................................................................................7
3.3.9 Security issues...........................................................................................................7
3.3.10 Resource issues..........................................................................................................7
3.4 System models..................................................................................................................8
3.5.1 Scenarios....................................................................................................................8
3.5.2 Use case model..........................................................................................................9
3.5.3 Object model............................................................................................................10
3.5.4 Dynamic models......................................................................................................11

i|Page
List of Figure
Figure 1.Use case diagram...............................................................................................................9
Figure 2. Class diagram.................................................................................................................10
Figure 3.Sequence Diagram 1.Login into the system....................................................................11
Figure 4Sequence diagram2: Student Registration........................................................................11
Figure 5Sequence Diagram3: Grade Entry....................................................................................11

ii | P a g e
1.1 Purpose
This software design specification is made with the purpose of outlining the software
architecture and design of the Registrar System in detail. The document will provide developers
an insight in meeting client’s needs efficiently and effectively. Moreover the document facilitates
communication and understanding of the system by providing several views of the system
design.

1.2 Scope
The Software design document would demonstrate how the design will accomplish the
functional and non- functional requirements captured in the Software Requirement specification
(SRS). The document will provide a framework to the programmers through describing the high
level components and architecture, sub systems, interfaces, database design and algorithm
design. This is achieved through the use of design patterns, sequence diagrams, class diagrams,
relational models and user interfaces.

1.3 Objectives and success criteria of the project

In order to achieve the general objective of the project the following specific objectives are
formulated:-

 To analysis the existing systems problem.

 To identify the functional and non-functional requirement of the student registration

system.

 To develop user friendly or interactive interface.

 To develop a database that holds students registration information.

 To implement the proposed system

 To prepare test plan and conduct testing

 To deploy the system and maintenance when need maintain the system

1|Page
1.4 Definitions, acronyms, and abbreviations
Acronym Definition
UML Unified Modeling Language
SRS Software Requirement specification
ID No Identification Number

1.5 References
 Software Requirements Specification (SRS) of the Student Registration System
 Object-Oriented Software Engineering_ Practical Software
 Ian Sommerville, 9 Edition SOFTWARE ENGINEERING
 Internet

1.6 Document Overview

The next chapter of the document has described current system of the Registrar System. In the
3rd part we deal about proposed system. Includes functional requirement and non-functional
requirements. Also non-functional requirements User interface and human factors,
Documentation, Hardware consideration, Performance characteristics, Error handling and
extreme conditions, Quality issues System modifications, Physical environment, Security issues
and Resource issues. The last part consists System models Scenarios, Use case model, Object
model, Data dictionary, Class diagrams and Dynamic models.

2|Page
2. Current system
In this chapter this project discuss about topics like how the current system is operating and how
the proposed application intend to replace the existing system.

Based on our data gathering the current registrar system is a manual. When the students they
done registration form from the registrar and go to different office to sign registration form. The
students may sign clearance form when they want to fill withdrawal, to take ID card for the
second time, during the end of each year and finally when they graduate and leave the university.
This makes the system so tedious and time consuming. Here, students have to visit all the
clearance offices with a form for them to sign. This process takes a lot of time to be completed
and possess a lot of stress for all students involved.

In the manual system, the registration forms are documented in a file cabinet. Each time the
registration form is needed, a search operation is conducted on the file cabinets to locate a
particular student’s registration form.

3|Page
 3. Proposed system
In order to overcome the current system problems that exist in the functioning of registrar
system, our project team members have put down alternative options. These are:-

 Changing the structure of manual system in to organized manner

 Completely change manual system in to computerized and automated system without

affecting the structure of clearance system

The new system is designed to solve problem affecting the manual system in use. It is designed
to be computerized thereby relieving both student and staff from much stress as experienced
from the manual system.

This will do the analyzing and storing of information either automatically or interactively. The
system will be made accessible over Internet. The new system gives full system functionality
that is needed by system user to use system functionalities.

The proposed system will also have some other features like.

 Accuracy in handling of data

 Fast rate of operation and excellent response time

 Flexibility it can be accessed at any time

 Better storage and faster retrieval system.

 Accessibility from anywhere.

The above listed points are described what the project teams are proposed to do and since the
proposed system is automated the user can perform the task with efficiently and effectively.

3.1 Overview
This chapter deals with featuring the proposed system by using different UML feature modeling
techniques such as use case diagrams, the use case descriptions (scenarios), sequence diagrams,
use case diagram, and class diagram.

4|Page
After identifying the actors and use cases, the use cases are developed and textual descriptions
(scenarios) are stated. The Sequence diagram id depicted based on the use cases which are
developed for the proposed system.

3.2 Functional requirements

Functional requirements define a function of a system and its components. A function is
described as a set of inputs, behavior, outputs, data manipulation and processing and other
specific functionality that define what the system is supposed to accomplish.

1. Registrar administrator

 Should be managing account.

 Should be maintain system

 Should be post message for system users.

 Should be done registration.

2. Officers (Like School/Department head; Registrar officers and Instructors.

 Should be Manage property

3. Student

 Done registration.

 View grade.

 Send request to Registrar admin.

 View messages.

 Download Material.

3.3 Non-functional requirements

Non-functional requirement specifies how the system should behave or a non-functional
requirement is a statement of how a system must behave, it is a constraint upon the systems

5|Page
behavior. It specifies all the remaining requirements not covered by the functional requirements.
They specify criteria that judge the operation of a system, rather than specific behaviors.

Some of the non-functional requirement of this system is listed below.

3.3.1 User interface and human factors

These requirements include the qualities of the system that are desirable from the users’ point of
view. The new system will use windows type graphical user interface. This type of interface is
easy to use for very little additional training and common to most computer users. The system
will enable the users to use the system.

The user interface for the software shall be compatible to any browser such as Internet Explorer,
Mozilla or Netscape Navigator by which user can access to the system.

3.3.2 Documentation
At the end of the project, every activity in the development process will be documented for
future reference. There will also be a documentation of implementation language for
maintenance during system failure.

3.3.3 Hardware consideration

Server Computer: For best performance, the system needs Server Computer with Intel Pentium4
CPU 8.00 GHZ, 200 GB of available RAM and 500GB of hard disk that acts as a back end for
storing incoming client reservations.

Client computer: The client computer should have the following specification, minimum hard
disk requirement and RAM size that is enough for browsing cases 1.00 GB with low processor
speed. Router: To be connected with service provider.

Printer: to print available information.

3.3.4 Performance characteristics

It concern on the speed of operation of the system. The search result for any query should not
take more than seconds if the database is available on the same machine and not more than
seconds if the database.

The product shall be based on web and has to be run from a web server.

6|Page
3.3.5 Error handling and extreme conditions
To reduce input fault, the system will: - Respond to error inputs by asking the user to re-enter
data in the correct format.

3.3.6 Quality issues

Registrar system is to shows process organization of the system that takes into account some
non-functional requirements, such as performance and availability. It addresses issues of
concurrency and distribution, of system’s integrity, of fault-tolerance, and how the main
abstractions from the logical view fit within the process architecture on which thread of control
is an operation for an object actually executed.

Generally, process view of the system can be viewed as follows.

 User interface and human factors

 Documentation
 Performance characteristics
 Hardware consideration

3.3.7 System modifications

Registration system should be modifiable for further modification and enhancement of the
application.

3.3.8 Physical environment

Registrar system should be shows the hardware for your system, the software that is installed on
that hardware and the middleware used to connect the disparate machines to one another. The
physical aspects of an object oriented software system it models the right time configuration in
static view and visualize the distribution of components in an application.

3.3.9 Security issues

It ensure the integrity of the registrar system from accidental or malicious damage the client
system user can’t log as an system administrator i.e. they can’t do the activities that performed
by the administrators. This controls the unauthorized users to update the database.

The inventory database is password protected.

3.3.10 Resource issues

There are many staffs that have used registrar system but this project is limited to automate
registrar system only because of the following reasons:-

7|Page
  Time factor in the sense that the semester was short and as a result combining this
task is tedious since there is a lot of staff is there.

Financial constraints:

 If the students lost/damage the university property, he/she couldn’t done registration,
until the students pay the cash personally to finance.

There is no transfer of properties or materials:-since online transfer of material is difficult tasks

in the process of developing this online registrar system so the project team can’t include such
tasks.

System hasn’t any chat room that facilitates communication between the administrator and
workers of the respected staffs in delivering information.

3.4 System models

The model describes the structure of the registrar system or application that we are modeling. It
consists of class diagrams, use case diagram and sequence diagrams that describe the logical
implementation of the functional requirements that you identified in the use case model. The
analysis model identifies the main process in the system and contains a set of use case
realizations that describe how the system will be built.

3.5.1 Scenarios
Main success scenario:

1. Loin to the system

2. Enter the ID and User Name
3. Validate entered Student ID and User Name
4. Enter/select upcoming academic semester-year
5. Display course catalog
6. Enter/select course to register
7. Determine course pre-requisite(s)
8. Add course number to student’s registered courses
9. Display/refresh list of registered courses

8|Page
Extensions:

2a. Choose the account

1. Staff
2. User

3a. Not mach ID and User Name

1. System asks to retry.

2. Go to step 4 & verify, if success go to step 5.

3.5.2 Use case model

Define the different types of users of a system and the various ways that they interact with
the system. They include actor, use case, boundary and relationship

Figure 1.Use case diagram

9|Page
 3.5.3 Object model
The object model describes the structure of the registrar system or application that we are
modeling. It consists of class diagrams view that describe the logical implementation of the
functional requirements that you identified in the use case model.

3.3.5.1 Class diagrams

Object here in the class diagram are entities that represent real world reality. These each objects
have their own behaviors (functions) and attributes (characteristics) by which they are
differentiated.

Conceptual model are used to depict the detailed understand of the problem space for the system.
Class model show the class of the system, their enter relationship and the operations and
attributes of the classes.

Figure 2. Class diagram

10 | P a g e
 3.5.4 Dynamic models
The dynamic model describes the structure of the registrar system or application that we are
modeling. It consists of sequence diagram that describe the logical implementation of the
functional requirements that you identified in the use case model.

Figure 3.Sequence Diagram 1.Login into the system

Figure 4Sequence diagram2: Student Registration

Figure 5Sequence Diagram3: Grade Entry

11 | P a g e
12 | P a g e