Technical Case Writing Guidelines_en

Embed Size (px)


how to create a case solution

Text of Technical Case Writing Guidelines_en


Technical Case Writing GuidelinesConfidentiality:

Document NameTechnical Case Writing Guidelines

VersionV01.30Effective Date2013-12-12

Document CodeBPAL113.0 Manage Base Support

Prepared ByYuan Linghui (ID: 00066393)L213.10 Manage Knowledge

Reviewed ByHuang Junhua (ID: 00162500)L3Manage Explicit Knowledge

Approved ByTan Xinde (ID: 00118692)L4

Process OwnerKnowledge Management Department Leader

ApplicabilityGlobalStandard RoleTechnical case author and technical case reviewer

Relevant Process, Guidelines, or Guide

Document NameDocument Code

Manage Explicit Knowledge Process

1 Purpose

This document provides guidelines for engineers to write technical cases that are easy to find and easy to understand so that these cases can help diagnose and solve problems. This document is applicable to all technical cases to be submitted through the iCase system.

2 Abstract

This document provides guidelines for writing key fields of a technical case with examples.

3 Definition of TermsTermDefinition

Technical caseA technical case is the information about the symptom, causes, recovery measures, preventative measures, and solution of a device or network fault that can be shared among customers and engineers or technical problems that are frequently asked by customers.

Case NominationCase nomination refers to the process when an iCare SR is resolved without any cases used during searching knowledge in iCare system.

4 Content

4.1 Guidelines for Writing nomination Cases4.1.1 TimelinessCases that are created at the request of iCare must be compiled and submitted for review within 10 days after the compiler approves the request.

4.2 Guidelines for Writing Cases and Managing Operations4.2.1 No Case Duplication

1) When submitting or reviewing a case, the author should search in case system to see whether there is a duplicate case, which with same information in Problem Description, Cause, and Solution. Avoid releasing duplicate cases on the system.2) If Troubleshooting process and solution already exist in Documentations and Guides(Product documentation,Precautions,Rectification and Bulletins,Release Documentation,Technical Guide,Functions and Features),dont create a case;

3) Do not duplicate information from archived documents by copying and pasting it.4.2.2 Case Optimization and Update

If you want to correct errors in an existing case or add new information to it, follow the case optimization process to update the case. Do not directly delete the existing case and upload a new one because this will invalidate other documents and email links.

4.2.3 Practicality

Technical cases are written to help engineers or customers with their work and studies related to Huawei products. The case content must be concise. It can be just a description of the handling process of a specific fault or the reply to a specific question.

4.2.4 Writing Instructions

Use correct punctuation marks.Use punctuation marks correctly. Use half-width punctuation marks in English sentences. Do not confuse full-width punctuation marks with half-width punctuation marks.Do not overuse the exclamation mark (!). A counterexample is as follows:

Otherwise the speed would be extremely slow. It takes about two hours!!! Avoid spelling mistakes. Avoid using colloquial language.For example, avoiding saying "We've done it", "our company", "our site", "our end", and "us". Do not include information that is technically irrelevant in your cases.Counterexamples are as follows:

We reinstalled the system for the user because the user has a good relationship with us.

Suddenly, we were struck by an idea; The carrier does not admit this issue

The key is to find evidence.

We have asked for help from Huawei technical support engineers.

After the fault occurred, local Huawei offices tried to resolve it through remote phone instructions but the issue persisted. Starting from the morning on February 2, engineers dispatched by local Huawei offices tried many methods to restore services but the transmission remained intermittent. As the fault could not be identified or rectified in a timely manner, the pressure on local Huawei offices increased. Do not provide ambiguous conclusions.For example, do not say "probably", or "supposedly". Provide formal product names or version numbers.Provide product names or version numbers. That is, use the official names or numbers that Huawei presents to its customers. The format of version numbers must comply with Huawei specifications.

For example, a C&C08 switch cannot be described as "a 08 device", and V610R105M8008 cannot be described as "the 8K version".

If the case content is closely related to a patch version, specify the patch version in the version description. Case generated by nomination should be written in English unless its from Chinese region.4.2.5 Security and Confidentiality

To avoid infringement of right and disclosure of secrets, do not specify the names of individuals, organizations, or countries. You can use codes to represent these names if necessary. Information related to product defects must be strictly managed based on the confidentiality levels of documents. Comply with Huawei's requirements of network security behavior.Do not include any malicious code, malicious software, backdoor virus, or undisclosed interfaces, accounts, or default passwords in your cases.Do not include any tools or methods that can be used to attack customers' networks or crack client passwords.Do not include information about how to illegally obtain software versions, patches, or licenses. Do not specify the names of sites, places, or individuals.Do not specify the names of sites, places, or individuals. This is especially important for networks such as government communication networks, communication networks for important activities, and military networks. Do not disclose the location or contact information, or even the networking information in the case description. If necessary, use the phrase "a certain site" instead of the specific name. Abide Do not specify names of carriers.Do not specify names of carriers in your cases. If necessary, use phrases such as "a certain site" or "an external site" instead. When describing interconnection or interworking problems, do not specify carriers' access codes. For example, use 179X9 when referring to access code 17909.

Use proper expressions when referring other vendors or their equipment.Use codes when referring to a vendor. The format is "vendor" + initial capital letter. For example, use vendor E to represent Ericsson, vendor B to represent Shanghai Bell, and vendor S to represent Siemens. As for equipment, the format is initial capital letter + X (the length of X should be consistent with that of the equipment name). For example, S1240 is referred to as SXXXX.The following table lists of the codes of some vendors:VendorVendor Code

Alcatel-LucentVendor A

CiscoVendor C

DatangVendor D

EricssonVendor E

FujistuVendor F

JuniperVendor J

NSNVendor N


NortelVendor NL

MotorolaVendor M

ZTEVendor Z

Shanghai BellVendor B

SiemensVendor S

UTVendor U

LucentVendor L

3comVendor 3com


NokiaVendor NK

HarborVendor H

GaokeVendor G

Exercise caution when using sensitive words related to national or political information.1. Exercise caution when using sensitive words such as "public security bureau", "public security unit", "state council", "xx provincial government", "Chairman xx", "Premier xx", and "xx military region". Avoid disclosing national secrets.2. If possible, do not specify country names. Do not use religiously or politically sensitive words.3. Lawful interception is a confidential action authorized by national laws. All information related to lawful interception, including lawful interception protocols, is considered to be national secrets. The confidentiality level of cases that involve security interception, public security interception, public security bureau interception, and lawful interception must be Huawei engineers.4.3 Writing Guidelines for Key Fields4.3.1 Title (Mandatory)1. For a fault, write the symptom and cause of a fault in the title.You are advised to use the symptom+ cause format, such as XXX Fails due to XXX Cause.

2. For an FAQ,write the title in any of the following formats:

FAQ - What Is XXX?

FAQ - Why XXX?

FAQ - How to Do XXX?

3. The content in the title should be clear and concise and with a maximum of 200 characters.4. The title should be one sentence, dont add interpunction mark in title.4.3.2 Product Information (Mandatory)1. Must choose product name or PBI information.

2. If case refers to Multi-product, need click Yes in Multi-product.4.3.3 Fault Type (Mandatory)

Select a fault type based on the symptom, but not based on the root cause or solution.

If there are multiple symptoms, select a fault type based on the primary symptom. If some new faults or FAQ cases dont fall into any existing L2 or L3 Fault Type,select Others for Fault Type.4.3.4 Problem Description (Mandatory)1. For a fault:

Write the symptom, alarm information, version information, networking overview (including related devices) and operation scenario. If there are multiple symptoms, concentrate on the primary symptom.If the fault occurred after some operations, the case need describe the operation details and related MML commands.

If some counters issue, the ca