Requirement Engineering and Process model CHAPTER ONE Introduction Human Resource Management System of University is a large database system which can be used for managing the regular activities of a University. Human Resource Management System of University allows users to store almost all the University Employee information electronically. 1.1 Motivation We have chosen database as our project area because of our well understanding of database and programming rather than other fields like Networking, Image Processing, Graphics etc. We have decided to develop a University management database because University Management System is a crucial area from service delivery perspective and people have started realizing the importance of process automation in University’s sand it’s IT application that is used to empower Universities in managing their activities. University Management System is configurable and can be configured to meet most individual University’s needs. It makes University staff's life easier than ever. Using University Management System, finding university’s employee information is just a few seconds away which might have cost hours, or even days, manually. Now a day, in our country most of the Universities are running all their managerial activities manually and the problem of a manual system is that it very time consuming, inefficient and error prone. That’s 1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Requirement Engineering and Process model
CHAPTER ONE
Introduction
Human Resource Management System of University is a large database system which can be used
for managing the regular activities of a University. Human Resource Management System of
University allows users to store almost all the University Employee information electronically.
1.1 Motivation
We have chosen database as our project area because of our well understanding of database and
programming rather than other fields like Networking, Image Processing, Graphics etc. We have
decided to develop a University management database because University Management System is
a crucial area from service delivery perspective and people have started realizing the importance of
process automation in University’s sand it’s IT application that is used to empower Universities in
managing their activities. University Management System is configurable and can be configured to
meet most individual University’s needs. It makes University staff's life easier than ever. Using
University Management System, finding university’s employee information is just a few seconds
away which might have cost hours, or even days, manually. Now a day, in our country most of the
Universities are running all their managerial activities manually and the problem of a manual
system is that it very time consuming, inefficient and error prone. That’s why we have chosen the
automation of University Management System as our project topics.
1.2 Overview
School Management System is imagined by first truly scalable, windows-based school management
package with the power to revolutionize the way that schools are run. School management
software is more than just a technology solution - it is an educational system that will improve the
way school is managed.
The School Management System basically divided into 4 modules such as Office Management,
Academic Management, Library Management and Finance & Accounts Management. The functions
of these modules are given below.
1
1.2.1 Office Management
This module starts functioning once an employee gets a job into the university. The module
“employee information” the complete profile of an employee in a very systematic way from
personal information to alumni information. The module helps the human resource staff to save
much of their time in data entry and record maintenance.
Some functions of office management module are given below:
New Recruitment process.
Maintaining employer’s data.
Issuing Leave, Transfer to the employees.
Providing information like category wise list of employees, full time as well as part time.
1.3 Objective
The main objective of this project is to develop an automation system for managing university
activities by applying software engineering principles, tools and techniques in an efficient way. We
have chosen a reputed private University named “Eastern University” (EU) as our study case.
1.4 Outline
Chapter 1 will discuss a general overview of the nature and purpose of the software.
Chapter 2 will discuss the Requirement Engineering & Process Model.
Chapter 3 will discuss the Existing System Analysis & Proposed Database System for School
Management.
Chapter 4 will discuss the Project Estimation.
Chapter 5 will discuss the System Design & Tools required for this project.
Chapter 6 will discuss the Implementation & Testing procedure of this project.
Chapter 7 will discuss the Conclusion & Future Scope of this project. CHAPTER TWO
Requirement Engineering & Process Model
Introduction
2
Requirement engineering helps software engineers to better understand the problem they will
work to solve. It encompasses the set of tasks that lead to on understanding of what the business
impact of the software will be, what the customer wants, and how end-users will interact with the
system. Requirement engineering must be adapted to the needs of the process, the project, the
product and the people doing the work. From a software process perspective requirement
engineering is a software engineering action that begins during the communication activity and
continues into the modeling activity.
2.1 Requirement Engineering
Requirement engineering is the primary major activity following the completion of a statement of
need ensuing from the predevelopment process in a software process. Requirement engineering is
defined in terms of its major activities –
Perceptive problems
Solution resolve
Specification of a solution that is testable, understandable, maintainable and that satisfies
project quality strategy.
The principle of a reasonable requirement engineering process is software requirements
specification. Requirement engineering process initiates with requirements of problem analysis.
Requirements engineering process is accomplished through the execution of seven distinct
functions: inception, elicitation, elaboration, negotiation, specification, validation and management
are given below.
2.1.1 Inception
At project inception, software engineers ask a set of context-free question to the customer. The
intent is to establish a basic understanding of the problem, the people who want a solution, the
nature of the solution that is desired and the effectiveness of preliminary communication and
collaboration between the customer and the developer [1].
2.1.2 Elicitation
3
It certainly seems simple enough-ask the customer, the users, and others what objectives for the
system or product are, what is to be accomplished, how the system or product fits into the needs
of the business, and finally how the system or product is to be used on a day-to-day basis.
2.1.3 Elaboration
The information obtained from the customer during inception and elicitation is expanded and
refined during elaboration. The end result of elaboration is an analysis model that defines the
informational, functional and behavioral domain of the problem.
2.1.4 Negotiation
The requirement engineer must reconcile these conflicts through a process of negotiation.
Customers, users and other stakeholders are asked to rank requirements and then discuss conflicts
in priority.
2.1.5 Specification
The specification is the final work product produced by the requirements engineer. It serves as the
foundation for subsequent software engineering activities and describes the function and
performance of a computer-based system and the constraints that will govern its development.
2.1.6 Validation
Requirement validation examines the specification to ensure that all software requirements have
been stated unambiguously that inconsistencies, omissions and errors have been detected and
corrected and that work products conform to the standards established for the process, the
project and the product.
2.1.7 Requirement Management
The requirement management is a set of activities that help the project team to identify, control
and track requirements and changes to requirements at any time as the project proceeds.
Requirement management begins with identification and each requirement is assigned a unique
identifier.
2.2 Risk Analysis
4
Risk is the chance that outcomes will not turn out as planned and risk analysis are a series of steps
that help a software team to understand and manage uncertainty [1].
2.2.1 Software Risk
Risk always involves two characteristics
Uncertainty – the risk may or may not be happen that is, there are no 100% probable risks.
Loss – if the risk becomes a reality, unwanted consequence or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss
associated with each risk. To accomplish this, different categories of risks are considered.
Projects risk threatens the project plan. That is, if projects risk become real it is likely that
project schedule will slip and that cost will increase. Projects risk identifies potential
budgetary, schedule, personnel (staffing and organization), resource, stakeholder, and
requirements problem and their impact on a software project.
Technical risks threaten the quality and timeliness of the software to be produced. If a
technical risk becomes a reality, implementation may become difficult or impossible.
Business risks threaten the viability of the software to be built.
2.2.2 Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan (Estimates,
schedule, resource loading etc). One method for identifying risk is to create a risk item checklist
that can be used for risk identification and focuses on some subset of known and predictable risks
in following generic subcategories [1].
Product size – risk associated with the overall size of the software to be built.
Business impact – risks associated with constraints imposed by management or the
marketplace.
Customer’s characteristics – risk associated with the sophistication of the customer and
the developer’s ability to communicate with the customer in a timely manner.
Process definition – risk associated with the degree to which the software process has
been defined and is followed by the development organization.
Development environment – risk associated with the availability and quality of the tools to
be used to build the product.
5
Staff size and experienced – risks associated with the overall technical and project
experienced of the software engineers who will do this work.
2.2.3 Risk Mitigation, Monitoring and Management
All the risk analysis activities presented to this point have a single goal – to assist the project team
in developing a strategy for dealing with risk. An effective strategy must consider three issues: Risk
avoidance, Risk monitoring and Risk management contingency planning.
To mitigate the risk, project management must develop a strategy for reducing turnover. Among
the possible steps to be taken are-
Meet with current staff to determine causes for turnover.
Mitigate those causes that are under our control before the project start.
Once the project commences, assume turnover will occur and develop technique to ensure
continuity when people leave.
Organize project team so that information about each development activity is widely
dispersed.
Define documentation standard and establish mechanisms to ensure that documentations
are developed in a timely manner.
Conduct peer reviews of all work.
Assign a backup staff member for every critical technology.
The project manager monitors factors that may provide an indicator of whether the risk is
becoming more or less likely. The following factors can be monitored:
General attributes of team members based on the project pressures.
The degree to which the team has jelled.
Interpersonal relationships among team members.
Potential problems with compensation and benefits.
6
The flowchart of risk analysis is given in Figure 2.1.
Figure 2.1: Flowchart of Risk Analysis
Here, Fig 2.1 shows the step by step functions of risk analysis. In step-1 risks are identified, step-2
analyzes those risks, step-3 prioritizes those risks according to some criteria, step-4 designs plan for
those risks, and step-5 monitors risk and mitigation the plan. If any new risk occurs then again step-
2 is executed and same procedures (discussed above) are followed. If there is no risk occurs then
all risks are solved.
2.3 Software Process Models
A structured set of activities are required to develop a software system. A software process model
is an abstract representation of a software process. Each process model represents a process from
a particular perspective that only provides partial information about the process.
There are several popular process models such as
Waterfall Model
Incremental Model
7
Rapid Application Development
Prototyping Model
Spiral Model
Extreme Programming (XP)
2.3.1 Waterfall Model
Among these, the Waterfall Model [2] is followed in this project. It is a sequential software
development model (a process for the creation of software) in which development is seen as
flowing steadily downwards (like a waterfall) through the phases of Requirements Analysis and
Definition, System and Software Design, Implementation and Unit Testing, Integration and System
Testing and Operation and Maintenance.
The phases are described in next page:
a) Requirements Analysis and Definition: The system’s services, constraints and goals are
established by consultation with system users. They are then defined in detail and serve as
a system specification.
b) System and Software Design: The system’s design process partitions the requirements to
either hardware or software systems. It establishes overall system architecture. Software
design involves identifying and describing the fundamental software system abstractions
and their relationships.
c) Implementation and Unit Testing: During this stage, the software Design is realized
as a set of programs or program units. Unit testing involves verifying that each unit
meets its specification.
d) Integration and System Testing: The individual program units or programs are integrated
and tested as a complete system to ensure that the software requirements have been met.
After testing, the software system is delivered to the customer.
e) Operation and Maintenance: Normally (although not necessarily) this is the longest life-
cycle phase. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life cycle and improving
8
the implementation of system units and enhancing the system’s services as new
requirements are discovered.
The flowchart of the Waterfall Model is given in Figure 2.2.
Figure 2.2: Flowchart of Waterfall Model
Some major advantages and disadvantages of Waterfall Model are given below.
Advantages:
Having fewer errors.
System requirements are identified before programming starts.
Changes are minimized to the requirements as the project proceeds.
Disadvantages:
Most time consuming process model.
Huge amount of paperwork is necessary.
Does not allow going next stage before finishing the previous stage.
2.4 Summary
9
This chapter is presented to provide the readers a clear view of the SDM. When developing the
software a software developing model has to be chosen. For this software the Waterfall Model has
been chosen. Risk analysis and management are a series of steps that help a software team to
understand and manage uncertainty.
CHAPTER THREE
Existing System Analysis & Proposed System
Introduction:
Requirement analysis is a software engineering task that bridges the gap between system
engineering and software design. It allows the software engineer to refine the software allocation
and builds the models of the data, functional and behavioral domains that will be treated by
software. Among the entire software process models that have been discussed in the chapter 2,
the Waterfall process model has been chosen for this particular project because of its relatively
simple structure. Another feature of this model is that it is easy to follow.
3.1 Existing System Analysis
As we told in chapter-1 that we have chosen a university named Eastern University as our study
case. It is situated at Dhanmondi in Dhaka and was established in 2002. The human resource
management system of eastern university manage the recruitment, training, promotion, transfer,
retirement etc of an employee.
The existing system analysis is the first step for requirement analysis. Currently the existing system
is running manually.
3.1.1 Some Major Functionalities of the Existing System
Keep record of all the previous and current employees’ information.
Search a particular employee.
Update the status of employees.
Add, delete and modify the information of employee.
Keep record of all the salary of employee.
Add or modify the salary sheet.
10
3.1.2 Drawbacks of the Existing System
The manual system is very slow considering the growth of data and its vast management
specification of the system required.
The amount of the data is increasing day-by-day. But the system needs more manpower to
get the whole management intact, though still it remains very slow.
Any required information needed by authority need to wait a long delay of time and linked
information searching is a cumbersome and tedious work to do.
Updating any information is cost incuses because it requires checking of multiple files.
The updating becomes unreliable due to mistakes sometimes.
3.2 The Proposed System
The Proposed system means a new system that should have the ability to overcome the problems
of existing one. After analyzing the problem of existing system, the following modules for the
proposed system have been established.
3.2.1 Some Major Advantage of the Proposed System
Manage your own Security. The system will be user friendly with the informative graphical user interface. The system can give current and updated information to its user group. This system will save the time and work load to the management. The system will provide security facility to restrict unauthorized access. The system will provide the option to view and print all the necessary reports. The system will give the option to search necessary information.
3.2.2 User Groups of the Proposed System
Two types of user groups have been proposed for this project. These are Administrative user and
Normal user.
Administrative user
o Add new user and give authority to a normal user.
o Add, modify and delete a employee and all of their relevant information.
11
o Generate all kinds of report.
o Check all kinds of information.
Normal User
o Add employee information.
o Generate authorized report.
o Generate cash transaction.
o Add, modify, delete and search authorized information.
3.3 Summary
This chapter has discussed about the Existing System Analysis and Proposed System. Next chapter
will discuss about the Project Estimation.
CHAPTER FOUR
Project Estimation
Introduction
Before starting the project the project manager and software team must estimate the works to be
done, the resources that will be required and finally the time that will be elapsed from start to
finish.
4.1 Methodology
When the software process model had selected, the common process framework had been
adapted to it. A Common Process Framework is established by defining a small number of
framework activities that are applicable to all software projects regardless of their size or
complexity. Common Process Framework consists of several software engineering activities [1]:
Customer Communication
Planning
Risk Analysis
Analysis and Design
Engineering:
a) Coding
b) Testing
Deployment
12
Customer communication is required to perform requirements engineering activities. To engineer
the requirements of software the following customer communication activities have been
performed:
Reviewed the customer request.
Conducted several informal and formal meeting with the authority.
Developed a statement of scope and prepared the list of features of DST.
4.2 Task Scheduling
Software project scheduling is an activity that distributes estimated effort across the planned
project duration by allocating the effort to specific software engineering task or activities.
There ware four managerial charts we had to consider for our project and the project manager was
responsible for observing all. The managerial chats are:
1. Activity Chart
2. Human Resource Requirement Chart
3. Physical Facility Requirement Chart
4. Finance Management Chart
4.2.1 Activity Chart
Activity chart shows which task has to do when and how much time will be allocated for each
activity. As we told in chapter 3 that we have chosen waterfall process model for our project and
first we collected the requirements from the DST authority. Then we planned & gathered risk for all
of those requirements and after analyzing all requirements the design part started. The coding and
testing part has been completed one after another.
The activity chart of our project is given in Fig 4.1.
13
Fig 4.1: Activity Chart
4.2.2 Human Resource Requirement
May people can be involved in a single software project, in our project Md. Mahfuzul Islam and
Siddika Mustafiz ware responsible for completing the project. To develop the project we had acted
as system analyst, database administrator, programmer as well as tester but two messengers had
to hire. First the customer communicator person had collected the requirement then the analyst
analyzes current system and related risk. After analyzing the current system, a new system had
proposed and deigned. The programmer implements the software by completing the code. For any
software project, the most important and difficult part is to finding errors. The tester was
responsible to do so. The most important role was the project menagerie and this person involved
to the whole project duration. In case of a real life situation, the following chart depicts the human
resource requirement for this project and the time duration for each of the resource personnel
required.
Fig 4.2: Human Resource Chart
Duration:
1. Project Manager – 211.25 days
2. Customer Communication Personnel – 28.25 days
14
3. Planning & Scheduling Personnel – 34.25 days
4. Risk Analysis Personnel – 29.75 days
5. Analysis & Design Personnel – 59.25 days
6. Coder – 25.50 days
7. Tester – 31.25 days
8. Deployment Personnel – 3 days
9. Messenger – 211.25 days
4.2.3 Physical Facility Requirement
The physical facility requirement chart shows the physical facilities needed during the development
of the project and also for how long each resource is required.
Hardware Requirements:
# Personal Computer: 2
Processor : Pentium dual core 2.5GHz
RAM : 3GB
Hard Disk : 320GB
# Personal Printer: 1
Software Requirements:
Microsoft Widows XP
Microsoft Access 2007 (for developing back end)
C#.Net (for developing front end)
Crystal Report 10.0 (for reporting)
Microsoft Word 2007 (used as editor)
Microsoft Visio 2007( for drawing charts)
The physical facility chart of our project is given in Fig 4.3 in next page.
15
Fig 4.3: Physical Resources Chat
4.3 Software Cost Estimation
For the estimation of the total cost of software, several categories of cost should be considered.
After calculating the total cost estimation of our project, a cost benefit analysis had been
performed to observe whether our project is feasible or not.
The software development cost for this project includes –
Human Recourse Cost
Physical Facilities includes:
o Computer/Printer Cost, Software Cost, Building Rent, Furniture, Decoration/