ILP Case Study : Trouble Ticket Management System

Title: Trouble Ticket Management System

Overview: The Trouble Tracking Management System enables the customers of a Telecom Servi

ce Company, TSCL to log their comments and Complaints about the Services/ Equipments of TSCL.This system is introduced as a part of excelling the customer satisfaction. After taking the reports from the customer the HelpDesk is acting for the remedy of it. Thus the users of the company are provided with the updated status regarding their reports at the earliest.

A new customer is requested to register in the site for utilizing the facilities provided. A Valid member can post the report about the services/ equipments of TSCL. These reports are available to the agents of the HelpDesk. The requests which are open will be verified and resolved by the agent. If the solution to the problem is acceptable to the customer then they will close it. The unacceptable solution may lead to the modification of the Report where the process can take round trips and get closed at last by the customer. The closed requests will be then deleted by the agent there by removing it from the report collection.

Assumptions & ConstraintsThe system assumes the following:

The details provided by the users are correct.The problem type, sub category and the department entered by the user are correct.The customer can view only the Faults created by their own.The agents can view all the Faults.The remarks updated by the agents are true.

User CharacteristicsUsers:

The Customers of TSCL, who have registered in the system are the Users. Users can Create/ View/ Update the Profile. They can Create/ View/ Update/ Close the Faults.Agents:

The Employees of the TSCL, Agents can View/ Update Remarks for all the Open Faults posted. Agents can delete the closed faults.

Modules

Module1: User Profiles

CRUD 1: User Registration

CRUD Operation 1: Creation of a New User Profile.

Primary user/s : Customer

Primary user action/s : Create a New User Profile (/Register User). The customers should enter the details required to open an account in this system. The details include : Username, Date Of Joining, Address, Email, Phone Number, Alternate Phone Number and Password. If the User Name or Email Exist in the Database, the user is informed with the Pop-Up and should be prompted to change the current Username/ Email details. After successful insertion an alert should be displayed to the customer with the user name and User ID generated.

Associated users : N.A

Input Criteria : 1. User Name – should allow only Alphabets.2. Date Of Joining – Format(“dd/MM/YYYY”).3. Address – NA4. Email – should be a Valid Email ID.5. Phone Number- should allow only digits and hyphen ( -).6. Alternate Phone Number – should allow only digits and hyphen (-).7. Password – should contain a digit, lowercase and Uppercase character.

Minimum length 8. Maximum length 10.

Output or success guarantee : A Pop-Up to show the User ID generated along with User Name. All the fields in the registration should be cleared.

Data requirements :

Data Element Name

Format Description

User_ID Varchar (30) Unique Id generated for User.

User_name Varchar (30) To store the name of the User

Date_Of_Joining DateTime To store the Date of Joining. Should be in “DD/MM/YYYY” Format.

Address Varchar (100) To store the address of the User

Email Varchar (50) To store the email id of the user

Contact_Ph Varchar (50) To store the contact number.

Contact_Ph_Alt Varchar (50) To store the Alternate Contact number.

Password Varchar (50) To store the Password.

Possible exception/error scenarios : If user ID already exists then a pop up message will be displayed.UI requirements : User Registration

UI for Output/ Success: Message Box

CRUD Operation 2: Search for a Particular User from the Users Profiles Collection.

Primary user/s : Customer.

Primary user action/s : View the User Profile. The User can search for the Profile by entering a valid User ID. The entered User Id, if exist should display all the details entered while registering. There should be a link to display “Edit User Profile”, if the logged on user id and the Search User Id are the same, clicking on this Link must redirect to “Update User Profile” page. If the current User ID and the Search User ID are not the same, then hide the link “Edit User Profile” .

Associated users : N.A

Input Criteria : User ID – Unique Identifier.

Data requirements :

Data Element Name

Format Description

User_ID Varchar (30) Unique Identity of the user.

Possible exception/error scenarios : The Entered User Id if does not exist Prompt the User with the appropriate message.

UI requirements : View User Details

CRUD Operation 3: Update the User Profile.Primary user/s : Customer Primary user action/s : Update the User Profile. The Update User Profile Page will help the U

ser to modify some of the values entered while registering, except their User ID and Account generated. Here, the user can modify the UserName and Email, so again check whether the UserName and Email Exist or not. If the UserName or Email exist, prompt the user for new values.If not Exist, then the user can update his profile with the new values.

Associated users : N.AInput Criteria : 1. User Name – should allow only Alphabets.2. Address – NA3. Email – should be a Valid Email ID.4. Phone Number- should allow only digits and hyphen ( -).5. Alternate Phone Number – should allow only digits and hyphen (-).Data requirements :

Data Element Name

Format Description

User_name Varchar (30) To store the name of the User. Take only alphabets.

Address Varchar (100) To store the address of the User

Email Varchar (50) To store the Valid email id of the user

Contact_Ph Varchar (50) To store the contact number

Contact_Ph_Alt Varchar (50) To store the Alternate Contact number.

Possible exception/error scenarios : The user can modify the UserName and Email, before submitting the page check whether the UserName and Email Exist. If Exist, promptthe user to use the new values.

UI requirements : Update User Details

Module2: Fault Creation.

CRUD Operation 1: Create new Faults.

Primary user/s : Customers

Primary user action/s : Create a New Fault. The Customer should verify the system that their details exist in the database for the further enquiries, so Enter the customer is asked to enter the valid Phone Number to get the User Details. If the Phone number exists the customer details are then displayed in the User details Pane along with the Options to move to “Raise a Fault” and “View the Faults”. If the Customer moves on to the “Raise a Fault” page, then they should enter the Problem Type, Sub category type, Assigned department and remarks regarding the Fault and can submit the details. A successful insertion will lead to the Successful insertion page, where the customer can see the Fault ID and the Account generated while creating the User Profile for the new fault created. And the “”View Faults” page, will list all

the Faults submitted by the current User. If the phone number does not exist, the customer can be prompted with an error in the entry and can ask to enter the details that are required.

Associated users : N.A

Input Criteria : Phone Number: Valid Phone NumberProblem Type : Select one among the Problem Type: Line Issue, Service Issue,

Equipment Issue and Billing Issue.Sub category : Line Issue – Noisy Line, Call Interference, Line damage.

: Service Issue – Major service outage at Provider.: Equipment Issue – Noisy, No Dial Tone, Damaged Equipment.: Billing Issue – Billing paid not updated, Wrong Billing.

Department Type: Infrastructure, Billing.Remarks : User's Remark.

Output or success guarantee : Show View Fault Page, only with Open Status for the customers.

Data requirements :

Data Element Name

Format Description

Problem_Type Varchar (50) To store the main Problem type.

Sub_Category Varchar (50) To store the Sub category.

Department Varchar (50) To store the Department.

Remarks Varchar (200) To store the Remarks.

Status Bit 1; 1-> Open0-> Close.

Possible exception/error scenarios : If the Problem type is assigned to the wrong department prompt the user with an alert.

UI requirements:: Create New Fault

CRUD Operation 2: View Faults.

Primary user/s : Customers

Primary user action/s : View Faults created by own. If the User have already raised any Fault , then he/ she should be able to view all the Faults and the corresponding details as well. In the View Faults page, there is a provision to enter the User Id and Select the Status, these options will not be available to the customers. The customers can view only the Account, Phone number and the relevant details of the Fault created by the customer. The details of each Fault should be shown in the View Fault Detail page. Here, the customer should be able to modify the Fault details or Close the status of the Fault which makes the visibility of the Fault to false. By making the status to close makes the fault ready to delete from the Fault Collection(This is done by the Agent, while viewing the Faults.). If there does not exist any Fault with the current user then prompt the customer that “No Faults Found.”, in this page.

Associated users : N.A

Input Criteria :Fault Id: Select any one among the List of the Faults.

Output or success guarantee : Show View Faults Page. The Faults having the status as Open are only seen here.

Output or success guarantee : Show View Fault Page, for the selection of view.Data requirements :

Data Element Name

Format Description

Fault_ID Varchar (50) To show the Fault details.

Possible exception/error scenarios :

UI requirements: View Faults

UI Output/ Success: View Fault Detail

CRUD Operation 3: Update a Fault.

Primary user/s : Customers

Primary user action/s : The customer can modify the Open Fault. The customer can choose one among the Faults displayed in the View Faults Page. This selection should lead them to the View Fault Details page, where they can Either Update or Close the Fault. Here, the customers can either choose Update or Close the Fault. If the customer selects the Update, it should lead to the Update Fault Page, where the customer can view the current values for the pro

blem type, sub category type, Department and remarks along with the submit button. After the desired modifications the customer can submit the details to make the changes and thereby can seek the remedy from the helpdesk with the updated values. If the customer selects the close, it should change the status of the fault as false. This status change makes the fault invisible to the customer from next attempt onwards.(Later, when the Other user, Agent views all the Fault, the closed faults are made avilable to delete.)

Associated users : N.AInput Criteria :

Problem Type : Select one among the Problem Type: Line Issue, Service Issue, Equipment Issue and Billing Issue.

Sub category : Line Issue – Noisy Line, Call Interference, Line damage.: Service Issue – Major service outage at Provider.: Equipment Issue – Noisy, No Dial Tone, Damaged Equipment.: Billing Issue – Billing paid not updated, Wrong Billing.

Department Type: Infrastructure, Billing.Remarks : User's Remark.

Output or success guarantee : Show View Faults Page with Open Status.Data requirements :

Data Element Name

Format Description

Problem_Type Varchar (50) To store the modified Problem type.

Sub_Category Varchar (50) To store the modified Sub category.

Department Varchar (50) To store the modified Department.

Remarks Varchar (200) To store the Remarks.

Possible exception/error scenarios : Alert for the faults that does not exist.UI requirements: Update Fault Detail

CRUD Operation 4: Close a Fault.Primary user/s : CustomersPrimary user action/s : Closing a Fault. The customer can choose the Close, from the View F

ault Details page and thus makes it hide from next attempt onwards. This ensures that the customer does not have any more issues with the Service/ Equipment provided.

Associated users : N.AInput Criteria :

Status :Make the Status Open to Close.Output or success guarantee : Show View Faults Page.(This will not contain the Closed Faul

ts.)Data requirements :

Data Element Name

Format Description

Status Bit 0; 1-> Open0-> Close.

Possible exception/error scenarios : Alert the customer, if there doesnot exist any fault now.

UI requirements: Close Fault

Module3: Fault ManagementCRUD Operation 1: View the Faults.Primary user/s : AgentsPrimary user action/s : View Faults according to the Status(Open, Closed or Both) of the Fau

lt.The Agent can view all the Faults in the View Faults page submitted by the Customers according to the selection of the Status(This status selection in the View Faults page is only available to the Agent, not to the Customer). The agent can also specify the User ID to view the Faults submitted by a single Customer(This User ID facility should only be available to the Agent, not to the customer. See the assumptions & constraints). The agent can then view the Faults defined in connection with the selection of the status. In the faults listing, the agent is provided with some more options. All the Open faults are available with View and Update option and All the Closed faults are available with the View and Delete option. For the Agent the View Option will help them to View the details of the Faults Listed in the View Fault Details page.

Associated users N.AInput Criteria-

User Id – Enter the User Id to View The Fault.Filter by Status – Status can be Open/ Closed/ Both.

Output or success guarantee: Data requirements :

Data Element Name

Format Description

User_Id Varchar (30) To search the Faults created by User.

Status Varchar (20) To specify Open/Closed

Possible exception/error scenarios : User does not exist.UI requirements : View Faults.

UI Output/ Success: View Fault Detail

CRUD Operation 2 : Update the Fault.Primary user/s : AgentsPrimary user action/s : Update the Fault. The customer after selecting the View of the Fault

detail, moves on to the View Fault details page where there is an Update button(The Close Fault button should be invisible for an agent, because the agent doesn't have the option to close the fault.). Then the agent should be redirected to the Update Fault page, where the agent updates only the remark and Submits it. This new Modification will be reflected to the the view Faults page for the customers as well.(This remark acts like the remedy to the Fault raised by the Customer.) .

Associated users N.AInput Criteria-

Remarks : Agent's Remark.Output or success guarantee: Show the Screen of the View Faults Page.Data requirements :

Data Element Na Format Description

me

Fault_ID Varchar (50) To show the Fault details.

Remarks Varchar (200) To store the Remarks.

Possible exception/error scenarios : UI requirements: Update Fault Details

CRUD Operation 3: Fault Deletion.Primary user/s : AgentsPrimary user action/s :Delete the Closed Faults. All the Faults which are closed by the custo

mers should be listed to the agent in the View Faults Page by selecting either the status as Closed/ Both. Then thereby selecting the Delete option along with each Fault details will remove the fault details from the database.

Associated users N.AInput Criteria- N.AOutput or success guarantee : Refresh the Screen of the View Faults page.Data requirements : N.APossible exception/error scenarios : UI requirements::View Faults.