University computer science and engineering departments often have budgets which are comparable with small companies and an integrated system to support all aspects of departmental administration is required. This should support student records, laboratory administration, the ordering of goods and services, input and output payments, payments made for teaching assistants, research contract reporting, etc. It should be linked to a wider University system responsible for staff salaries etc. Factors which should be taken into account include: 1) Departmental chairmen who use such a system are usually very busy. Even if they are computer literate, they require a system with a straightforward user interface. 2) Users of the system range from secretaries through technicians to teaching and administrative staff. The range of users to be supported is very wide. 3) In some countries, the trend is for Universities is to devolve administration from a central organization to the individual departments. The system must be able to be expanded to handle future, unforeseen tasks. 4)Sub-systems should be automatically linked so that, for example, the costs of a particular class or laboratory can be computed by considering payments made and received.

1. Lumbini ICT College
Gaindakot-2, Nawalparasi
Nepal
Project on
Integrated University Department Information System
Department of Bachelor in
Computer Science and Information Technology
(Bsc CSIT)
Submitted by: Submitted to :
Nischal Khatiwada Er. ModNath Acharya
Kausik Panta
Puspa Adhikari
Bishnu Sapkota ……………………
Rabin Ghimere Signature
Rosan Chapagain
Submitted on:
10 February, 2017

2. i
Acknowledgement
We would like to express our deepest appreciation to all those who provided us the possibility to
complete this project. In performing this project, we had to take the help and guideline of some
respected persons, who deserve our greatest gratitude. The completion of this assignment gives us
much pleasure. We would like to show our gratitude to Er. ModNath Acharya for giving us a good
guideline for this assignment throughout numerous consultations.
We would also like to expand our deepest gratitude to all those who have directly and indirectly
guided us in completion of this project. Many people, especially our classmates and team members
itself, have made valuable comment suggestions on this report which gave us an inspiration to
improve our assignment.
We thank all the people for their help directly and indirectly to complete our project.

3. ii
Abstract
The project is about the integration university department information. The integrated university
department information system is to support all the aspects of the departmental administration. It
is also concerned with keeping the records of the students of different faculty, laboratory
administration, ordering of goods and services, research contract reports as well as staff salaries.
Integrated university department system is developed to provide high-level information service to
students and staff of that particular university. Great amount of information is made available.
Centralized relational database stores great amount of information. Accurate information and their
update are checked by the system administration. It supports flexible information access 24/7 any
time any place. It provides high security, only authorized staff and users can access the system.
The main aim of the system is to reduce formalized workload. The system helps access from the
comfort of home or lab. Via connection to World Wide Web. This helps to reduce costs associated
with staff required in help desk or reception. Moreover, cost of paper work will be significantly
reduced. Information administration and paperwork will be minimized, with details on users stored
in computer databases. Integration of the system will make sure the information is updated as soon
as any changes occur.
This system helps to provide the information about the platform to the student for discussion and
complain the activities that should be improved by the faculty and university as well as support
the students for online examination and provide the one stop service to the faculty members and
students as well as to the administration of the university.

4. iii
Table of Contents
Acknowledgement .................................................................................................................................................i
Abstract.................................................................................................................................................................ii
Table of Contents............................................................................................................................................... iii
Introduction.........................................................................................................................................................1
Objectives ............................................................................................................................................................2
Issues....................................................................................................................................................................2
Methodology........................................................................................................................................................3
Approaches to system development ..............................................................................................................3
Requirement finding techniques....................................................................................................................4
Design of the system........................................................................................................................................4
FEASIBILITY STUDY
Introduction.........................................................................................................................................................5
Feasibility study area..........................................................................................................................................6
Findings and Recommendations.........................................................................................................................10
REQUIREMENT ANALYSIS
Introduction.......................................................................................................................................................11
Methodology......................................................................................................................................................12
Limitations of the methodology.......................................................................................................................14
Body....................................................................................................................................................................15
Questioneers..................................................................................................................................................15
Requirements elicitation and gathering......................................................................................................15
User requirements.......................................................................................................................................15
Collaboration with partners.........................................................................................................................16
Requirement specification............................................................................................................................17
User requirement.........................................................................................................................................17
Interface requirement..................................................................................................................................18
Requirement validation................................................................................................................................20

5. iv
Requirement management...........................................................................................................................20
DESIGN
Framework........................................................................................................................................................21
System design ....................................................................................................................................................24
Unique Features of Sequence Diagrams .....................................................................................................24
Sequence diagram of different module ...........................................................................................................25
PROJECT SCHEDULING
Gantt chart ........................................................................................................................................................30

6. 1
Introduction
The integrated university department information system is to support all the aspects of the
departmental administration. It is also concerned with keeping the records of the students of
different faculty, laboratory administration, ordering of goods and services, research contract
reports as well as staff salaries.
Integrated university department system is developed to provide high-level information service to
students and staff of that particular university. Great amount of information is made available.
Centralized relational database stores great amount of information. Accurate information and their
update are checked by the system administration. System administrator, update system script to
ensure the data consistency with university central database. Flexible information access 24/7 any
time any place. High security, only authorized staff can access the electronic coursework but no
modification can be made after submitted. Reduce formalized workload. Coursework submitted
electronically. The system helps access from the comfort of home or lab. Via connection to World
Wide Web. This helps to reduce costs associated with staff required in help desk or reception.
Moreover, cost of paper work will be significantly reduced. Information administration and
paperwork will be minimized, with details on users stored in computer databases. Integration of
the system will make sure the information is updated as soon as any changes occur.

7. 2
Objectives
 to facilitate the web based system to the university for the ease access of the information.
 To helps the university to analyze the activities performed by the different faculty
 To helps to integrate the faculty and provide the better communication between faculties.
 To provide one stop services for the students and other staff of the university to get their
required information
 Provide better platform for analyzing the achievements and performance of the students
and the performance of the university.
 Platform for the administration to analyze the expenses of the university in importing good
and services, laboratory equipment and research works.
Issues
1) Privacy and confidentiality.
2) Initial difficulty in using the system.
3) Technical challenges like unavailability of some hardware resources.
4) Initial problem in coordination between the faculties.
5) Timely response problem when the number of users increases.

8. 3
Methodology
To carry out this project we performed the following tasks
 Investigate what the current university information systems of different universities
 Produce a detailed requirement specification for the potential new integrated university
information system
 Evaluate and analysis the requirement specification of the potential new integrated
university information system module.
The minimum requirements of this project have been set in the beginning of the project. They are:
 Conduct a requirement specification from first principles that will be based around the
generic requirement of a typical university school
 An investigation of potential customers (university school)
 Business process modelling and information capture requirement
 Providing evidence of investigation
Approaches to system development
The choice of system development approach will heavily influence the quality of the
system being produced. Therefore, make a right choice of appropriate system development
approach is vital before develop an actual system. So, we choose the incremental development
model.
Incremental development
"Incremental development" divides the project into well-defined stages with intermediate
milestones. The version of the product is delivered until the requirement of the users is not
fulfilled. "Incremental development" method has many advantages, as it is the most direct way
to the objective with the shortest development time cost accommodation in change of user
requirements and helps to get the customer feedback. However, the drawbacks of this method
include difficulty and time consuming of evaluation after each iteration and difficult to map the
requirements directly to different increment.
Object oriented approach
Object-Oriented (OO) technology has been heralded as a solution to the problems of software
engineering. The claims are that OO technology promotes understandability, extensibility,
resolvability, reusability, and maintainability of systems, and that OO systems are easy to

9. 4
understand and use. It has been applied widely in the past for mapping from real-world problem
to abstractions from which software can be developed effectively. Moreover, the object-
orientation provides good conceptual structures, which can be used to deal with the increasingly
complex information system.
Requirement finding techniques
There are five main fact finding techniques that are used by analysts to investigate
requirement. They are background reading, interviewing, observation, document sampling, and
questionnaires. These techniques helps to get the requirements with more clarity.
Design of the system
For designing our system we use the UML diagram. UML Diagrams are considered as a main
component in requirement engineering process and these become an industry standard in many
organizations. UML diagrams are useful to show an interaction, behavior and structure of the
system. It is necessary to integrate System Models with the UML diagram to overcome the
requirements errors i.e. contradiction, ambiguities, vagueness, incompleteness and mixed values
of abstraction. UML diagrams are important to understand the complexity of system. UML
describes the behavior and structure of a program. Also, they describe the interaction of
components with the system. These include Use Case, Class, Activity and many other diagrams.
UML diagrams are easy to understand by the users, developers and domain experts whereas the
formal methods are difficult to understand by the users, domain experts and developers as well.
UML Sequence diagram, as sequence diagram is an interaction diagram which shows the
interaction and proper sequence of components (Methods, procedures etc.) of the system.

10. 5
FEASIBILITY STUDY
Introduction
The integrated university department information system is to support all the aspects of the
departmental administration. It is also concerned with keeping the records of the students of
different faculty, laboratory administration, ordering of goods and services, research contract
reports as well as staff salaries.
Therefore, we carried out the feasibility study concerning on various factors to develop this project.
Our feasibility study aims to objectively and rationally uncover the strengths and weaknesses of
an existing business or proposed venture, opportunities and threats present in the environment, the
resources required to carry through, and ultimately the prospects for success. In its simplest terms,
the two criteria to judge feasibility are cost required and value to be attained.
Our feasibility study evaluates the project's potential for success. Our feasibility studies precede
technical development and project implementation. This report define major problem areas, so that
the system analyst can plan the strategy for the field investigation as well as determine the
approximate time required for the full investigation and cost. Therefore, perceived objectivity is
an important factor in the credibility of the study for potential organization developing the system
and system lending institutions. It was therefore conducted with an unbiased approach to provide
information upon which decisions can be made.

11. 6
Feasibility study area
 Technical feasibility:
This assessment is based on an outline design of system requirements, to determine whether
the company has the technical expertise and environment to handle completion of the project.
Upgraded technological capability will be required for IUDIS to move toward offering an
online services to the members of university from which users can get various information.
Here, faculty members demand a simple and easy way by which they can obtain online services
and it is imperative that all operations are conducted in a secure manner. IUDIS aims to
maintain a web site with service lists and descriptions. Also, focus of the integration of
information of all the departments so that administration can easily access the information.
Additionally, all the faculty aims to maintain separate database for storing it’s information in
secured manners.
University currently maintains a high speed internet connection, web server that can support
the system. In addition to this university has also some of the technical human resources who
can use the system after providing short package training. University has the sufficient
hardware that can support the system and can maintain the environment for the proper
operation of the system and helps in usability and enhance reliability on the system.
Hence, we can develop the system for university using the current technologies and can easily
include the latest hardware that helps to enhance the efficiency and effectiveness of the system.
 Economic feasibility:
This feasibility study estimate the total capital requirements for proposed system, whether
enough finances (investments) are available for proposed system or not. This is often called a
cost-benefit analysis.
The financial projections for an online platform for university are highlighted in the table
below.
Measure Cost
University Project cost $350000
Staffing Cost $100000
Project Material cost $20000
Additional Web Hosting and Marketing staff $10000

12. 7
Contractor for design , Build and implementation $20000
Total additional cost for online system $50000
Cost for training $50000
Profit to organization $100000
These are the abstract cost estimation for the project to get the idea on the benefits for the
organization in terms of cost. These figures account for projected online information about the
university, additional staffing requirements, contract support for IT and training needs, and
web server and hosting costs.
The assumptions for these projections are as follows:
 In store sales projections remain unchanged
 All milestones are performed in accordance with the schedule
 All transactions are closed yearly with no carry-over to subsequent years
 Schedule feasibility
A project will fail if it takes too long to be completed before it is useful. Typically this means
estimating how long the system will take to develop, and if it can be completed in a given time
period using some methods like payback period.
This section is intended to provide a high level framework for implementation of the product
or service being considered. This section is not intended to include a detailed schedule as this
would be developed during project planning should this initiative be approved. This section
may include some targeted milestones and timeframes for completion as a guideline only.
The IUDIS is expected to take 1 and half years from project approval to launch the system in
university. Many of the foundations for the system, such as high speed internet and web server
capability, are already available. The following is a basic schedule of some significant
milestones for this initiative:
 Jan 1, 2017: Initiate Project
 February 1, 2017: Project kickoff meeting
 April 1, 2017: Complete individual faculty system design
 June 1, 2017: Complete testing of individual faculty sub-system
 Sept 1, 2017: Complete beta testing trials of faculty sub-system
 February 3, 2018: integrate all the faculty sub-system into final system

13. 8
 March 12, 2018: Complete testing of final system of university
 May 1, 2018: Complete beta testing trials of final system of university
 June 27 , 2018 : Go live with system launch
Upon approval of this project a detailed schedule will be created by the assigned project team
to include all tasks and deliverables.
 Social feasibility:
Determines whether the proposed system conflicts with legal requirements or not. The
proposed system should follow the rules and regulation formed by government, i.e the system
that we are going to built should be within the boundary of constitution. Also the proposed
system should not violate the tradition of human.
IUDIS has a data processing system that comply with the local data protection regulations.
Here, we determine whether the university members has the skills to do the jobs and assess
whether the system will meet their needs. We also determine whether the operation performed
by the system will result in a permanent connection to the labor market for the target
population. We also calculated how many employees the business will need and how much the
employees will earn. What will their benefits be? We computed the working conditions of the
employee (i.e. hours per week, travel time, equipment they will use, levels of stress). We
ascertain the legal requirements necessary to operate a business .e.g. licenses, permits,
certifications, etc.
 Developing organization and staffing feasibility
Since, IUDIS need the complex system to perform the activities of the university. With the
increment of complexity in the system, we analyzed our organization to determine whether
we have enough skilled and experience manpower to develop the system. We analyzed
whether the expertise currently exists internally to design, build, and implement the sort of
extensive online system. If not, it is recommended to contract this work out to an external
expertise or hire the experienced manpower who can work with our company to meet the need
of the system within estimated timeframe and budget. The proposed system with different
services might need for additional staffing or for the system to restructure in order to
accommodate the change. These are important considerations as they may result in increased
costs. This helps our company to evaluate whether to proceed when we don’t have this
expertise internally, the technology exists and is in use throughout the marketplace and lowers

14. 9
the risk of the system failure considerably. Here, we identify and describe the suppliers we
will use. How much will they charge and how will you pay? Explain what would have to
change to facilitate success. We evaluated what additional management/staff are required.
What will be the cost? Do they require training? Assess the product testing that will be
required. We describe other major next steps to move the system development forward. What
are the general milestones? When will these occur? We also assess the impact if it did go
wrong and describe what you can do to prevent it. We also analyse at what points we could
cut our losses if things don’t go as planned.
 Market Opportunity
This study determines whether the proposed system can be used for other customers or not and
determine the market place. Here, we determine who will buy our product or service, and under
what circumstances.
Here, we determined what our customer(s) will be buying (the product or service and its key
elements) and explain the customer need that our product or service will address and identified
how, when, and where they will buy it. We diagnose which customer/ market segments we
should target. We also evaluated the size of the market (i.e. how many potential customers).
How many customers we can expect per year? Classified how often customers will buy system
from us. What is the average value of each purchase? We Identify and describe the market
trends and have the evidence that the market has demonstrated support for our product. We
have also described and evaluated our competitors. What are their strengths and weaknesses?

15. 10
Findings and Recommendations
It is the summary of the findings of the feasibility study and explain why this course of action is
or is not recommended.
Based on the information presented in this feasibility study, it is recommended that integrated
university information system can be initiated and begins project initiation. The findings of this
feasibility study show that this initiative will be highly beneficial to the organization and has a
high probability of success.
Key findings are as follows:
1) Technology:
 Will utilize existing technology which lowers project risk
 All technological infrastructure will be contracted out to vendor which allows university to
share risk
 Once in place this technology is simple to operate and maintain for a relatively low cost
2) Marketing:
 This initiative will allow university to reach large number of target groups electronically at a
low cost.
 Even we can enhance our market value after its successful completion.
3) Organizational:
 Minimal increases to staffing are required with no changes to organizational structure
 No new facilities or capital investments are required.

16. 11
REQUIREMENT ANALYSIS
Introduction
This document presents the results of the work package to identify user requirements for the
integrated university department information system project. The main aim of integrated university
department information system is to establish a prototype of the system to support the requirements
of the university. As such, this work package aims to elicit views from the faculty members of the
university, including key areas for integration within the University’s portal framework and the
content and applications that should be included. It describes the methodologies used to identify
the requirements, the initial findings and an analysis of the results from the complete set of user
surveys. The results of this analysis will feed into the next work package systems integration
requirements. These will assess the user requirements and priorities against practical constraints
and draw up the hit list of key capabilities that will encourage advocacy and maximize uptake of
the integrated university department information system.
This documents contains the requirements gathered applying different methodology and
specification of those requirements. It also define the interface between the users and the system
as well as between the systems in integrating the different functionalities of the system.

17. 12
Methodology
Integrated university department information system have been developed using a strong user-
centered approach. The IUDIS project wanted to ensure that the prototype implemented the
features that would be used, rather than features which fitted the technology well. For that reason,
all-inclusive methodology was implemented by the researchers and formulate the user
requirements from consultation.
 One to one interviews
The requirements gathering exercise started with a number of fairly informal discussions with
researchers. These one-to-ones discussed the current research activity of the user to determine
stages and processes for their activities. They were also asked about the systems that they used
and an attempt was made to identify gaps in the provision of support systems. Subsequent
one-to-one interviews were more structured, with a view to determining whether the research
followed similar processes or whether it diverged from those interviewed previously. We also
performed the semi structured interview to the detailed information about the system and
generate the clear idea of the requirements of the users.
These interviews looked into more detail about the actual systems required, although still kept
the flexibility to look into unused provision or gaps in research systems. The interview was
conducted between limited users from almost all the departments of university to get all the
requirements of the system.
 Focus groups
The first focus group was structured to check the validity of the ideas emerging from the one-
to-one sessions. The second focus group meeting presented an idea of what might go into the
IUDIS portal, and asked for feedback on this. It also set some challenges, for example, the
safety and security of the system the developer need to focus for the efficiency of the system.
The initial requirements resulting from the one-to-one and focus group sessions were
documented and the key ones noted. These were then prioritised based on the apparent
importance to users gleamed during the interviews and focus groups. The prioritised
requirements formed the basis for the questions posed in the subsequent online survey.
 Online survey

18. 13
A Web-based questionnaire was used to compare the needs of the specific users involved in
the earlier stages of this work package with the wider users of the system. In this survey almost
all the users were involved in providing their requirements for the system. The survey had
very tightly defined goals: prioritisation of user requirements; testing the completeness of the
requirements found through the one-to-one and focus group sessions; and confirmation that
these requirements were applicable to researchers from other disciplines. It also provided
opportunity for further consultation by encouraging comments on proposed functionality and
perceived barriers to research.
An analysis of the questionnaire returns enabled the IUDIS project team to adjust the
requirement priorities of the proposed systems identified as a result of the one-to-one and
focus group sessions.

19. 14
Limitations of the methodology
The major limitation of the methodologies employed in the requirement gathering phase of the
work package is related to sample size. The resource available to the project limited the number
of one-to-one interviews that could be undertaken within the allotted timescale. Despite this, it was
felt that increasingly repetitive answers indicated that at least some of the key requirements and
main phases of research activity were already being identified. There was a disappointing turnout
for the first focus group, though the second, and arguably more critical, group was well attended.
The project team had deliberately focused the one-to-one and focus group sessions to extract the
all the requirement and information about the system. It was believed that these would provide the
project with a broad spectrum of research activities, which proved to be the case. An obvious
drawback of such an approach was that the research process of these departments might not be
typical of other departments within the university and some users cannot generalize the
requirement of all the users of the system.
The online survey with its broad userbase was a way of mitigating the risk of leaving the
requirements unstated and eliminating the potential bias that might result from restricting the
number of disciplines involved.
The researchers involved in the one-to-one and focus group sessions were informed of the survey
and encouraged to promote it as far and wide as they could. Even though it was recognised from
the outset that not all researchers would complete the questionnaire, the number of responses was
higher than expected and it was felt that the views expressed by the respondents could be deemed
to be representative of the research body of the university.

20. 15
Body
Questioneers
a) To Dean
1. Do you want an overall analysis of each and every Department or each and every tasks
done by the Department?
2. Do you want an overall analysis of each and every student or each and every individual
records of student?
3. Do you want your system to be remotely accessible?
b) To HOD
1. How your Department Execute?
2. How your Department interact with other department?
3. How would you like to maintain the student records?
c) To System Maintainer
1. Have you ever maintained this type of system or not?
2. Do you need some training or not?
d) To user
1. How easy do you want the system to be?
2. What are the function that you would like to have in our system?
Requirements elicitation and gathering
User requirements
 Student records of all faculty of University [undergraduate, taught postgraduate and
research students]
 Staff information
 Research information [research publications and research grand]
 Faculty performance information
 Student Admission information
 Web based interface
 Performance statistics [No. of students registered, research publication…etc]
 Module review back function

21. 16
 Student project information
 Tutorial support
 Electronic version coursework schedule
 Electronic version module timetable
 Electronic coursework submission
 Electronic reporting system (e.g. equal opportunity report, self-checking report. etc.)
 Student and staff forum
 Conference notification to dedicated members of university
 Apply external examinations
 Study plan for the whole university life
 Class homepage facilities
 Remote access to key resources
 Simple search interface
 Links to datasets from reference lists
 Links from databases to library resources
 Alerting service for new journal articles.
 Eliminate cost barrier of document supply
 Prompt supply of documents.
 Easier access to datasets (including non-academic datasets) for authorized users
 Support for record download and sharing
 Online proposal submission to ethics committee
 Support for conference attendance
 Streamline Research Support Unit activities
 Links to full costing information, especially for staff costing (easy access essential)
Collaboration with partners
 Applications embedded in collaborative tools
 Easy setup of memberships and user interface for collaborative tools
 Ability to push information to all members of a group
 Alerting information to a group member
 Tools capable of handling large files
 Data security

22. 17
 Acceptable performance/availability of tools
 Enforced (no cost) use of collaborative tools
 Shared document/file versioning
 Desktop videoconferencing
 Group diary
 Help finding collaborators
 Help finding expertise within university
 Links between the collaborative tools and repositories (the bid repository and the research
output repository)
 Collation and digest of email lists
 Threaded message board
 Support to maximise benefit of collaborative tools
 On line chat
 Multi-lingual support
 Building up new interest groups
 Tools for online voting, surveys, feedback gathering
Requirement specification
User requirement
Need Priority Concern Current solution Purposed solution
Effective and
efficient integrated
university
department
information system
High
Mass information
management is
difficult and time
consuming
Require intensive
data entry by staff
and paper work
User “Self Service”
approach using
internet based central
database information
distribution system
Database integrity
and efficient
accessibility
High
Data can be loss due
to security breaches,
improper database
design and hardware
failure
Firewall and virus
detection software
Firewall and virus
software , coupled
regular data backup,
use of MYSQL and
sound internal

23. 18
Interface requirement
password management
schemes
Information accuracy
High
The wrong
information may
mistake in serious
mistake
Human data input
and paper record
system involve
create human
mistakes
Update daily by the
concerned body,
nobody can access the
system while they are
in the system except
certain position staff
Ease and authorized
access of the system
High
All the members of
university cannot
access all the
information
Level of the users
are defined and
grant them
authorization
accordingly
Level is maintained
and password and
login scheme is used
to restrict the
authorization of
different level of
users.
Notification of
conference and
events happening to
respective faculty
and concerned bodies
High
Information
deployment should
be electronically and
surety that all
concerned bodies
get the information
Notification on all
the concerned
bodies’ account
they created for
the system
Notification to
concerned bodies and
surety
acknowledgement
from the concerned
bodies ,to ensure that
notice have
successfully deployed.

24. 19
Other requirements
 Video conferencing with faculty members and administration
 Report generation of the achievements and improvement of the students
 Online examination system
 Complain registration
 Discussion platform for the students and lecturers
 Expenses report generation module
Interface Interface type Interface method Description
Any visitor to
system
Human-System Web browser Any person can view general
information about university via a web
browsing using internet connection
Student to system Human-System Web browser
login
Student will have a password to login
into the system
Faculty staff to
system
Human-System Web browser and
login
Staff will have to choose the faculty
and enter the password to login into
system, then they can access
confidential staff only resources and
service
Administrator to
system
Human-System Web browser and
login or direct
login
Administration will have higher
privilege for system, can view all the
information of university
Database to dynamic
web-page
System-System Eg: perl script Unique web page can be created for
the database providing relevant
information to the individual users
Student faculty
records database to
university central
database
System-System Eg:ODBC link University database regularly update
the local database ensure student data
consistency and information integrity

25. 20
Requirement validation
In the requirement validation, we check the completeness of the requirements which means either
gathered requirements are correct, complete or not. We analyzed the consistency of the
requirements to determine whether there are any contradictory constraints or not or different
description of same system function. We check for the realism of the system to identify whether
the system can be implemented in the existing technology. Here, we reviewed the requirements
engineering process. The main objective to analyze the validation and verification of RE process
to identify and resolve the problems and highly risk factors of software.
Requirement management
Finally, in Requirements management phase, we resolved the issues and conflicts of users. The
requirement management is a political game. Here, we involved to control the expectations of
stakeholders from software, and put the requirements rather than in well-meaning by customers
but meaning full by developers, so they can examine that, they actually full fill the user’s
requirements.

26. 21
DESIGN
Framework
IUDIS is to collect all the information of the university and carry out its efficient operation. IUDIS
collected information from all the faculty and course offered by these faculty and their expenses
in various research works. The IUDIS system is built around a series of interrelated components
that collect institution–level data in the areas of enrollment, program completions, graduation rates,
faculty, staff, finances, institutional prices, and student financial aid.
The IUDIS survey data collection occurs at different points during the different phase of system
development involving multiple web–based components. These components request information
from other components about the activities or characteristics happening in different parts of
university. These components include the following:
 Enrollment: Component collects data of the activities carried out and helps the administration
to analyze the activities of the university. For example student component collects the data
annually on the number of full– and part–time students enrolled in different faculty and the
other jurisdictions by level (undergraduate, graduate, first–professional) and by race/ethnicity
and gender of student. The component also involves in reporting attendance status of the
students and working faculty member to the administration which help to analyze the
enrollment of students and faculty member in the university.
 Completions: These component collects data annually on recognized degree completions and
the teaching duration of the professors of different faculty of different by level (associate’s,
bachelor’s, master’s, doctor’s, and first–professional) and on other formal awards by length
of program.
 Faculty Financial Aid: This component collects the number of full–time, first–time,
degree/certificate–seeking students receiving aid compared to the total number of full–time,
first–time students, as well as the number of students receiving each type of financial
assistance and the average amount received by type. Tis component also collect information
about the number of retired and needed professors obtaining the financial aids from the
university.

27. 22
 Prices section of Institutional Characteristics : This component collects the basic institutional
data that are necessary to sort and analyze the university database. This components collects
information on tuition and required fees, room and board charges, books and supplies and
other expenses charged to various types of students and the professors. It also involves in
collecting information on institutional revenues and expenditures (Finance) as well as faculty
and other staff (Salaries, Fall Staff, and Employees by Assigned Position).
Block diagram of the system

28. 23
1) webpage
2) login module
3) signup module
Administration
Information module
-> provide information
about the activities by
different faculty
Analysis module
-> Analyze the report
provided by faculty
about their progress
and activities
Activities module
-> provide infromation
about the research
and conference
performed by
different faculty
Expenses module
-> keep the record of the
expenes in university in
importing goods and
services and research
work of different faculty
faculty
Enrolled module
-> keep the records of
students and professor
enroled in the faculty
faculty detail module
-> keep the detail records
of professor and other
staff in the faculty
storage module
-> store the research
paper for distributing to
suttudent
reserach info module
-> provide the detail
infoemation about the
eserach peroormed by the
students and financial
support provided to them
communication module
-> to communicate with
administration and between
faculties
expense module
-> keeps the expense of research and
other services and laborotary of
faculty
Achievement module
-> keeps the achievement details
of differnet students
Student
student detail module
Achievements detail
faculty course detail
research paper
online exam module
Discussion module
online tutorial module
Complain registration
module
study material module

29. 24
System design
For designing our system we use the UML diagram. UML Diagrams are considered as a main
component in requirement engineering process and these become an industry standard in many
organizations. UML diagrams are useful to show an interaction, behavior and structure of the
system. It is necessary to integrate System Models with the UML diagram to overcome the
requirements errors i.e. contradiction, ambiguities, vagueness, incompleteness and mixed values
of abstraction. UML diagrams are important to understand the complexity of system. UML
describes the behavior and structure of a program. Also, they describe the interaction of
components with the system. These include Use Case, Class, Activity and many other diagrams.
UML diagrams are easy to understand by the users, developers and domain experts whereas the
formal methods are difficult to understand by the users, domain experts and developers as well.
Here, we mainly focus on UML Sequence diagram, as sequence diagram is an interaction
diagram which shows the interaction and proper sequence of components (Methods, procedures
etc.) of the system.
Unique Features of Sequence Diagrams
There are some unique features of Sequence diagrams and also reasons for choosing sequence
diagrams for this research purpose, which are:
 Sequence Diagrams are used to show the priorities of steps/modules of system, Lower step
denotes to the later.
 Reverse Engineering of UML sequence diagrams are used to support reverse engineering in
software development process.
 It shows a dynamic behavior of system and considered as good system architecture design
approach.
 Sequence diagrams include the Life line of the objects, and it can be easily integrated because
of Time dimension.
 We can use messages to make it understandable by all stakeholders.
 We can also use loops, alternatives, break, parallelism between complex components of
system and many more.

30. 25
Sequence diagram of different module
Sequence diagram for sign in

31. 26
Sequence diagram for login
Sequence diagram for student

32. 27

33. 28
Sequence diagram for administration
Sequence diagram for faculty

34. 29

35. 30
PROJECT SCHEDULING
Gantt chart

36. 31