Case Study_Dotnet Stream

8/8/2019 Case Study_Dotnet Stream

http://slidepdf.com/reader/full/case-studydotnet-stream 1/54

ICT Academy of Tamil NaduELCOT Complex, 2-7 Developed Plots, Industrial Estate, Perungudi, Chennai 600 096.

Website : www.ictact.in , Email : [email protected] , Phone : 044 4290 6800 , Fax : 044 4290 6820



Table of Contents

1. Bill Payments System ................................................................................................................1

2. Bill Payments System - Specifications ......................................................................................3

3. Customer Relationship Management..................................................................................... 20

4. Customer Relationship Management - Specifications........................................................... 22

5. Reservation System for Friendly Hotel................................................................................... 34

6. Reservation System for Friendly Hotel - Specifications......................................................... 36

7. Training Management System ................................................................................................ 45

8. Training Management System - Specifications ...................................................................... 46



Case Study

1

Project - 1

Bill Payments System

ABC bank (Bank) is a regional bank and has been in existence in southern states of India since

1965. So far Bank has been providing standard banking services to its almost captive customers

who have been with the bank for several decades. Bank has been able to retain these

customers primarily because of their personalized and timely services. For all these years, ABC

bank made minimal investments in its technology platform and various systems. As a result,

ABC bank has not been able to offer value added financial services and responsiveness to its

customers. Because of the changing banking environment and competition from larger financial

institutions, ABC bank has started losing its customers and its profitability is continuously

decreasing. In the last board meeting, directors assessed the situation. Board felt that bank has

a critical mass of the loyal customers and should the bank be able to provide contemporary

services combined with its passion for customer services, it will not only be able to retain its

customers, but it will also be able to grow profitably. Board resolved that Bank must undertake

an initiative to transform its technology as well as systems, launch new products and services.

Board also mandated that Bank must build its new systems based on latest technology platform

that matches its profile. Board recommended adoption of technology and standards that allow

bank to manage the future changes quickly and efficiently to stay ahead of the competition.

As part of this initiative, Bank has decided to deploy several new systems: Online bill payment

is one such new system.

The key objectives of the System are

o Allow customers to set up and pay bills in a simple and fast manner

o Ability to set up single payments in advance or schedule automatic payments at

predefined frequencies

o Ability to receive bills electronically from a growing list of vendors (future enhancement)



Case Study

2

o Attract new customers by offering the service free of cost

o Allow categorization of bills and provide query and reporting capability to customer for

tracking category-wise spendSystem Requirements

1. Customers can sign up for Bill Payer by filling up the online application form. Once the

application is submitted, customer can start using Bill Payer right away.

2. Customers can add billers to the service by entering information from their current

billing statement sent by the biller. Bill Payer allows set up of payments in advance as

well as set up of automatic payments. Currently, automatic payment can be set up for

monthly payments only.

3. The payment can be set up using the Pay Bills function. The customer enters the

amount and selects the biller to be paid. The dynamic calendar shows the earliest date

the payment is expected to arrive. The payment can be scheduled to arrive any time

later by entering a due date up to 12 months in the future by manually typing in a date

or choosing a pay date from the dynamic calendar.

4. Categories will be assigned to each biller based on common industry categories, such as

"Mortgage", " Utilities", or "Telephone". Members can query payment history for a

category and period.

5. Members who have more than one account set up in their Bill Payer account will be

prompted to select their "Preferred Account". Members will be prompted to select their

"Preferred Account" while signing up and when selecting a funding account during

payment set up.

6. Customer can make changes to the payment amount, payment date, and withdrawal

account of payments which are in pending status

7. Every day, Customer service manager checks the payments due on that date for all

accounts and approves the payments where sufficient balance is available. A check is

generated and mailed to the biller’s address. In case the balance is not sufficient, the

transaction is rejected and the customer is informed.



Case Study

3

Bill Payments System - Specifications

Screen Design

1. Welcome Screen

This is the initial screen displayed when the system is launched.

Welcome to Online Bill Payment System

Processing

a) When clicked on the hyperlink, launch the login screen.

Click here to Login



Case Study

4

2. Login Section

The user is already a customer of the bank and has the Username and Password issued by the

bank. These need to be validated before providing access to the Bill Payment modules.

The Customer Service Manager of the bank will login with a user id of “Admin”.

Login

Username

Password

Validations

a) Validate the Username and Password against the Customer table.

b) For Bank’s Customer Service officer, the user name will be “Admin”.

Processing

a) If the username = “Admin” and the password is valid

Direct the user to “Bill Payment Menu” screen

b) If the Username and Password combination is valid,

• If the customer is not registered for the Bill Payment function

Direct the user to “Bill Payment Registration” screen

• If the customer is already registered for the Bill Payment functionDirect the user to “Bill Payment Menu” screen

c) If “Clear” is clicked, Refresh the values in Username and Password fields.

d) If “Cancel” is clicked, return to the Welcome screen.

Submit Clear

*

*

Cancel



Case Study

5

3. Bill Payment Registration

Existing bank customers can register for bill payment facility. The customer name is retrieved from the

database using the login username. A customer can select two preferred accounts for funding the bill

payment

Bill Payment Registration

Customer Name : Venkatesan K

Preferred Account 1 [DROPDOWN]

Preferred Account 2 [DROPDOWN]

Terms and Conditions

I hereby declare that I have read the terms and conditions completely as mentioned in the

Bill Payment Agreement and I unconditionally agree to abide by these terms and conditions.

Validations

a) Preferred Account 1 and Preferred Account 2 should not be the same.

b) Preferred Account 2 should not be entered if Preferred Account 1 is not entered.

Processing

a) Display Customer’s accounts (only of Savings and Checking type) in the Preferred Account

fields.

b) If the user clicks on “I Agree”• Update the Bill_Pay_Registered to “Y” in the Customer table for the customer’s ID

• Update the Bill_Pay_Preferred to “Y” in the Account table for the preferred accounts

selected on the screen

• Display the “Activation” screen

c) If “Cancel” is clicked, return to the Login screen.

I Agree Cancel*



Case Study

6

4. Activation screen

Processing

a) If “OK” is clicked, direct the user to “Bill Payment Menu” screen.

Bill Payment System Activated Successfully

Now You can Access This Facility

OK



Case Study

7

5. Bill Payment Menu

Bill Payment Menu

Processing

a) “Maintain Categories” and “Approve Payments” should be visible only to Admin users

b) Based on the option selected, direct the user to respective page

c) If Logoff is selected, return to the Welcome page.

Manage Billers

Manage Payments

View Payment History

Maintain Categories

Approve Payments

Logoff



Case Study

8

6. Manage Billers

This screen allows the user to add new billers and modify or delete existing billers.

Validations

a) For Update, one of the billers displayed on the screen should be selected

Processing

a) All the billers defined by the customer are loaded into the screen when it is displayed.

b) If “Add” is clicked, display the “Add New Biller” page

c) If “Update” is selected, display the “Update Biller” page

d) If “Back” is selected, display the “Bill Payment Menu”

Select Biller Name Address Category

List of Billers

BackUpdateAdd



Case Study

9

7. Add a New Biller

This screen is used to add a new biller.

Add a New Biller

Biller Name

Address

City

Pin Code

Category [DROPDOWN]

Processing

a) If “Submit” is clicked

• Generate a unique ID for biller

• Store Biller details in the Biller Table

• Return to “List of Billers” screen

b) If “Back” is selected, display the “List of Billers”

Submit Back

*

*

*

*

*



Case Study

10

8. Modify Biller

This screen is used to modify the details of an existing biller.

Modify Biller Information

Biller Name

Address [TEXTBOX]

City [TEXTBOX]

Pin Code [TEXTBOX]

Category [DROPDOWN]

Status Active Inactive [RADIO BUTTON]

Validations

a) If status is changed from Active to Inactive• Check if there are any outstanding payments for the biller in the Payment_Instr table. If

Yes, give an error message

Processing

a) If “Update” is selected, modify the Biller details in the Biller table. Return to “List of Billers”

screen

b) If “Back” is selected, display the “List of Billers” screen

Update Back

*

*

*

*

*



Case Study

11

9. Manage Payments

Add Payment

AC No x,xx,xxx.xx

Biller Name

Bill Amount [TEXTBOX]

Payment Due Date [TEXTBOX && DATE PICKER]

Repeat Payment Monthly? Yes No

Biller Date Amount Repeat?

Add Payment Modify Payment Delete Payment

Submit

SUB MENUS

Cancel

*

*

*

*

*



Case Study

13

10. View Payment History

This screen allows the customer to view the history of payments made during a selected period.

View Payment History

Category

From To

Date AC No Biller Amount Category

Validations

a) To-date should not be less than From-date

Processing

a) If category is not entered, assume all categories.

b)

From-date should be pre-filled with the first day of current month. To-date should be pre-filledwith today’s date.

c) When Search is clicked,

• Search the Payment table for the given category, date range and the list of accounts owned

by the customer

d) When Cancel is clicked

• Return to the Bill Payment menu

Search Cancel



Case Study

14

Admin Section

11. Approve Payments

This screen is used by the Customer Service Manager of the Bank to approve or reject payments

to be processed each day.

Approve Payments

Date Account Name Biller Payment

Amount

Account

Balance

Approve

Yes

No

Yes

No

Processing

a) From the payment_Instr table, load all the payment instructions which have a payment date <

or = today’s date

b) When Submit is clicked, do the following processing for each payment instruction

• If Approve = “Yes”,

i. Subtract the bill amount from account balance and update the account

recod

ii. create a record in payment table

iii. If recurring_payment = “No”, delete the payment_instr record

iv. If recurring_payment = “Yes”, update the last processed date to today’s

date and update the Payment_Due_Date by 1 month

• If Approve = “No”,

i. Generate an email message to customer

ii. Delete payment_instr record

• Refresh the list

c) If Cancel is pressed, direct the user to Bill Payment Menu page.

Submit Cancel



Case Study

15

12. Maintain Categories

Maintain Categories

Select Category Code Description

Telecom Tele Communication

Utility Water Tax

Category Name [TEXTBOX]

Description [TEXTBOX]

Add Category Modify Category

Submit Cancel

SUB MENUS



Case Study

16

a) Add Category

Validations

• Category code should not be already existing in Category table

Processing

• Store the Category details in Category table

b) Modify Category

Validations

• One of the existing categories should be selected.

Processing

• Display the selected category details.

• Update the category details in Category table



Case Study

17

Database Design

Table Name Account

Field Name Field Type

Acct_no Integer primary key

Customer_Id Integer Foreign Key referring to

Customer

Ac_type Integer 1 – Savings

2 – Current

3 – FD

4 - Loan

Account_Balance Decimal

Bill_Pay_Preferred Char Y – Yes

Blank - No

Table Name Customer


Customer_Id Integer Primary Key

Customer_Name Varchar(45)

username Varchar(45)

password varchar(10)

Bill_Pay_Registered Char Y – Yes, Blank - No



Case Study

18

Table Name Biller info


Biller_id Integer(auto increment) primary key

Customer_Id Integer Foreign key referencing

Customer table

Biller Name Varchar(45)

address varchar(10)

City Varchar(40)

Pin Varchar(10)

Category_Code Integer Foreign key referencing

Category table

Status Integer 1 – Active

2 - Inactive

Table Name Payment_Instr


Payment_Instr_No integer Primary key; auto generated

Ac_no Integer Foreign key referencing

Account

Biller_Id Integer Foreign key referencing Biller

Payment_Due_Date Date

Amount Decimal

Recurring_Instr Integer 1 – Yes

0 – No

Last_Processed_Date Date



Case Study

19

Table Name Payment


Payment_No integer Primary key; auto generated

Ac_no Integer Foreign key referencing

Account table

Biller_Id Integer Foreign key referencing Biller

table

Payment_Date Date

Amount Decimal

Category_Code Integer Foreign key referencing

Category tale

Table Name Category


Category_Code Integer Primary Key

Category_Desc Varchar(20)



Case Study

20

Project - 2

Customer Relationship Management

Customer relationship management (CRM) is a term applied to processes implemented by a

company to handle its customer interactions in an organized and efficient manner. The

customers can include current customers as well as prospective customers. The objective of a

CRM application is to improve customer experience with the organization and to promote

efficiency in marketing, sales and service functions of the organization.

A CRM system can be used by employees from different departments, such as sales, marketing,

customer service and training. Various communication channels (telephone, web, personal visit

etc) may be used by customers to interact with these departments. A CRM system provides an

integrated view of the customer and all his/her interactions with the company across various

communication channels.

“Customer Relationship Management is not just about how a company communicates with its

customers through advertising, direct marketing and customer services. It is a much broader commitment to organize a company around its customers in order to anticipate individual needs

whilst providing the organizational structure to deliver on the marketing promise.”

Charles Turner

CRM Management Pocketbook

This project is for a reputed manufacturing company that supplies UPSs (Uninterrupted Power

Supply Machines) and Inverters for both home and office use. The company already has an

integrated system for Order processing, Manufacturing and Accounting. The complete detailsabout customers and their transactions are maintained in the database.

The company is planning to build a centralized contact center where all new orders, service

requests, queries and complaints are received and processed. Customers can reach the contact

center using either a toll-free number, email or fax. The calls are either processed while the



Case Study

22

Customer Relationship Management - Specifications

Screen Design

1. Welcome Screen

This is the initial screen displayed when the application is launched by the customer service

representative (CSR).

Processing

a) Based on the link selected, navigate to the respective screen.

Welcome!

Queries

Company Outlets

Product Features

Product Pricing

Complaints

Query Complaint Status

Register Complaint



Case Study

23

2. Query Product Features

This screen is used by the CSR to answer queries regarding product features, base price of the product,

warranty period and product launch date.

Processing

a) The product field should be populated with all product names, from which the user can select

one product.

b) When Submit is clicked, features for the selected product are displayed.

c) If Clear button is clicked, clear all the fields and remain in same page.

d) If Back is clicked, return to the Welcome screen.

Query Product Features

Product

Features

Base Price

Warranty

Launch date

Clear Back

*

Years Months

Dropdown

Submit



Case Study

24

3. Query Company Outlets

When a customer calls for details on the company’s sales and service outlets, this screen is used.

Processing

a)

The city field should provide a list of all cities where the company has either a sales or a serviceoutlet.

b) If outlet type is selected, the list will be filtered to the selected type. Otherwise, all outlets are

displayed.

c) If Back is clicked,

• Return to the Welcome screen

Query Company Outlets HomePage

Back

City :

Outlet Type :

Dropdown

Sales Service

*

Submit



Case Study

25

4. Pricing Screen

This screen is used to calculate the price of a product. Base price is the cost of UPS or Inverter made by

the company. Additionally, the customer can purchase the following with the product –

a. Battery

b. Service at customer premises. This is charged as a percentage of the product cost + battery

cost

c. Additional warranty (beyond the normal product warranty). This is charged as a % of

product cost + battery cost.

Validations

a) Years of additional warranty should be between 0 and 2 years

Processing


one product.

Product Pricing

Product

Service location

Additional

Dropdown

Submit

Homepage

Back

*

*

At client place

Base Price

(0 to 2 years)

Battery

At service center

Final Price

*

Clear

Required



Case Study

26

b) When Submit is clicked

• Validate the data

• Get the Base price and Battery cost from the product table

• If service location is client place, calculate the additional % to be charged. There is no

additional cost for servicing at company’s service center.

• If additional warranty (in addition to the normal product warranty) is required,

calculate the additional cost.

• Display the final price

c) If Clear is clicked

• Clear all the fields on the screen.

d) If Back is clicked,




Case Study

27

5. Register Complaint

This is used by CSR to register customer complaints. A complaint number is generated and given to the

customer for future follow-up.

Register Complaint

Customer Name

Contact Phone #

Product

Complaint

Description

Complaint

type

Submit

Homepage

Back

*

*

*

*

*

Drop down

Drop down

Clear



Case Study

28

Validations

a) Phone number should be numeric

Processing


one product.

b) Complaint type can be any of the following

• 1 - Equipment malfunction

• 2 - Price charged is too high

• 3 - Service not rendered in time

• 4 - Service center not responsive

• 5 - Others

c)

When Submit is clicked• Validate the data

• Generate Complaint number

• Store the details in Complaints table with

o Status = “Registered”

o Status Update Date = System date

o Complaint date = System date

• Display the confirmation screen

d) If Clear is clicked

• Clear all the fields on the screen.

e) If Back is clicked,




Case Study

29

6. Confirmation screen

This is the confirmation screen that the complaint has been registered.

Processing

a) Display the complaint number generated in the Register Complaint screen.

b) Compute the expected resolution date as complaint date + 2 weeks.

c) If OK is clicked

• Go to Register Complaint Screen

d) If Back is clicked,


Confirmation

Ok

Homepage

Back

The complaint has been registered.

The complaint number is



Case Study

30

7. Enquire Complaint Status

CSR uses this screen to answer customer queries on the status of their complaints.

Processing

a) If Submit is clicked

• Based on the complaint date, retrieve the complaint details from complaint table

• Using the product code in the complaint record, get the product name from

product table

b) If Clear is clicked

• Clear all fields on the screen

c)

If Back is clicked,• Return to the Welcome screen

Query Complaint Status

Complaint Number

Product Name

Complaint

Current Status

As of

Clear Back

*

Submit



Case Study

31

Tables

Table Name Product


Product_code char(10) primary key

Product_Name char(30)

Base_Price Integer(6)

Warranty_months Integer(2)

Launch_date Date

Battery_Price Integer(6)

Svc_at_Client_Place Integer(2)

Addl_warranty_peryear Integer(2)

Table Name Product_Feature

Product_Code Char(10) primary key; foreign key to

Product table

Feature_No Integer(20) primary key

Feature_Desc char(20)



Case Study

32

Table Name Outlet

Outlet_number Integer Autogenerated

Outlet_type Integer(2) 1 – Sales

2 - Service

Address1 char(50)

Address2 char(50)

City char(20)

Pincode Integer(6)

Contact_Number Integer(10)



Case Study

33

Table Name Complaint

Complaint_Number Integer(5) Primary Key; autogenerated

Customer_Name char(40)


Product_code Char(10) Foreign key of Product table

Complaint_details Varchar(200)

Complaint_type Integer(2) 1 - Equipment malfunction

2 - Price charged is too high

3 - Service not rendered in

time

4 - Service center not

responsive

5 - Others

Complaint_date Date

Complaint_status Char(20)

Status_date Date



Case Study

34

Project 3

Reservation System for Friendly Hotel

Friendly Hotel was built about 100 years ago by the great, great grandfather of the current

owner. It has 100 rooms of three types: Bridal Suite, Double and Single.

The hotel has grown to be a popular destination among tourists and the revenues have

increased steadily. The hotel has added several new services such as Beauty Parlour, Library

and 24 hour Coffee shop, to meet the growing needs and expectations of the clients. However,

the reservations and billing processes continue to be predominantly manual. This has

sometimes caused overbooking or double booking of rooms, forcing the hotel management to

accommodate some guests in nearby hotels. Also, the manual billing process has resulted in

loss of revenue in some cases, as some of the services utilized by guests are not reported to the

front-desk by the time guests checked out of the hotel. A system analyst studied the current

system and did some analysis for the development of an automated reservation and billing

system for Friendly Hotel. In what follows, the study and analysis results are summarised.

Room prices vary according to season. Currently two seasons are recognised: 'Low', from the

20th of September to the 20th of May and 'High', from the 21st of May to the 19th of

September. Prices for each room type per season are updated every year.

Customers, some of whom belong to companies, book rooms throughout the year. Each

booking is for one room. A name of a customer is always required when a booking is made.

Bookings are either confirmed at the time of booking or are provisional. A provisional booking

has to be confirmed within three weeks and at least 2 days prior to arrival. Otherwise, the

booking lapses, and is deleted from the system. For preferred customers, a discount is offered

depending on their historical patronage. The discount percentage is updated once a year by

the marketing department.

Upon arrival, customers who propose to pay their bill by credit card have to inform the hotel byproviding the relevant credit card number. Friendly accepts three methods of payment: cash,

cheque and credit card. Cheque and credit cards are credit checked while customers are shown

to their room. If the credit check shows the card to be unacceptable, Friendly staff inform the

customer and request another card or another method of payment. Until the new method of

payment is acceptable, the customer cannot use the hotel's services without paying in cash.



Case Study

35

During their stay, guests can use the hotel's services, which are: Bar, Restaurant, Laundry,

Coffee Shop, Room Service and Beauty Parlour. These services are either paid for directly or

charged to the room number of the guest. The total of each service used is recorded in the

system.

When a booking is taken, whether provisional or confirmed, a booking number is allocated, a

customer number and/or a company code number are attached to the booking, and the

expected start and end dates are recorded.

Friendly has 50 companies and 300 customers on record. Each room has an average of 30

bookings per year. When at Friendly, guests use the hotel's services 10 times on average.

Corporate bookings should involve information about corporate events like conference,

entertainment or accommodation

Scope of this project is to process telephonic room bookings. For the purpose of this project,

the following assumptions can be made

- There is only one room per booking.

- The hotel has enough number of rooms to satisfy all bookings



Case Study

36

Reservation System for Friendly Hotel - Specifications

Screen Design

1. Welcome Screen

This is the initial displayed when the application is launched by the hotel staff making reservations.

Processing

a) If “New Customer” is clicked, navigate to “New Customer Registration” screen

b) If “Existing Customer” is clicked, navigate to “Existing Customer – Search” screen

Welcome!

New Customer

Existing Customer



Case Study

37

2. New Customer Registration

This screen is used to capture details of new customers.

Validations

a) First Name should be at least 2 characters long.

b) Last name should be at least 2 characters long.

c) Date of Birth should be in the format DD/MM/YYYY. Date of Birth should be less than today’s

Date.

d) After entering DOB calculate the age. If the age is below 18 years give an error message

e) Pin code should be numeric and should consist of 6 digits.

f) Contact number should be numeric.

g) Check in the Customer_Details table if there is already a record with the same Last Name andContact Number. If yes, give an error message.

Processing

a) When Submit is clicked, generate customer number and insert the values in Customer_Details

Table and display the Reservation page.

b) If Clear button is clicked, clear all the fields and remain in same page.

c) If Back is clicked, return to the Welcome screen.

Registration

First Name:

Last Name:

Date Of Birth:

Address1:

Address2:

City:

Pin code:

Contact Number:

Submit Clear Back

*

*

*

*

*

*

*



Case Study

38

3. Existing Customer – Search screen

This screen is used to search existing customers by last name or contact number.

Validations

a) Either Last Name or Contact Number should be entered. If both are entered, Last name takes

precedence over Contact Number.

Processing

a) When Search is clicked,

If Last Name is entered

• Search Customer_Details table for customers with matching last name

Else

• Select Customer_Details table for customers with matching contact number

Endif

Pass the search results to Customer details screen

b) When Back is clicked,


Existing Customer

Last Name:

Contact Number:

SearchBack



Case Study

39

4. Customer details Screen

This screen displays details of customers matching the search criteria. A maximum of 6 entries aredisplayed.

Select Customer Number Name Address Contact Number

Validations

a) If OK is clicked,

• A customer should have been selected

b) If Back is clicked,

• Return to the Search screen

c) If HomePage is clicked,


Customer Details

Ok

HomePage

Back



Case Study

40

5. Reservation Screen

This screen is used by the hotel reservation staff to make room reservations. Reservations can be madeonly for customers who are already registered in the system. For the purpose of this project, system will

not check

Reservation

Customer name: Customer number

Room Type:

Booking Type:

From Date:

To Date:

Number of

people:

Dropdown

Confirmed

Ok

Homepage

Back

*

*

*

*

*

Provisional

DD/MM/YY

DD/MM/YY



Case Study

42

6. Confirmation screen

This screen shows confirmation details of reservation.

Processing

a) If OK is clicked

• Go to Welcome Screen

b) If HomePage is clicked,


Confirmation

Customer Name:

Room Type:

Booking Type:

From date:

To date:

Number of

people:

Rate:

Homepage

OK

Confirmation #



Case Study

43

Tables

Table Name Customer_Details


Customer_Number char(10) primary key

Fname char(20)

Lname char(20)

DOB Date

Address1 char(50)

Address2 char(50)

City char(20)

Pincode Integer(6)


Table Name Room_Type

Room_Type_Id Integer(auto increment) primary key

Room_Type_Name char(20)

Table Name Rate

Season char(10)

From_Date Date

To_Date Date

Room_Rate Integer(7)



Case Study

44

Table Name Reservation

Resrvation_Number Integer(5) Primary Key

Customer_Number char(10) foreign key referring to

customer_details table

Room_Type_Id Integer foreign key referring to

room_type table

Booking_Type Char(1) 1 – Provisional

2 - Confirmed

From_Date Date

To_Date Date

Number_Of_People Integer(1)

Rate Integer(7)



Case Study

45

Project 4

Training Management System

The purpose of this project is to build a tool that automates all the activities related to organizing and

managing training programs within an organization. The system accepts the training requests,

nomination of employees to attend training, approval of nomination and tracks the training to

completion, using a built-in work-flow process. The following functionalities are supported in the

system

• Request training - This is typically done by the project manager. The request can also come from HR

based on the training needs analysis conducted during the appraisal process.

• Announce training programs - The training department consolidates the training requests and

schedules programs that are in good demand. The program details (Course name, dates, duration,

trainer background, venue etc.) are announced to all the employees through the company’s intranet

portal and email.

• Receive nominations - Project managers nominate their team members to attend training.

• Approve or reject nominations - Based on the response and availability of seats, the training

department may approve or reject certain nominations. The nominated employee and his/her

manager are informed regarding the confirmation or rejection of nomination. Reminder mails are

sent one day prior to the start of the program.

• Capture attendance - This is done by the training department during the course of training.

• Collect Feedback – At the end of training, participant feedback is taken on various aspects of the

program including program relevance, trainer effectiveness, quality of training material,

infrastructure etc.

• Track employees training hours – The number of hours spent by the employee in attending training

is used by HR and the management to track the career development of employees.



Case Study

46

Training Management System - Specifications

Screen Design

1. Welcome Screen

This is the initial screen displayed when the system is launched.

Processing

a)

Based on the option selected, launch the corresponding screen.

Welcome!

Request Training

Review training requests

Schedule Training

Submit Nominations



Case Study

47

2. Request Training

This screen is used by the managers to request training on specific topics for their team members.

Validations

a) If Needed by date is entered, it should be a valid date and should not be a past date.

b) Priority should be between 1 and 5.

Processing

a) Generate Training Request Number.

b) Create a record in the Training_Request table with the data entered on the screen. Use

today’s date as training request date. Set the status to “Requested”.

Request Training

Confirm Back

Training Topic

Needed by date

Requested by*

No. of Participants

*

Dropdown*

DD/MM/YY

Priority*

1 – Low, 5 - High

Refresh



Case Study

48

3. Review Training Requests

This screen is used by the training department to review the training requests received. If the sametraining is requested by multiple managers, the number of participants are totaled and the average

priority is computed.

Validations

a) If Schedule is clicked, the training program should have been selected.

Processing

a) Select the training requests which have a status of “Requested” and group them by training

topic. Sum up the number of participants and find the average priority. Display the top 5 (by

priority) training topics.

b) When Schedule is clicked,

• Pass the training topic id to Schedule Training screen

c) When Back is clicked,


Select Training Topic Total Participants Average Priority

Review Training Requests

Schedule Back



Case Study

49

4. Schedule Training

This screen is used to schedule the training for the topic selected in the previous screen.

Validations

a) Schedule from should be a valid date and should not be a past date.

b)

Schedule to should be a valid date should not be earlier than schedule from date.Processing

a) Based on the training topic selected in the previous screen, display the training topic name.

b) When Confirm is clicked,

• Create a record in Training_Schedule table with Topic id, schedule from date,

schedule to date, trainer name and venue.

• Update the status column in Training_Request records for the given topic with a

value of “Scheduled”. Note that only those records which have a status of

“Requested” should be updated. The table may contain records with other statuses

for the same training topic.

• Return to the Review Training Requests screen.

c) When Refresh is clicked,Data is retrieved from the database and repopulated into the screen

d) When Back is clicked,

• Return to the Review Training Requests screen.

e) When Home is clicked,

• Return to the Welcome screen.

Schedule Training

Confirm Refresh Back

Training Topic

Schedule from

Trainer

Schedule to

DD/MM/YY

DD/MM/YY

Venue

*

*

*

*

Home



Case Study

50

5. Submit Nominations

This screen is used by project managers to submit nominations for the training programs which arealready scheduled.

Processing

a) Training topic field should show the list of topics from Training_Schedule table

b) When Retrieve is clicked,

• Get the training details from Training_Schedule table

c) When Confirm is clicked,

• Create a record in Nomination table

• Clear the screen

d) When Back is clicked,


Submit Nomina*

Confirm Back

Training Topic

Scheduled from

Trainer

to

Venue

*

*Name of person

nominated

Retrieve

Nominations received



Case Study

51

Tables

Table

Name

Training_Request


Training_Req_No Integer (auto increment) primary key

Topic_Id Char(10) Foreign key referring to

Training_Topic table

Participant_Count Integer

Priority Integer

Requestor Char(40)

Needed_By_Date Date

Request_Date Date

Status Char(20)

Table Name Training_Topic

Topic_Id Char(10) primary key

Topic_Desc Char(40)



Case Study

Table Name Training_Schedule

Schedule_No Integer (autoincrement) Primary Key

Topic_Id Char(10) Foreign key referring to

Training_Topic table

Scheduled_from Date

Scheduled_to Date

Trainer_name Char(40)

Venue Char(40)

Status Char(20)

Table Name Nomination

Nomination_No Integer (autoincrement) Primary Key

Schedule_No Integer foreign key referring to

Training_Schedule table

Nomination_name Char(40)

Case Study_Dotnet Stream

Documents

Transcript of Case Study_Dotnet Stream