Download Anna University B.Tech (Bachelor of Technology) CSE (Computer Science And Engineering) 5th Sem CS6511 Case Tools CT Lab Manual Question Paper.
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
52 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PLACE ORDER AND BILLING:
Entered into the
order form
Place order
Validate
Billing
performed
Invalid item
Application
is closed
[invalid]
[valid]
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
52 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PLACE ORDER AND BILLING:
Entered into the
order form
Place order
Validate
Billing
performed
Invalid item
Application
is closed
[invalid]
[valid]
53 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.STATE CHART DIAGRAM: RECUIRTMENT SYSTEMS
Provide
user_id
Registration
Attend Test
Display
Result
Interview
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
52 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PLACE ORDER AND BILLING:
Entered into the
order form
Place order
Validate
Billing
performed
Invalid item
Application
is closed
[invalid]
[valid]
53 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.STATE CHART DIAGRAM: RECUIRTMENT SYSTEMS
Provide
user_id
Registration
Attend Test
Display
Result
Interview
54 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.STATE CHART DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
ADMIN
issuing
cancelled
delivered
withdrawal
check
balance
deduction
Payment
update
an info is not available
all info available
sufficient amount
low balance
do/initiate
delivery
do/check
details
do/initiate
withdraw
do/
checking
payment of
the credit
do/ from the
account
do/balance
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
52 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PLACE ORDER AND BILLING:
Entered into the
order form
Place order
Validate
Billing
performed
Invalid item
Application
is closed
[invalid]
[valid]
53 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.STATE CHART DIAGRAM: RECUIRTMENT SYSTEMS
Provide
user_id
Registration
Attend Test
Display
Result
Interview
54 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.STATE CHART DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
ADMIN
issuing
cancelled
delivered
withdrawal
check
balance
deduction
Payment
update
an info is not available
all info available
sufficient amount
low balance
do/initiate
delivery
do/check
details
do/initiate
withdraw
do/
checking
payment of
the credit
do/ from the
account
do/balance
55 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.ACTIVITY DIAGRAM: PASSPORT AUTOMATION SYSTEMS
Collect Status
from Applicant
Status Enquiry:
Check Status
Send new form
Send renewal
form
Old Applicant New Applicant
submit detail
Store to Database
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<
<
<
Admin
Update
order
Cancel
order
Crediting
details
Pay back
details
Make
order
28 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 3 IDENTIFY THE CONCEPTUAL CLASSES AND DEVELOP A DOMAIN
MODEL WITH UML CLASS DIAGRAM
1.CLASS DIAGRAM : PASSPORT AUTOMATION SYSTEMS
29 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
30 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. CLASS DIAGRAM:Online Book Banking Systems
ORDER BOOKS:
31 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
32 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.CLASS DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
33 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
34 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.CLASS DIAGRAM: STOCK MAINTENANCE SYSTEMS
Any user
(from Use Case View)
main form
user enters main form()
Stock form
displays stock details()
user views the details of the available stock()
error message
displays error msg()
invalid stock()
Stock controller
validate stock details()
refer from db() DB
(from Use Case View)
VIEW STOCK:
35 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.CLASS DIAGRAM: ONLINE RECRUITMENT SYSTEMS
36 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.CLASS DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
37 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 4 Using the identified scenarios, find the interaction between objects
and represent them using UML Sequence Diagram
1.UML SEQUENCE DIAGRAM : PASSPORT AUTOMATION SYSTEMS
:main form
:student
passport
:database :others
Student/others
for student passport
if response is
student
Verify and confirm
for others
if response is
others
:applicant
Request to open main form
Collect details
Response
request to enter student details
Store student details
successfully registered for students
Request to enter applicant details
store an applicant details
verify and confirm
successfully registered
APPLICANT:
38 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
SEQUENCE DIAGRAM:
:Administrator :New :Update :Status Enquiry
Check Status type
Response
Resquest
Send new form to Applicant
Request to renewal
Send renewal form to Applicant
Store to Database
Update the Status
New Update
STATUS ENQUIRY:
39 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.SEQUENCE DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
student data entry form book form database
controller
database confirmation
message
error message
request data
enter details
validate
enter book details
check availability
list of available books
get books
update
invalid
confirmation
error
40 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
41 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.SEQUENCE DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
42 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
EXAM DETAILS:
43 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.SEQUENCE DIAGRAM: STOCK MAINTENANCE SYSTEMS
:any user
:main form :stock form :stock
controller
:db :error msg
user enters into the main form
user enters into the stock form
validates the available stock
valid stock
displays items to the user
refer from db
invalid stock
error msg
VIEW STOCK:
44 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.SEQUENCE DIAGRAM: RECUIRTMENT SYSTEMS
45 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.SEQUENCE DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
46 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 5 Draw Relevant state chart and activity Diagrams
1. STATE CHART DIAGRAM: PASSPORT AUTOMATION SYSTEMS
47 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Send status to
administrator
Collect
response
Store to
database
Status Enquiry:
48 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.STATECHART DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter
details
enter book
details
check
availability
get books
validate
49 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PAYMENT MODE:
50 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.STATE CHART DIAGRAM: EXAM REGISTRATION SYSTEMS
REGISTRATION FORM:
EXAM DETAILS:
51 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4.STATE CHART DIAGRAM: STOCK MAINTENANCE SYSTEMS
Entered into
stock form
validation
Stock is
viewed
Error message is
displayed
Application
is closed
/check for validity
[valid] [invalid]
/cancelled /cancelled
VIEW STOCK:
52 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
PLACE ORDER AND BILLING:
Entered into the
order form
Place order
Validate
Billing
performed
Invalid item
Application
is closed
[invalid]
[valid]
53 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.STATE CHART DIAGRAM: RECUIRTMENT SYSTEMS
Provide
user_id
Registration
Attend Test
Display
Result
Interview
54 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.STATE CHART DIAGRAM: CREDIT CARD PROCESSING SYSTEMS
ADMIN
issuing
cancelled
delivered
withdrawal
check
balance
deduction
Payment
update
an info is not available
all info available
sufficient amount
low balance
do/initiate
delivery
do/check
details
do/initiate
withdraw
do/
checking
payment of
the credit
do/ from the
account
do/balance
55 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.ACTIVITY DIAGRAM: PASSPORT AUTOMATION SYSTEMS
Collect Status
from Applicant
Status Enquiry:
Check Status
Send new form
Send renewal
form
Old Applicant New Applicant
submit detail
Store to Database
56 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.ACTIVITY DIAGRAM: ONLINE BOOK BANKING SYSTEMS
ORDER BOOKS:
enter details
enter book
details
get books
validate
check
availability
display error
msg
from database
invalid
Store
details
available
unavailable
Order books
deny order
DB DB CONTROLLER STUDENT
FirstRanker.com - FirstRanker's Choice
1 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 ?CASE TOOLS LAB
Expt. No. 1 TO DEVELOP A PROBLEM STATEMENT
1. Passport Automation System
1. Problems Analysis and Project Planning for Passport Automation System
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport automation system
has been defined online passport automation process in their houses through internet .Therefore, the online
passport automation process can be done efficiently in advance and without much of delay. The use case
descriptions and other documents are described in such a way that the user understand it and finds it easy to
use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation system. This
system contains the details about the applicant, appointment date & time and the date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit the form in
the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport for submitting
the applicant details to the administrator and confirming it by the police. This system tries to use any kind of
interface as simple as possible and at the same time not risking the security of data stored in the database. The
system will retain information on the entire applicant who has necessary rights to apply for the passport. The
particular applicant should have a nationality.
If the entire process of ?Issue of Passport? is done in a manual manner then it would take several
months for the passport to reach its applicant. An automatic system is essential to meet the rising demand. For
security purpose, only the administrator is allowed to maintain the applicant details. The applicant details are
stored in a highly secured database, so that it cannot be illegally accessed. The online passport automation
database administrator maintains all the applicant and passport details. The administrator takes care of adding or
2 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
deleting the applicant details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system. Online passport
automation system enables us to save time, reduce the workload and process application. This system is efficient
in the way that there is no manual intervention. This system provides instant and accurate results for applying the
passport online. Finally, these systems aim at improving the efficiency in the issue of passport and reduce the
complexities involved in it to the maximum possible extent.
2. Problem Statement (Use case) Analysis:
2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:
2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the online passport
automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:
3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name, gender, age,
address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre-condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Status Enquiry:
3.2.1. Brief Description: This use case generates the process of applying and renewing the passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre-condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new passport or
renew the old passport.
3.3. Generate Unique Id:
3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2. Flow of events:
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and issue a unique
id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the applicant, the
administrator will not issue unique id.
3.3.3. Pre-condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of applicant.
3.4.2. Flow of events:
3.4.2.1. Basic Flow: Verification of passport is done by the admin and report is submitted to the police for
confirmation.
3.4.2.2. Alternate Flow: If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2. Flow of events:
4 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor?s details are not true.
3.5.3. Pre-condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
2. Book Banking System
1. Problems Analysis and Project Planning for Book Banking System
1.1. Introduction
This document deals with book banking system for students. This System has been designed for student
reference purpose such as borrowing books. It is an efficient way to improve the student?s academic activities.
Use case descriptions and other documents are described in such a way that the student understands it and finds
it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking system. This system
contains details about displaying the books, lending books, maintaining books, returning books, checking status,
paying dues and penalties, maintaining member details, etc.
1.3. Scope
This document for book banking system makes the students borrow books, through internet. The system
reduces power and enables the user to save his/her valuable times.
1.4. Problem Statement
Computers play an integral role in day to day life. Due to advancement in communication technology
internet came into existence. With the help of these two all the jobs are computerized now. So there is no
exception of book banking system is done to replace the manual entering and processing of information which
are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update the information.
The administrator keeps track of member details and book details. The system will have all the details about the
book and its availability. A database is maintained by the database administrator. The member should provide
their necessary information such as course, year etc., for registration purpose. Then the student has to login with
their name and id and proceed further. The student has options to select books, renew and return. A pupil is
allowed to take 3 books at a time. The student selects the book based on author name and edition that will be
displayed in the website. If the student delays to return or renew the book, then he/she must pay the penalty
amount at the time of returning the book.
5 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:
3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be prompted.
3.1.3. Pre-Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details
3.2.1. Brief Description: Students can check the availability of the books.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2. Book is added to student?s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre-Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member?s account.
6 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3. Order Books
3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error message will be
prompted.
3.3.3. Pre-Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode
3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2. Flow of Events:
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student?s account.
7 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3. Exam Registration System
1. Problem Analysis and Project Planning for Exam Registration System
1.1. Introduction
This software has been developed in such a way that any applicant can register themselves for their
exams. Once an administrator builds software for the concerned examination, any common applicant can use the
software for registering themselves in the examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also the other details
and register themselves for the desired examination provided all eligible criteria specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and ability. Also the
user can register him by going through the various details and particulars regarding the exam of his/her choice. If
the applicant is not eligible for a particular exam, the software provides an option by giving a list of other available
examinations.
1.4. Problem Statement
This system gives the access rights of the software to the administrator. The admin has a login form
which asks for a valid username and password. This username and password can be set as per the admin. The
administrator is given the top priority; hence he/she has a login into the software. Once, it has been logged in by
the preset username and password, the software is ready. Once, the software is ready, the admin creates a
database and enters the examination details required by the applicant. The details include the examinations
available for a particular field, fee structure for the exam and other particulars. The admin alone has the authority
to add, modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety of the various
options, examinations offered and various eligibility criteria. The applicant having got the full knowledge about the
various examinations conducted, he/she enters his/her pass percentage for registration of the particular
examination, and he/she desires to attend. The registration form includes the various fields like name, DOB,
address and other personal details. The eligibility criteria include fields such as year of passing, percentage of
marks and so on. If any empty value or any mismatch occurs then the error message is indicated.
8 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1. Identified Use cases
2.1.1 Login: It helps the students to login.
2.1.2. Registration Form: It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or not.
2.1.4. Exam Details: It tells the details regarding the exam.
2.1.5. Fee Processing: It describes the fee structure pertaining to the exam.
2.1.6. Confirmation: It helps the applicant to confirm whether he/she is valid to write the particular examination.
2.2. Identified Actors
2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration: This actor manages the details of applicant and exam.
2.2.4. Applicant: The person who wishes to write the exam.
2.2.5.ug: The one who register for their exam according to their UG syllabus.
2.2.6.pg: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward?s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it asks for a
username and password, which is present.
3.1.2. Flow of Events:
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password. The actor
enters the username and password and the system validates the entered name and password and logs the actor
into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it displays an error
message. The actor can choose either to return to the beginning of the basic flow or cancel the login at which it
ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or the state will
remain unchanged.
9 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2. Registration Form:
3.2.1. Brief Description: The applicant uses this use case for registration by going through the following flow of
events involved in the registration process.
3.2.2. Flow of Events:
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the following activities
takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is invalid an appropriate
error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria required for that
particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of the use case
otherwise they can register again.
3.3. Eligibility Criteria:
3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as pass percentage,
qualification, etc.
3.3.2. Flow of Events:
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can register for the
examination.
3.4. Exam Details:
3.4.1. Brief Description: This use case describes how the applicant views the various details of the examinations
available and selects the examinations of his choice.
10 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.4.2. Flow of Events:
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:
3.5.1. Brief Description: The applicant uses this use case for payment of fees through online payment.
3.5.2.Flow of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant?s regulation.
3.6.2. Flow of Events:
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation message.
4. Stock Maintenance system
1. Problem Analysis And Project Planning for Stock Maintenance system
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information about the stock
and retrieves the information. Here in our project the departmental store stocks are maintained and the profits are
computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance system. The
specifications and the use case model together describe the complete set of requirements on the system.
11 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of stocks. In our
software all the defects are removed and it is reliable, user friendly and very supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing maintenance system,
which is inefficient. The new stock maintenance system allows the stock maintainer to enter information about the
stocks available in the departmental sore and compute profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the information
about the items and proprietor to compute the profits. Stock maintainer can only access the information and
purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the records of price of
the different items, quantity and expiry date etc. The stock maintainer maintains the information of the sale of
items. The user can view the availability of all the items in the store along with the price and can?t make any
changes of it.
2.1. Problem Statement Analysis:
2.1.1. Identified Use Case: A specific way of using the system from a user?s perspective is called as a use case.
This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items available in the
stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user wants to place an
order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he wishes to
purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and modifying it from the
stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total sales with the
actual price and the maximum retail price.
2.2. Identified Actors:
2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of the payment and
the administrative reports.
12 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the data can be
retrieved.
3. Design Of Stock Maintenance System:
3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance system.
3.1.2. Flow Of Events:
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the login at which
point the use case ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If not the system
state is unchanged.
3.2. View Stock:
3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the items available in
the stock maintenance system.
3.2.2. Flow Of Events:
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:
1. If in the basic flow, the user enters an invalid item then the system displays an error message.
2. The user can either enter another item or return to the beginning of the basic flow.
3.2.4. Pre Condition: The user logs onto the system.
13 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.5. Post Condition: If the use case was successful the user views the available stock else the system state is
unchanged.
3.3. Place Order And Billing:
3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing details.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow:
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.3. Pre Condition: None
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the system state is
unchanged.
3.4. Purchase Stock:
3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to purchase stock from the
dealer.
3.4.2. Flow of Events:
3.4.2.1. Basic Flow:
1. This use case starts when the stock maintainer wishes to purchase any item from the dealer.
2. The stock maintainer gives the order according to the least quotation given by the dealer.
3.4.2.2. Alternate Flow:
If the stock maintainer is not satisfied with the quotation he can quit and can place order later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else the system is
unchanged.
14 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5. Stock Updation:
3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting and modifying the
items from the stock maintenance system.
3.5.2. Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and maintain the stock. This
includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to perform.
2. Once the stock maintainer provides the required information, one of the sub flows is executed.
1. If the stock maintainer selected add item, it is executed.
2. If the stock maintainer selected delete item, it is executed.
3. If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item. This includes
name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2. Alternate Flow:
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the specified id does
not exist, the system displays an error message. The stock maintainer can then enter a different number or
cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to delete the stock,
the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
15 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders else the system
is unchanged.
3.6. Profit Computation:
3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2. Flow Of Events:
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the actual price and
the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the database.
2The profit is computed with the above data.
3.6.2.2. Alternate Flow:
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system state is unchanged.
5. Online Recruitment System:
1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the FOUR
SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills concern vacancy
positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the result.
1.3. Scope
This is ?RECRUITMENT SYSTEM? software, which is used to conduct on-campus recruitment of a
software company. The advantage of this software is that one can easily attend the campus interview from their
16 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
college campus itself and it filter out the eligible members for the main interview. It saves time as well as provides
an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and interview for
the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers involved in the
recruitment should not hire employees that should start as soon as possible. This habit leads to poor recruitment
and mis-profiling of individuals who will in turn become part of the problems in the system. Recruitment at an
officer and managerial level should be done effectively and one should remember that once you make the
mistake it takes sometime before that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are not utilizing their
full potential. This is compounded by the fact that some companies have built a tradition of hiring people based
on personal connections when the person is not qualified for the job. This is a vivid case in most Organizations
today. From the author?s experience, most recruitment that involves managers are done during discussions at
lunch hour, at social clubs or during the coffee break time. All the other processes that follow will only be a
formality as the decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in the recruitment
are not given courses to enlighten them on the importance of the process. One may ask, why is necessary
always to be systematic in recruitment process? Certain type of managers can make a significant impact on
Organizations or Companies. Consequently, a process or a strategy is necessary to deal effectively with equal
opportunity issues, to hire the right people, to minimize cost and most importantly, to identify marginal performers
before they are hired. Inadequate recruitment procedures will result in a number of staff not being sufficiently
qualified either for the positions they hold or their grades levels, especially in management positions. Most formal
systems are flawed in such fundamental respects that there is a tendency to circumvent it through the application
of ad hoc measures, which often rely heavily on personal contacts.
17 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. Problem Statement (Use case Analysis):
2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can attend the personal
interview through online.
2.2 Identified Actors:
2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.2.3 Government Tax Agency: This type of actor has an interest in the behavior of the use case but is not
primary or supporting actor.
3. Design of Online Recruitment System:
3.1. Login:
3.1.1 Brief Description: User name and password
3.1.2 Flow of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data?s are stored in
database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
18 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.3.2 Flow of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the tes
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and updates in the
database.
3.4.2 Flow of Events: when the exam has been finished, DBA evaluates the test and produce the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she can attend the
personal interview through online.
3.5.2 Flow of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant who had cleared
the test
3.6.2 Flow of Events: After the personal interview result will be produced and the applicant can check for the
result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
19 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6. CREDIT CARD PROCESSING SYSTEM
1. Problem Analysis and Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this system is crediting
and doing payback transaction. Carrying of cash to each and every place is a great load for clients in today?s life
and to reduce this, the credit card system was developed. The user interface makes the credit card processing
system to be efficient. It is such a reliable system that it is able to process the client for their corresponding
request and also perform functions for many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not risking the security
of data transaction process. This minimizes the time duration in which the consumer receives the item. The
consumer should purchase an item from the shop by using credit card payment then the merchant should give
response to the consumers view while purchasing an item from the shop and required processing of transaction
should be done by the merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to protect both the
merchant and the consumer from fraud. In its simplest form, the Glossary is a list of noteworthy terms and their
definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly
different ways by different stakeholders; this needs to be resolved to reduce problems in communication and
ambiguous requirements
1.4. Problem Statement
A problem statement is a concise description of the issues that need to be addressed by a problem solving
team and should be presented to them (or created by them) before they try to solve the problem. When bringing
together a team to achieve a particular purpose provide them with a problem statement. The primary purpose of
a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is
too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling. The
credit card transaction is used by the clients to do the crediting features that are available in bank and do the
20 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
payment back. The account has to be updated with the balance every time when the crediting and the payback
are done.
2. Problem Statement (Use case Analysis)
2.1. Identified Use cases
2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or cancel the orders
that they have made.
2.1.4. Crediting Details: This involves the card holder name, card number, card expire date for processing the
amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given duration time to the
concerned organization.
2.2. Identified Actors:
2.2.1. User: The customers who purchase some item from the shop by using credit card payment are stored
here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are administrated by the admin.
3. Design of Credit Card Processing System:
3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow of Events: Customers enter the order number, customer id and total orders they have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
21 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:
3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:
3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained over here.
3.4.2. Flow of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow of Events: The customer goes to login page for making the cash pay back transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
22 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
Expt. No. 2 IDENTIFY USE CASES AND DEVELOP THE USE CASE MODEL
1.USECASE DIAGRAM: PASSPORT AUTOMATION SYSTEM
23 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
2. USECASE DIAGRAM: Online Book Banking Systems
24 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
3.USECASE DIAGRAM: Exam Registration Systems
25 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
4. USECASE DIAGRAM: Stock Maintenance Systems
Login
ViewStock
Place Order &Billing
Purchase Stock
Stock Updation
Profit Computation
Any user
Dealer
Proprietor
DB
Stock Maintainer
USE CASE :
26 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
5.USECASE DIAGRAM: Online Recuirtment Systems
DBA
Test
Checking
Interview
Result
Login
Resume
Applicant
<
<
<
27 Format No:FirstRanker/Stud/LM/34/Issue:00/Revision:00
6.USECASE DIAGRAM: CREDIT CARD PROCESSING SYSTEM
User
Shopping
Crediting
Pay back
<
<
<