ILP Case Study : Trouble Ticket Management System

Title:
Trouble Ticket Management System

Overview:
The Trouble Tracking Management System enables the customers of a Telecom Service Company, TSCL to log their comments and Complaints about the Services/ Equi pments of TSCL. This system is introduced as a part of excelling the customer satisfaction. After taking t he reports from the customer the HelpDesk is acting for the remedy of it. Thus the user s of the company are provided with the updated status regarding their reports at the e arliest. A new customer is requested to register in the site for utilizing the facilities prov ided. A Valid member can post the report about the services/ equipments of TSCL. Thes e 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 th e customer then they will close it. The unacceptable solution may lead to the modificati on of the Report where the process can take round trips and get closed at last by the c ustomer. The closed requests will be then deleted by the agent there by removing it fr om the report collection.

Assumptions & Constraints

The 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 c orrect. 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 Characteristics
Users: 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 sh ould 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 an

d 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. Aft er successful insertion an alert should be displayed to the customer with the user nam e 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 NA 4. 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 N Format ame User_ID User_name Date_Of_Joining Address Email Contact_Ph Contact_Ph_Alt Password Varchar (30) Varchar (30) DateTime Varchar (100) Varchar (50) Varchar (50) Varchar (50) Varchar (50) Description Unique Id generated for User. To store the name of the User To store the Date of Joining. Should b e in DD/MM/YYYY Format. To store the address of the User To store the email id of the user To store the contact number. To store the Alternate Contact numb er. To store the Password.

Possible exception/error scenarios : If user ID already exists then a pop up messag e 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 e ntering a valid User ID. The entered User Id, if exist should display all the details entere d while registering. There should be a link to display Edit User Profile, if the logged o n user id and the Search User Id are the same, clicking on this Link must redirect to U pdate User Profile page. If the current User ID and the Search User ID are not the sam e, then hide the link Edit User Profile . Associated users : N.A Input Criteria : User ID Unique Identifier. Data requirements : Data Element N ame User_ID Format Varchar (30) Description 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 hel p the User to modify some of the values entered while registering, except their Us er ID and Account generated. Here, the user can modify the UserName and Email, s o again check whether the UserName and Email Exist or not. If the UserName or E mail exist, prompt the user for new values.If not Exist, then the user can update hi s profile with the new values. Associated users : N.A Input Criteria : 1. User Name should allow only Alphabets. 2. Address NA 3. 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 N Format ame User_name Address Email Contact_Ph Contact_Ph_Alt Varchar (30) Varchar (100) Varchar (50) Varchar (50) Varchar (50) Description To store the name of the User. Take only alphabets. To store the address of the User To store the Valid email id of the use r To store the contact number To store the Alternate Contact numb er.

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, pro mpt the 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 t hat 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 exi sts the customer details are then displayed in the User details Pane along with the Opti ons 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, Assi gned department and remarks regarding the Fault and can submit the details. A succes sful insertion will lead to the Successful insertion page, where the customer can see th e Fault ID and the Account generated while creating the User Profile for the new fault c reated. And the View Faults page, will list all the Faults submitted by the current Us er. 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 Number 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 Fault Page, only with Open Status for the customers. Data requirements : Data Element N Format ame Problem_Type Sub_Category Department Remarks Status Varchar (50) Varchar (50) Varchar (50) Varchar (200) Bit Description To store the main Problem type. To store the Sub category. To store the Department. To store the Remarks. 1; 1-> Open 0-> Close.

Possible exception/error scenarios : If the Problem type is assigned to the wrong d epartment 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 a ny 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 an d Select the Status, these options will not be available to the customers. The custo mers can view only the Account, Phone number and the relevant details of the Faul t created by the customer. The details of each Fault should be shown in the View Fa ult Detail page. Here, the customer should be able to modify the Fault details or Clo se 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 N Format ame Fault_ID Varchar (50) Description 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 c hoose one among the Faults displayed in the View Faults Page. This selection should le ad them to the View Fault Details page, where they can Either Update or Close the Faul t. Here, the customers can either choose Update or Close the Fault. If the customer sel ects the Update, it should lead to the Update Fault Page, where the customer can view the current values for the problem type, sub category type, Department and remarks a long with the submit button. After the desired modifications the customer can submit t he details to make the changes and thereby can seek the remedy from the helpdesk wi th 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 ne xt attempt onwards.(Later, when the Other user, Agent views all the Fault, the closed f aults are made avilable to delete.)

Associated users : N.A Input 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 N Format ame Problem_Type Sub_Category Department Remarks Varchar (50) Varchar (50) Varchar (50) Varchar (200) Description To store the modified Problem type. To store the modified Sub category. To store the modified Department. 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 : Customers Primary user action/s : Closing a Fault. The customer can choose the Close, from the View Fault Details page and thus makes it hide from next attempt onwards. This en sures that the customer does not have any more issues with the Service/ Equipmen t provided. Associated users : N.A Input Criteria : Status :Make the Status Open to Close. Output or success guarantee : Show View Faults Page.(This will not contain the Clos ed Faults.) Data requirements : Data Element N Format ame Status Bit Description 0; 1-> Open 0-> Close.

Possible exception/error scenarios : Alert the customer, if there doesnot exist any f ault now. UI requirements: Close Fault

Module3: Fault Management CRUD Operation 1: View the Faults. Primary user/s : Agents Primary user action/s : View Faults according to the Status(Open, Closed or Both) of the Fault. The Agent can view all the Faults in the View Faults page submitted by the Custom ers 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 specif y 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 sele ction of the status. In the faults listing, the agent is provided with some more optio ns. 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.A Input CriteriaUser 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 N Format ame User_Id Status Varchar (30) Varchar (20) Description To search the Faults created by User. 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 : Agents Primary user action/s : Update the Fault. The customer after selecting the View of th e Fault detail, moves on to the View Fault details page where there is an Update bu tton(The Close Fault button should be invisible for an agent, because the agent doe sn'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 n ew Modification will be reflected to the the view Faults page for the customers as w ell.(This remark acts like the remedy to the Fault raised by the Customer.) . Associated users N.A Input CriteriaRemarks : Agent's Remark. Output or success guarantee: Show the Screen of the View Faults Page. Data requirements : Data Element N Format ame Fault_ID Varchar (50) Description 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 : Agents Primary user action/s :Delete the Closed Faults. All the Faults which are closed by th e customers should be listed to the agent in the View Faults Page by selecting eithe r the status as Closed/ Both. Then thereby selecting the Delete option along with ea ch Fault details will remove the fault details from the database. Associated users N.A Input Criteria- N.A Output or success guarantee : Refresh the Screen of the View Faults page. Data requirements : N.A Possible exception/error scenarios : UI requirements::View Faults.