qwertyuiopasdfghjklzxcvbn

mqwertyuiopasdfghjklzxcvb
nmqwertyuiopasdfghjklzxcv
bnmqwertyuiopasdfghjklzxc
vbnmqwertyuiopasdfghjklzx
cvbnmqwertyuiopasdfghjklz
xcvbnmqwertyuiopasdfghjkl
Paying Guest
zxcvbnmqwertyuiopasdfghjk
Accommodation System
lzxcvbnmqwertyuiopasdfghj
[Automated Paying Guest Management
System]
klzxcvbnmqwertyuiopasdfgh
[18-04-11]

jklzxcvbnmqwertyuiopasdfg
hjklzxcvbnmqwertyuiopasdf
Akshay Khandelwal
Malavikka Sharma

ghjklzxcvbnmqwertyuiopasd
fghjklzxcvbnmqwertyuiopas
dfghjklzxcvbnmqwertyuiopa
sdfghjklzxcvbnmqwertyuiop
asdfghjklzxcvbnmqwertyuio
pasdfghjklzxcvbnmqwertyui
opasdfghjklzxcvbnmrtyuiopa
sdfghjklzxcvbnmqwertyuiop
 ACKNOWLEDGEMENT

On the successful completion of our project “Paying

Guest Accommodation System”, we would like to express
our sincere gratitude to all the teachers and friends
who helped us in the completion of this project.

We are sincerely thankful to Ms. Deepali Jain, the

project-in-charge for being a constant source of
help, knowledge and encouragement.

We are also grateful to Mr. Amit and Mr. Sanjay for

all the help they provided during the labs.

Akshay Khandelwal
Malavikka Sharma
 CERTIFICATE
This is to certify that the project entitled
Performance appraisal system by Abhigya Jain and
Mahima Garg has been carried under our supervision.
The project has been submitted as per the
requirements in the fourth semester of computer
science (H)

Teacher-in-charge
(Ms. Deepali Jain)
 INDEX
1.Introduction

2.Problem statement

3.Requirement analysis

3.1. Requirement elicitation

3.1.1. Interview

3.1.2. Questionnaire

3.1.3. Facilitated application

specification techniques

3.1.4. Quality function deployment

3.2. Software model used

3.3. Analysis modeling

3.3.1. Entity relationship diagram

3.3.2. Data flow diagram(for existing

system)

3.3.3. Use case diagram

3.3.4. Data definition(for existing

system)

3.3.5. State transition diagram

3.4. Timeline chart

3.5. Feasibility study

3.6. Risk analysis

 3.7. Software requirement specification

4.Design phase

4.1. Data flow diagram(for proposed

system)

4.2. Structure chart

4.3. Data definition (for proposed system)

5.Test cases

6.Screen shots

Bibliography
 Synopsis

Problems faced by clients:

Today, paying guest accommodations have evolved

into a great business. Large number of students come
and stays over there from different parts of world
and with different economic backgrounds. Everybody
has different requirements accordingly. Some of them
need air conditioned room while others may need
just a non-A.C. Room but with the refrigerator or
Television. Moreover there is a limit that students
cannot stay out after a certain time. So as the
business is growing day by day.

It gets difficult for the families to keep the

record of students. The record of the raw material
used in the kitchen and the attendance. They get a
problem even in managing the collection of the money
from different students which have different rooms
different food demands.

Present Scenario

These days the families are manually recording

there data and do a lot of labour in keeping an
account of everything. The labour, the raw material
used, the students, the attendance and everything.
Some even are unable to use the efficient use of
their resources.

What software will do?

The software we intend to make will be a

sufficient replacement for all the registers
maintained for keeping the records of various
students. Their identity will be maintained in the
software. The student will be allotted a registration
number, through which all his/her information will be
obtained. Fee collection will be very easy after the
software. Automatic bill will be generated by the
software according to the usage of resources by the
accommodant.
 The Process model

Through the interview questions and interview, we

have analysed that our client has a legitimate need
of the software but is clueless about the details. So
we have decided to use the Prototyping model in our
project. None of the customer has ever asked of such
a software so even we, the developers don't have
enough idea that what the customer exactly wants, and
unsure about the algorithm.

So we (software developers) met the client and

decided on the overall objectives for the software,
identified whatever requirements are known, and
outlined areas where further definition is mandatory.
A “quick design” then occurs. This quick design is
called the “Prototype”. Our prototype will focus on
the aspects of the software that will be visible and
usable by the user.
 This prototype is then evaluated by the
customer/user and used to refine requirements for the
software to be developed. Iteration occurs as the
prototype is tuned to satisfy the need of the
customer, while at the same time enabling us with
better understanding what needs to be done.

Requirement Analysis

Requirement analysis is a software engineering task

that bridges the system level requirements
engineering and software design. Requirement
engineering activities result in the specification of
software's operational characteristics, indicate
software’s interface with other system elements, and
establish constraints that software must meet.

System
engineering

Software
requirement
analysis

Sofware
design

Figure: Analysis as a bridge between system engineering and

software design.
For requirement analysis in our project, we also did
the interview with the client which lasted for about
1 and half hour. Through interview we got to know
about the clients requirements very clearly. Some of
the questions that were asked from the client
regarding the software were:-

Interview

Analyst: Who is going to get the benefit from the

software?
Client: The manager of our paying guest
accommodations, located in and around Delhi, is going
to get the benefit through this software. He has a
lot of manual work and has to maintain a lot of data
in the registers. He sometimes even makes mistakes in
the calculations of the fees at the end of the month.

Analyst: Who will use the end-user of the software?

Client: The manager and the residents of the paying
guest accommodation will be the user of the software.

Analyst: By what time do you need the delivery of the

software?
Client: Within 2 months.
Analyst: By what time you want to see the prototype of
the project?
Client: By the next 15 days.

Analyst: What are the educational qualifications of

the user of the software?
Client: The user of the software will be at least a
graduate.

Analyst: What all features do you need in the

software?
Client: I want the software to be made which would be
a full fledged replacement for the manual register
work that is done by the manager.
− The software should keep the information of
the paying guests that are staying in and the
rooms and facilities that are being provided
to them.
− The software should provide a unique
identification to each paying guest and a
unique bar code through which attendance can
be done easily using bar code reader devices.
− The software should keep the account of the
raw materials that are used in the kitchen.
− The software should even keep the attendance
record of cooks and maids.
− The software should automatically generate
the bills at the end of month.
 − The website should be compatible with the
software and it should be capable of booking
the rooms online, according to the needs of
the person.
− The software should be easy to use and a good
eye-candy.

Analyst: What is your budget for the software?

Client: The budget is under Rs. 1,00,000.

Analyst: Sorry, the budget of the software is

estimated to about Rs. 1,60,000. Are you comfortable
with this?
Client: That is fine.

Summary of the interview: This interview was

beneficial to both the developer and client in
following ways:

 The developer got to know the approximate

deadline for handing over the software.
 Both client and developer mutually agreed on
the approximate budget of the software.
 The developer was briefed by the client about
some special issues concerning the development
of the software.
 The developer got to know that the software
should be a web based application.
  The developer was briefed about the end-users
of the software; hence its development shall be
planned in a more directed manner.

Questionnaire

Questionnaire is one of the fastest and easiest ways

to know the requirements of the user. The persons who
are going to use the software know well what all his
major requirements would be in the software. The
persons also who come to stay in the paying guest who
will use the website to book his/her rooms should be
comfortable with the website. So questionnaire is the
only mode through which we can meet their
requirements too. We have attached one sample
questionnaire in the following page.

Q.) Have you ever booked paying guest rooms before

online?

 Yes
 No
Q.) Do you get any difficulty in finding the paying
guest suitable for you?

 Yes
 No

Q.) How do you often find a suitable paying guest for

you?

 Dealers
 Inspection
 Friends
 Pamphletes

Q.) What web browser do you generally use?

 Internet explorer
 Mozilla Firefox
 Google chrome
 Opera

Q.) Is the manual work a lot, so that the work needs

automation through computer software ?

 Yes
 No
Q.) On what the manual work done ?

 Computer/Spreadsheet
 Registers

Q.) What type of software do you want for the

replacement of manual work?

 Software
 software + website
 website

Q.) Do the guests going to get any benefit from this

sofware?
.....................................................
.....................................................
.....................................................
.....................................................

Q.) You want the payment to be done on website

through:-

 credit cards
 debit cards
 cash cards
 through the banks

 through net banking

Summary of the questionnaire: The survey brought
highlighted the following points:
• Most of the end-users’ fall in the semi urban
category of population, therefore, the products
bought such users need to be given a priority.
• The software so developed should be most
compatible with the Google Chrome internet
browser, since this is the most used web browser.
• The end-users mostly have a broadband connection;
therefore software should be fine tuned for
handling bandwidth of a broadband connection.
• People mostly go out for shopping on a monthly
basis. This fact needs to be accounted for when
developing the application.
 Quality Function Deployment

QFD, i.e. Quality Function Deployment is a customer-

oriented approach to product and service innovation.
It guides managers through the conceptualization,
creation, and realization of new products and
services.

QFD identifies 3 types of requirements:

1) Normal requirements: The objective and goals that

are stated for a product or system during meetings
with customer. If these requirements are present the
customer is satisfied. Examples of normal
requirements are requested types of graphical display
etc.
2) Expected requirements: These requirements are
implicit to the product or system and maybe so
fundamental that the customer does not explicitly
state them. Their absence will call cause great
dissatisfaction. For e.g.: ease of human/machine
interaction, etc.

3) Exciting requirements: These go beyond the

customer's expectation and prove to be very
satisfying when present.eg: word processing software
is requested with STD features.

The requirements and corresponding functionalities

(technical requirements) collected through interview
process and the questionnaire are classified as
follows:

• Normal requirements:
 The software should keep the information
of the paying guest that are staying in
and the rooms and facilities that are
being provided to them.
 It will keep the attendance records.
 It will keep the information about the
employees.
 It will keep all the details and
spending of the kitchen/ mess.

• Expected requirements:
  user friendly interface
• An eye candy interface that will be
very exciting to use.
• Customization of employee journals
 easy access
 Links and tabs
 Maintain records

• Exciting requirements:
 finger print interpreter
 Automatic bar code generation for all
the accommodants and employees

Setting, helping and keeping a track of employee

goals by means of pie diagrams that help in employee
evaluation
 DATA DICTIONARY

NAME: name of the accommodant/employee/local guardian

ALIASES: None

WHERE USED/HOW USED: Every employee/accommodant

provides for a page of personal information that
includes all his requirements and expectations from
paying guest accommodation, etc. that serves as the
basic level document maintained for every employee or
accommodant in the paying guest accommodation. The
accommodant also provides information about his local
guardians.
DESCRIPTION: name = a sequence of at most 20
characters.
Characters = (a-z)/ (A-Z)/’blank space’.

NAME: Father’s name

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation

DESCRIPTION: name = a sequence of at most 20

characters.
Characters = (a-z)/ (A-Z)/’blank space’

NAME: College name

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation.

DESCRIPTION: name = a sequence of at most 20

characters.
Characters = (a-z)/ (A-Z)/’blank space’

NAME: age

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation.

DESCRIPTION: age = maximum of 3 digit number, first

digit should not be 0.
Digit = 0, 1, 2, 3...9
NAME: gender

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation.

DESCRIPTION: gender= (M= male)/ (F = female).

NAME: permanent address

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation. The accommodant also
provides information regarding his local guardian’s
address.

DESCRIPTION: address = a sequence of at most 40

letters.
Letters = alphanumeric + special symbols.
Special symbols = blank space, comma, hyphen.
/, etc….
Alphanumeric = characters + digits
Characters = (a-z)/ (A-Z).
Digits = 0, 1, 2, 3...9.

NAME: mobile number

ALIASES: None

WHERE USED/HOW USED: Every accommodant provides for a

page of personal information that includes all his
requirements and expectations from paying guest
accommodation, etc. that serves as the basic level
document maintained for every accommodant in the
paying guest accommodation. The accommodant also
provides information regarding his local guardian’s
mobile number.

DESCRIPTION: contact number = a sequence of at most

10 digits.
Digits = 0, 1, 2, 3……, 9.
NAME: Room number

ALIASES: None

WHERE USED/HOW USED: Every accommodant according to

his/her requirements chooses a room after which he is
allotted a room number.

DESCRIPTION: room number=a sequence of digits

(depending upon the number of rooms in the
accommodation).
Digits=0,1,2,3…….,9.

NAME: Meal type

ALIASES: None

WHERE USED/HOW USED: Every accommodant according to

his/her requirements chooses a meal type (vegetarian
or non vegetarian) after which he is allotted A
(vegetarian) or B(non vegetarian).
DESCRIPTION: meal type=characters
Characters=A or B.

NAME: Unique identification number

ALIASES: None

WHERE USED/HOW USED: Every accommodant/employee

provides for a page of personal information that
includes all his requirements and expectations from
paying guest accommodation, etc. that serves as the
basic level document maintained for every employee or
accommodant in the paying guest accommodation. After
this the software generates a unique identification
number for each accommodant and employee.

DESCRIPTION: unique identification number =

alphanumeric characters
Alphanumeric characters=letters + numbers

NAME: Occupation

ALIASES: None
WHERE USED/HOW USED: Every accommodant provides
information regarding both his father’s and local
guardian’s occupation.

DESCRIPTION: occupation = a sequence of at most 20

characters.
Characters = (a-z)/ (A-Z)/’blank space’.

NAME: Room type

• Ac/cooler/fan
• Attached bathroom
• Floor number
• Number of accommodants in each room

• Building number of the room

ALIASES: None

WHERE USED/HOW USED: Every accommodant according to

his requirements and preferences chooses a room (an
ac/cooler/fan or an attached/unattached bathroom).He
also chooses whether he wants a single, double or
triple seater. After this the software generates a
floor number and a building number according to the
location of the room in the paying guest
accommodation.

DESCRIPTION: floor number and building number=digits

Digits=1,2,3………,9.

NAME: Monthly salary

ALIASES: None

WHERE USED/HOW USED: every employee in working in the

paying guest accommodation provides his basic
information which also includes his qualifications.
Based on his qualifications and talent he is given a
job with a deserving pay package.

DESCRIPTION: Monthly salary=digits.

Digits=0,1,2…….,9.

NAME: Job
ALIASES: None

WHERE USED/HOW USED: Every employee in working in the

paying guest accommodation provides his basic
information which also includes his qualifications.
Based on his qualifications and talent he is given a
job.

DESCRIPTION: job=a sequence of almost 20

characters(designation).
Characters = (a-z)/ (A-Z)/’blank space’.

NAME: Department

ALIASES: None

WHERE USED/HOW USED: Every employee in working in the

paying guest accommodation provides his basic
information which also includes his qualifications.
Based on his qualifications and talent he is given a
job in a particular department.

DESCRIPTION: department=a sequence of almost 20

characters.
Characters = (a-z)/ (A-Z)/’blank space’.
SOFTWARE REQUIREMENT SPECIFICATION

A Software Requirements Specification (SRS) is a

complete description of the behavior of the system to
be developed. It includes a set of use cases that
describe all the interactions the users will have
with the software. Use cases are also known as
functional requirements. In addition to use cases,
the SRS also contains non-functional (or
supplementary) requirements. Non-functional
requirements are requirements which impose
constraints on the design or implementation (such as
performance engineering requirements, quality
standards, or design constraints).
SRS for the Paying Guest Accommodation
Software:

Introduction

Purpose – The purpose of this document is to describe

the external requirements for a paying guest
accommodation system. What are the different
requirements for achieving the ultimate goals, what
are the views of different users about the system. It
also describes the interfaces for the system.

Scope – This document is the only one that describes

the requirements of the system. It is meant for
use by the developers and will be the basis for
validating the final delivered system. Any changes
made to the requirements in the future will have
to go through a formal change approval process.
The developer is responsible for asking for
clarifications, where necessary and will not make
any alterations without the permission of the
client.

Abbreviations – PGA : Paying guest accommodation

UID : Unique identification number

References – The documents that will be referenced

later in the SRS document are:
 ⇒ Questionnaire
⇒ Interview documentations
⇒ Data flow diagrams (DFD)

Overview – The following SRS document contains an in-

depth documentation of the product perspective that
is how the system (if not stand alone) relates the
requirements of the larger system to functionality of
the software and identifies various interfaces
between that system and the software. It contains
various software system attributes like reliability,
availability portability etc. The SRS is divided
into basic 6 sections with the first dealing with
acquainting the client with the new system; section 2
contains an overall description / general factors
affecting the product and its requirements. And
Section 3 specifies specific requirements of the
software.

The overall description

Product perspective – Product i.e. paying guest

accommodation software should be able to provide a
basic and easy interchange of information i.e. it
should be able to remove the communication gaps
between an employee and other employees and even
between employees and the students. It should be
compatible with all the operating systems.
Interfaces - The external users are the accommodants
staying in the paying guest accommodation. The
accommodants and employees can have an access to
their accounts for their records and history of
bills, their dues, and other information, etc.

System interfaces

⇒ Hardware interfaces - The external hardware

interface used for accessing the performance
appraisal software is the personal computers of
the various employees of the company. The PCs may
be laptops with wireless LAN as the internet
connections provided will be wireless.
⇒ Software interfaces - The Operating Systems can
be any version of Windows, Linux, UNIX or Mac
which supports TCP/IP protocols. Also visual
basic for coding and developing the software will
be used.

Communications interface - The communication

interface is a local area network through wireless
network routers preferably. As one of the important
functionality of our software is the feature of an
automated reminder system (through e-mails etc), a
network connection is a must for communication.

Memory constraints – the PGA software is light weight

software and thus shouldn’t pose any problems as far
as primary or secondary memory space is concerned. At
least 64 MB RAM and 512 MB space on Hard disk will be
required for running the application.

Operations – This software release will cover the

required automated management aspects of the
database. Database will be managed both manually by
the employees filling up their journals plus
automated on the basis of various database management
techniques for maintaining old or non-required data.
Database backup and recovery will also be handled
both by the Database administrator and the various
incorporated database management features.

Site adaptation requirements – The terminals at

client side will have to support the hardware and
software interfaces specified above.

Product functions - The following are the product

functions of the software to be developed:

⇒ The login box should also be on the official

website of the organization.
⇒ The password field should be secured.

⇒ After signing in and respective verification for

each employee that accesses the software, all
updates and new announcements for users should be
displayed in their respective a/c accordingly.
⇒ By clicking on the easy-interface-tabs the user
should be able to view current bill of today,
 dues, date of due for rent, notes, attendance,
fine to be paid and results.
⇒ User should be able to change the passwords and
the changes would be stored in the security
settings for the purpose of software maintenance
and checking’s.

User characteristics - Each employee is given a

unique identification worked out on the basis of his
registration number and other basic information
specific to an employee. So if he joins the
organization, only then he can login. This prevents
misuse, unauthorized access and hacking of the
product.

Constraints –
⇒ Due to limited features of DBMS being used
performance tuning features will not be applied
to the queries and thus the system may slow down
with the increase in number of records being
stored.
⇒ Due to limited features of DBMS being used,
database auditing will also not be provided.
⇒ Company should follow some security policy so
that no unauthorized access is permitted(in
addition to the login security provided by
software)
Assumptions and dependencies – The UID number of the
employees and the accommodants, the departments to
which they belong, posts and designations should not
change.

Apportioning of requirements – not required.

Specific requirements - This section contains the

software requirements to a level of detail sufficient
to enable designers to design the system, and testers
to test that system.

External interfaces

User interfaces: The external users are the students

searching for the PG online and the students
already staying in the paying guest
accommodation. The accommodants can have an
access to their accounts for their pupations
to their journals, assessments and
evaluations etc.

Hardware interfaces: The external hardware interface

used for accessing the paying guest
accommodation software is the personal
computers of the various accommodants. The
PCs may be laptops with wireless LAN as the
 internet connections provided will be
wireless.

Software interfaces: The Operating Systems can be any

version of Windows, Linux, UNIX or Mac which
supports TCP/IP protocols. Also visual basic
for coding and developing the software will
be used

Functions

Product Information Maintenance

Description - The system will be maintaining

information about the accommodant and role of each
and every employee of the organization. The
information maintained would be like: accommodant
name, occupation/designation, unique employee
identification number, building, years into PG, track
record etc.

The system will allow creation\modification\deletion

of accommodant information and special purpose graphs
that will help both the accommodant and the employees
in managing the accommodations.

Validity checks
i. Each and every employee and accommodant of the
organization has access to the paying guest
accommodation through specific login IDs
 ii. Login ID will be unique for each accommodant
and employee.
iii. Login ID will not be blank.
iv. Name will be unique for each employee.
v. Employee name will not be blank.
vi. Building name, room no. (to which an
accommodant belongs) should not be blank

Error Handling\Response to Abnormal Situations

If any of the above validations\sequencing flow does
not hold true, appropriate error messages will be
prompted to the user for doing the needful.

Bill Information Maintenance

Description - The system will be maintaining
information about the bills that each accommodant is
spending in mess/ canteen. The accommodant is also
tracked for its attendance and is fined accordingly.
The system will allow creation\modification\deletion
of due bills only by the employees for student does
not bear more than a certain credit at a time.

Validity checks
i. Each and every employee and accommodant of the
organization has access to the paying guest
accommodation through specific login IDs
 ii. Login ID will be unique for each accommodant
and employee.
iii. Login ID will not be blank.
iv. Name will be unique for each employee.
v. Employee name will not be blank.
vi. Building name, room no. (to which an
accommodant belongs) should not be blank

Error Handling\Response to Abnormal Situations

If any of the above validations\sequencing flow does
not hold true, appropriate error messages will be
prompted to the user for doing the needful.

Receipt Generation
Once the employees are done with
creation/modification/deletion of the student’s
information, the receipt copy is generated.

Performance requirements - The PCs used must be at

least Pentium 4 machines so that they can give
optimum performance of the product.

Logical database requirements

The following information will be placed in a

database:
1) Accommodant information: Name, contact details,
UID Number building no. and room no.
2) Building information: Building no., employees,
no. of rooms, manager.
 3) Account Information: User Name, User id,
Password, room no.

Design constraints – There are no design constraints.

It is a simple project. Any change in the PG can be
easily reflected back in the software. Like adding a
new room, change of mess charges, change of rental,
any such information can be easily modified
accordingly but only by the administration head of
the PG.

Software system attributes - The following are the

attributes of the product

• It should be equipped with current and archive

database.
• All records can easily be updated.
• It should facilitate employees, accommodant with
updating his/accommodants account, downloading or
uploading pages/documents etc from anywhere.
• Reliability
• availability
• security
• maintainability and portability
FEASIBILITY STUDY
A feasibility study was an evaluation of a proposal
designed to determine the difficulty in carrying
out a designated task. Generally, a feasibility
study precedes technical development and project
implementation. In other words, a feasibility
study is an evaluation or analysis of the
potential impact of a proposed project.

Technology and system feasibility

The assessment is based on an outline design of

system requirements in terms of Input, Processes,
Output, Fields, Programs, and Procedures. This can be
quantified in terms of volumes of data, trends,
frequency of updating, etc. in order to estimate
whether the new system will perform adequately or
not. Technological feasibility is carried out to
determine whether the company has the capability, in
terms of software, hardware, personnel and expertise,
to handle the completion of the project.

Economic feasibility

Economic analysis is the most frequently used method

for evaluating the effectiveness of a new system.
More commonly known as cost/benefit analysis, the
procedure is to determine the benefits and savings
that are expected from a candidate system and compare
them with costs. If benefits outweigh costs, then the
decision is made to design and implement the system.
An entrepreneur must accurately weigh the cost versus
benefits before taking an action.

Cost Based Study: It is important to identify cost

and benefit factors, which can be categorized as
follows: 1. Development costs; and 2. Operating
costs. This is an analysis of the costs to be
incurred in the system and the benefits derivable out
of the system.

Time Based Study: This is an analysis of the time

required to achieve a return on investments. The
benefits derived from the system. The future value of
a project is also a factor.

Legal feasibility

It determines whether the proposed system conflicts

with legal requirements, e.g. a data processing
system must comply with the local Data Protection
Acts.

Operational feasibility

Is a measure of how well a proposed system solves the

problems, and takes advantages of the opportunities
identified during scope definition and how it
satisfies the requirements identified in the
requirements analysis phase of system development
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. Schedule
feasibility is a measure of how reasonable the
project timetable is. Given our technical expertise,
are the project deadlines reasonable? Some projects
are initiated with specific deadlines. You need to
determine whether the deadlines are mandatory or
desirable.

The feasibility study of software

development at hand is:

Economic feasibility - The client company’s rigidity

in adjusting with a few increments in budgets can
prove to be a major hurdle in the development of
efficient, portable and robust software.

Schedule feasibility - As per the current

requirements provided by the company 6 months seem to
be reasonable enough for the completion of the
project.
Technology feasibility - Due to the size limit, the
inclusion of a good GUI and other attractive add ons
would b difficult

Operational feasibility - As the data has been kept

in archives manually for past many years and needs to
be stored in the software database thus this makes
work easier but will take time for entering the data.

Legal feasibility - All the legal acts and protocol

are followed
 RISK ANALYSIS
1. RISK TABLE
Risks Category Probability Impact
Software doesn’t meet
PE 30% 1
performance requirements
Hardware doesn’t support
PE 30% 2
the required interface
The user doesn’t find it
PE 20% 2
up to his requirements.
CUT OFF LINE
Customer changes
SC 10% 4
requirements
Team member performance SC 30% 4
Scope estimate incorrect SC 100% 3

Impact values: Category values:

1 – Catastrophic PE – Performance Risk
2 – Critical CO – Cost Risk
3 – Marginal SU – Support Risk
4 – Negligible SC – Schedule Risk

Risk Descriptions

Software doesn’t meet performance requirements

Software developed doesn’t meet performance

requirements. This is a pretty generic risk, so we
will refine it at our discretion. Something like an
extremely jumpy screen will probably constitute a
trigger for the contingency plan.
Sub-condition 1: Real-time computing present issues
on allocating processing time.

Hardware doesn’t support the required interface

Hardware doesn’t support the required interface.

Sub-condition 1: With the reuse of the login
component, many new interfaces will have to be
implemented. Issues that relate to non conformance
of the design specification are cause for concern.
Sub-condition 2: The design standards for component
interfaces have not been solidified and may not
conform to certain existing reusable components.

Customer changes requirements

Client may request small changes outside the agreed

upon requirements. These may have a major impact on
our design and implementation.

Team member performance

We are relying on our team members to perform at

certain levels to complete this project. Team
members have an infinite number of possible
situations that may hinder their performance.

Probability and Impact

Software doesn’t meet requirements

The software not meeting the performance requirements
has a probability of 30%. This is a performance risk
and has an impact rated as 1 (Catastrophic).

Hardware doesn’t support required interface

If one of the engines interfaces doesn’t meet the

requirements, we have a manageable problem. However,
this is rated as critical to the project and has a
30% chance of occurring. This is also a performance
risk.

Customer changes requirements

In every project there is the risk of the customer

trying to change the requirements. This is both a
scheduling and cost risk. We gave this a 10% chance
of occurring and rated it as a negligible risk. This
is due to the fact that we have a strong argument for
not having to submit to the customer’s request if it
is not specified in the requirements document.

Team member performance

Team member performance is also a risk that every

project faces. We gave it a 10% chance that the
occurrence may arise and action must be taken. This
is however a negligible risk and can be corrected
easily.

Risk refinement

High probability/high impact risks are refined

Risk mitigation, monitoring, and
management

Risk mitigation/monitoring

Software doesn’t meet performance requirements

Ensuring milestones are met and taking action if they

are not will be essential to the success of this
project. Establish and enforce formal technical
review guidelines after the completion of a major
component of the project. If the component cannot be
completed due to inability to meet requirements via
coding, a group meeting needs to occur where we
either reevaluate the design of the project or
reassign team member responsibilities.

Hardware doesn’t support required interface

Strong emphasis will be placed on strictly adhering

to the design specification. Being that the engine
component is already designed and we have little
knowledge of the internal workings, well defined
interfaces are a must. We don’t have the choice of
redesigning the entire API when a problem arises.
Individual unit tests with stubs/drivers will reveal
more information about the interfaces and their
correctness.
Client requirements change

We are going to attempt to avoid a requirements

change all together, but under these circumstances
(students working for a Professor) it may arise. We
can attempt this by writing a strict requirement
specification and ensuring that both client and our
team have the same perspective on the project
outcome.

Team member performance

Mitigation of team member performance slippage will

be handled with caffeine. Ensuring that we have an
assortment of caffeine sources will be essential to
this projects success. Dark brewed roast from
dunking' doughnuts is preferred. In certain regards,
there is nothing that can be done to mitigate this
risk. If a group member is sick, for instance, there
is nothing we can do to combat that happening. We
can monitor other situations however, such as a group
member dropping out because of workload. We can
monitor group members through group meetings, and try
to ensure that everyone knows what they are doing,
and is comfortable doing it.

Risk management

Software doesn’t meet performance standards

Obviously, this is a heavy responsibility on the
team. If requirements are not met, it could greatly
affect the quality of the project. If the
requirements are not being met correctly, or at all,
then the contingency plan is to either discuss with
our customer what changes need to be made, or choose
a new project if there is no way we can complete the
project. The trigger to this risk being active is
that we have fallen far behind schedule in one aspect
and the completion of the project is in jeopardy.

Hardware doesn’t support required interface

In the event an interface is designed incorrectly, we

can only attempt to resolve the issue with a
conversion algorithm that corrects the issue. In the
case that the interface is tightly coupled with other
interfaces, we will have no choice but to take the
project back to the design phase. Analysis must then
be done on the impact of the proposed changes. The
trigger here is obvious, that being an incorrectly
defined interface found.

Client requirements change

If the occurrence of a change in requirement does

arise after the formal sign off, we will simply
consider the impact of the request. If the impact of
the change is minimal and the schedule allows for it,
we will attempt to incorporate the requested change.
The trigger here is quite obvious, that being the
change request.

Team member performance

As mentioned above, there is not much we can do in

this regard other than making sure that all group
members are kept relatively happy. If this risk does
occur, then our contingency plan is to assign other
group members additional tasks. Someone might have
to become an additional programmer or tester, for
instance. Luckily, this will probably not occur and
would not have a catastrophic impact regardless. The
trigger to this risk occurring would be notification
by the group member that they will no longer be
working on the project.

STATE TRANSITION DIAGRAM

 Student selected.
Generate unique id Unique
New Student identification
no.

new accom.

Check room list

Canteen/mess demands

Room List Things provided

Room available Add to the

Modify room list
bill cart