During the development of the project, 13 documents should be written as required, and the documentation requirements are targeted, accurate, clear, complete, flexible, and traceable.

During the development of the project, 13 documents should be written as required, and the documentation requirements are targeted, accurate, clear, complete, flexible, and traceable.
◇ Feasibility Analysis Report: Explain the feasibility of the implementation of the Software development Project on the technical, economic and social factors, and comment on the reasons of the selected implementation plan in order to reasonably meet the various possible implementation options for the development target.
◇ Project Development Plan: Develop specific plan for Software project implementation program,Should include the responsible personnel of each part of the work, the progress of development, the budget of development funds, the required hardware and software resources.
◇ Software Requirement Specification (software specification): The function, performance, user interface and operating environment of the software developed are described in detail. It is written under the condition that both the user and the developer have a common understanding and agreement on the software requirements, and it is the basis of the implementation of the development work. The specification should give the data logic and the requirements of the collection, in order to generate and maintain the system data files ready.
◇ Summary Design Specification: This manual is a summary of the actual stage of the work results, it should explain the function allocation, module division, the overall structure of the program, input and output and interface design, operation design, data structure design and error processing design, to provide the basis for detailed design.
◇ Detailed Design Specification: emphatically describes how each module is implemented, including the implementation of algorithms, logic flow and so on.
◇ User manual: This manual describes the function, performance and user interface of the software, which gives the user a detailed understanding of how to use the software, and provides the operator with the knowledge of the various operating conditions of the software, especially the details of the operation method.
◇ Test Plan: In order to do the integration test and acceptance test, the implementation plan should be developed for how to organize and test. The plan should include the content of the test, progress, conditions, personnel, the selection of test cases, the allowable deviation range of the test results, etc.
◇ Test Analysis Report: After the completion of the test work, the test plan should be submitted a description of the implementation of the test results are analyzed, and put forward the test of the concluding comments.
◇ Development Progress Monthly: The monthly report of the software personnel to the management of the project progress reports, the report should include the progress plan and actual implementation of the comparison, stage results, problems encountered and solutions, and the next month's plan.
◇ Project Development Summary Report: After the completion of software project development, should be compared with the project implementation plan, summarize the actual implementation of the situation, such as progress, results, resource utilization, cost and input of manpower, in addition, also need to evaluate the development work, summed up the experience and lessons.
◇ Software Maintenance Manual: mainly includes software system description, program module description, operating environment, support software Description, maintenance process description, easy to maintain the software.
◇ software Problem Report: Indicate the registration of software problems, such as date, discovery person, status, problem belongs to the module, to provide preparation for software modification documents.
◇ Software Modification Report: After the SOFTWARE PRODUCT is put into operation, it is found that it needs to be amended, changed and so on, the existing problems, modification considerations and the influence of the modification should be described in detail and submitted for approval.

Feasibility Analysis Report

1 Introduction
1.1 Purpose: To clarify the purpose of preparing the feasibility study report and to propose the reader object.
1.2 Project background: should include
The name of the proposed development software
The project's task-seekers, developers, users, and units that implement the software
The relationship between the project and other software or other systems.
1.3 Definition: Lists the definitions of the specialized terms used in the document and the original text of the abbreviations.
1.4 References: Lists the author, title, number, publication date, publication unit or source of the information, which may include
Approval of the project's approved plan of assignment, contract or superior authority
Published information related to the project
The data referenced in the document, the software standards or specifications used
2 Prerequisites for Feasibility studies
2.1 Requirements: List and describe the basic requirements for the proposed development of the software, such as
function
Performance
Input/Output
Basic data flow and process flow
Security and confidentiality requirements
Other software-related systems
Finish date
2.2 Objectives: may include
Savings in human and equipment costs
Improvement of processing speed
Control accuracy or productivity improvement
Improvements in Management information services
Improvement of decision System
Improvement of staff productivity
2.3 Items, assumptions and limitations: may include
Recommended to develop the shortest life span of software operation
The time limit for the comparison of obvious options
Sources of funding and restrictions on use
Legal and policy constraints
Conditions and limitations for hardware, software, operating environment, and development environment
Available information and resources
Recommend the latest time to develop software to be put into use
2.4 Feasibility Study Methods
2.5 key factors in determining feasibility
3 analysis of the existing systems
3.1 Process flow and data flow
3.2 Workloads
3.3 Expense: Expenses such as manpower, equipment, space, supporting services, materials, etc.
3.4 Personnel: List the professional technical categories and quantities of personnel required
3.5 devices
3.6 Limitations: Explain existing system problems and why new systems need to be developed
4 Recommended Technical Feasibility analysis
4.1 Brief description of the system
4.2 Advantages of comparison with existing systems
4.3 Process flow and data flow
4.4 Possible implications of using the proposed system
Impact on the device
Impact on Existing software
Impact on users
Impact on the operation of the system
Impact on the development environment
Impact on expenditure of funds
4.5 Technical feasibility Evaluation: including
Whether the functional purpose is achieved under the restriction condition
Using the existing technology, the functional purpose is to achieve
Requirements for the number and quality of developers, and indicate whether they meet
Whether the development can be completed within the stipulated period
5 Proposed system economic feasibility analysis
5.1 Expenditure
5.2 Benefits
5.3 Yield/investment ratio
5.4 Payback Period
5.5 Sensitivity analysis: Refers to a number of key factors, such as:
System life Cycle length
The amount of system work load
Processing speed Requirements
Analysis of the impact of equipment and software configuration changes on expenditures and benefits
6 feasibility analysis of social factors
6.1 Legal factors: such as
Contractual liability
Infringement of patent rights
Copyright infringement
6.2 Use of the user feasibility: such as
Administration of user Units
Working system
Personnel quality and so on can meet the requirements
7 Other options available
Clarify other options individually and highlight the reasons for not being recommended.
8 Concluding observations
can start to organize development
Need to wait for a few conditions to be developed
Some modifications to the development goals are required
cannot be or does not need to be
Other

Project Development Plan

1 Introduction
1.1 Purpose: To clarify the purpose of preparing the feasibility study report and to propose the reader object
1.2 Project background: should include
The entrusted units, development units and competent departments of the project;
The relationship between the software system and other systems.
1.3 Definition: List the definitions and abbreviations of the special terms used in the document
1.4 References: may include:
Approval of the project's approved plan of assignment, contract or superior authority
Materials, specifications, etc. referenced in the document
List the author, title, number, publication date, publication unit or source of the information;
2 Project Overview
2.1 Work Content: Brief description of the main work of the project, introduce the function of the software developed, performance, etc., if not to write a feasibility study report, you should give a more detailed introduction in this section;
2.2 Articles and limitations: clarify the conditions to be fulfilled in order to complete the project, the conditions that the development unit already has, and the conditions that are still to be created. The work, completion period and other conditions and limitations of the user and sub-contract shall also be described if necessary.
2.3 Products
2.3.1 Program: Lists the name of the program to be delivered, the language used, and the form of storage.
2.3.2 Documentation: Lists the documents that should be delivered.
2.4 Operating environment: should include hardware environment, software environment.
2.5 Service: Clarify the service that the development Organization can provide to the user. such as personnel training, installation, warranty, maintenance and other operational support.
2.6 Acceptance Criteria
3 Implementation Plan
3.1 Task decomposition: The Division of tasks and the person responsible for each task.
3.2 Progress: Projects completed by stages, with charts explaining the start time, finish time.
3.3 Budget
3.4 Key issues: Describe the key issues that may affect the project, such as equipment conditions, technical difficulties or other risk factors, and explain the countermeasures.
4 Personnel organization and division of Labor
5 Delivery term
6 highlights of the thematic plan
such as test plan, quality assurance plan, configuration management plan, personnel training plan, system installation plan, etc.

Software Requirement Specification

1 Introduction
1.1 Purpose: To clarify the purpose of writing the requirements statement, indicating the reader object.
1.2 Project background: should include
The entrusted unit, Happy Unit and competent department of the project;
The relationship between the software system and other systems.
1.3 Definition: A wish to list the definitions and abbreviations of the specialized terms used in the document.
1.4 References: may include
Approval of the project's approved plan of assignment, contract or superior authority
Materials, specifications, etc. referenced in the document
List the author, title, number, publication date, publication unit, or source of the information
2 Overview of tasks
2.1 Goals
2.2 Operating Environment
2.3 Items and Limitations
3 Data Description
3.1 Stance Data
3.2 Dynamic Data: Includes input data and output data.
3.3 Database Description: Gives the name and type of the database used.
3.4 Data Dictionary
3.5 Data acquisition
4 Functional Requirements
4.1 Functional Divisions
4.2 Function Description
5 Performance requirements
5.1 Data accuracy
5.2 Time characteristics: such as response time, update processing time, data conversion and transmission time, running time, etc.
5.3 Adaptability: In the way of operation, operating environment, interface with other software and development plan change, should have adaptability.
6 Operational requirements
6.1 User interface: such as screen format, report format, menu format, input and output time, etc.
6.2 Hardware Interface
6.3 Software Interface
6.4 Fault Handling
7 Other requirements
such as usability, security and confidentiality, maintainability, portability, etc.

Overview Design Manual

1 Introduction
1.1 Writing Purpose: To clarify the purpose of writing a summary design specification, indicating the reader object.
1.2 Project background: should include
Entrusted units, development units and competent departments of the project
The relationship between the software system and other systems.
1.3 Definition: The willingness to list the definitions and abbreviations of the terminology used in this document.
1.4 References:
List the author, title, number, publication date, publication unit, or source of the information
Approval of project tasks, contracts or higher authorities, project development plan, requirements Specification, test plan (first draft), User manual
The materials referenced in the document, the standards or specifications adopted.
2 Overview of tasks
2.1 Goals
2.2 Requirements Overview
2.3 Items and Limitations
3 Overall Design
3.2 Overall structure and module exterior design
3.3 Function Assignment: Indicates the relationship between function and program structure.
4 Interface Design
4.1 External interface: Includes user interface, software interface and hardware interface.
4.2 Internal interface: the interface between the modules.
5 Data structure Design
6 Logical Structure Design
The unified cover page format for all documents is shown in the following pages.
7 Physical Structure Design
8 The relationship between data structure and program
9 Running the design
9.1 Combination of running modules
9.2 Operation Control
9.3 Run time
10 Error Handling Design
10.1 Error Output information
10.2 Error Handling countermeasures: such as setting up backup, performance degradation, recovery and restart.
11 Secure and confidential design
12 Maintenance Design
Description for the convenience of maintenance work facilities, such as maintenance modules.

Detailed design Instructions

1 Introduction
1.1 Purpose: To clarify the purpose of writing a detailed design specification, indicating the reader object.
1.2 Project background: should include the source of the project and the competent departments.
1.3 Definition: The willingness to list the definitions and abbreviations of the terminology used in this document.
1.4 References:
List the author, title, number, publication date, publication unit, or source of the information
Approval of project tasks, contracts or higher authorities, project development plan, requirement specification, summary design specification, test plan (first draft), User manual
The document refers to the data, software development standards or specifications.
2 overall design
2.1 Requirements Overview
2.2 Software structure: Give the structure diagram of software system.
3 Program Description
3.1 The following instructions are given on a per-module basis:
function
Performance
Enter Project
Output Project
3.2 algorithm: The algorithm chosen by the module.
3.3 Program Logic: Detailed description of the module implementation of the algorithm, can be used: standard flow chart; PDL language; n-s diagram; decision table and other descriptive algorithms.
3.4 Interface
Storage allocation
Restriction conditions
3.5 Test points: Give the test module of the main test requirements.

User Operating Manual

1 Introduction
1.1 Purpose: To clarify the purpose of the preparation of the manual, indicating the reader object.
1.2 Project background: Explain the source of the project, the entrusted Unit, the Development Unit and the competent department.
1.3 Definition: Lists the definitions of the terminology used in the manuals and the willingness to abbreviate the words.
1.4 References:
List the author, title, number, publication date, publication unit, or source of the information
Approval of project tasks, contracts or higher authorities, project development plan, requirement specification, summary design specification, detailed design specification, test plan
Other materials referenced in the documentation, software engineering standards used, or engineering software specifications.
2 Software Overview
2.1 Goals
2.2 Features
2.3 Performance
2.4 Data accuracy: Includes the accuracy of input, output, and processing data.
2.5 Time characteristics: such as response time, processing time, data transmission time and so on.
2.6 Flexibility: The adaptability of the software in the mode of operation and the need for certain changes in the operating environment.
3 Operating Environment
3.1 Hardware
Lists the minimum hardware configuration required for the software system to run, such as the computer model, main memory capacity
External memory, media, recording format, device model and number
Input and output devices
Type and quantity of data transmission equipment and conversion equipment.
3.2 Support Software
Operating system name and version number
Name and version number of the language compiling system or assembler system
Name and version number of the database management system
Other necessary support software
4 Instructions for use
4.1 Installation and initialization: gives the program's storage form, Operation command, feedback information and its implication, the test example indicating the installation completed, and the software tools required for installation.
4.2 Input: Gives the requirements for input data or parameters.
Data background: Explains data sources, storage media, frequency of occurrence, limitations, and quality management.
Data formats: such as length, Format datum, label, order, delimiter, glossary, ellipsis and repetition, control.
Enter an example.
4.3 output: Gives a description of each output data.
Data background: Explain the whereabouts of the output data, frequency of use, storage media and quality management.
Data format: Details the format of each output data, such as the specific form of the header, body, and tail.
For example
4.4 Error and Recovery: give the error message and its meaning, the action that the user should take, such as modify, restore, restart.
4.5 Help query: Explains how to do it.
5 Operating Instructions
5.1 Run Table: lists each of the possible operating conditions, indicating the purpose of its operation.
5.2 Running steps: Each and every step is described sequentially and should include:
5.3 Operation Control
5.4 Operation Information: Operation purpose, operating purpose, operation requirements, starting method, expected run time, Operation command format and description, and other matters;
5.5 Input/Output files: Give information about creating or updating a file, such as the name and number of the file, the recording media, the remaining directory, the control of the document, the guidelines for determining the retention or discarding of files, the distribution of the objects, the priority of the hardware, and the secrecy control.
5.6 Startup or recovery process
6 Non-routine processes
Provide necessary information and procedures for emergency ring non-routine operation, such as error handling operation, switch operation to back-up system and maintenance personnel instructions and precautions.
7 List of OPERATIONAL commands
Lists the format, function, and parameter descriptions of all operations commands in alphabetical order.
8 Program Files (or command files) and data files list
List file names, identifiers, and descriptions in alphabetical order by file name, or by function and module sort order.
9 User Action Examples

Test Plan

1 Introduction
1.1 Purpose: To clarify the purpose of writing a test plan and to indicate the reader object.
1.2 Project background: Explain the source of the project, the entrusted unit and the competent department.
1.3 Definition: Lists the definitions and acronyms of the specific terms used in the test plan.
1.4 References: Lists the author, title, number, date of publication, publication unit or source of the information, which may include: Project plan, contract or approval, project development plan, requirement specification, summary design specification, detailed design specification, user manual, other information referenced in this test plan, Using
Standards or specifications for software development.
2 Overview of tasks
2.1 Goals
2.2 Operating Environment
2.3 Requirements Overview
2.4 Items and limitations
3 Planning
3.1 Test scenario: Describes the test method and the principle of selecting a test case.
3.2 Test Project: Lists the content, name, purpose, and progress of each test in the assembly test and validation test.
3.3 Test Preparation
3.4 Test organization and personnel: the name of the test organization, responsible person and responsibility.
4 Test Project description
4.1 In order to explain the test project one by one
4.1.1 Test project name and test content
4.1.2 Test Cases
4.1.3 Input: Input data and input commands.
4.1.4 Output: Expected output data.
4.2 Steps and Operation
4.3 Allowable deviation: Gives the range of allowable deviations between the measured and expected results.
4.4 Progress
4.5 article: To give out the test of the special requirements of resources, such as equipment, software, personnel and so on.
4.6 Test Data: The information required for the test of the description.
5 reviews
5.1 Scope: Indicates the scope of the problem and its limitations in the various tests completed.
5.2 Guidelines: Describe the criteria for commenting on test results.

Test Analysis Report

1 Introduction
1.1 Purpose: To clarify the purpose of writing the test analysis report and to indicate the reader object.
1.2 Project background: Explain the source of the project, the entrusted unit and the competent department.
1.3 Definition: Lists the definitions of the terminology used in the test analysis report and the original meaning of the abbreviations.
1.4 References: Lists the author, title, number, date of publication, publishing unit or source of information, which may include: Project task book, Contract or approval, project development plan, requirement specification, summary design specification, detailed design specification, user operation manual, test plan , other materials referenced in the test analysis report, software engineering standards used, or engineering specifications.
2 Test Plan Hospitality situation
2.1 Institutions and personnel: give the name of the test organization, the responsible person and the list of participating testers.
2.2 Test Result: Each test item is given in order: The measured result data, deviation from the expected result data, the fact that the test indicates, the problem that the test finds.
3 Software Requirement Test conclusion
The conclusion of each requirement test is given sequentially. Includes: Proven software capabilities, limitations (i.e., the circumstances and reasons for which the requirements have not been adequately tested.
4 reviews
4.1 Software capabilities: the software capabilities that have been tested.
4.2 Defects and limitations: Describes the software defects and deficiencies exposed by the test, and the impact it may have on the software operation.
4.3 Recommendation: To make up for the above deficiencies.
4.4 Test Conclusion: The explanation can pass.

Development progress Report

1 Reporting time and development phase
2 Project Progress
2.1 Major events during the month
2.2 Actual progress vs. Plan comparison
3 hours used
At different levels of the staff to time separately.
4 When using the machine
The computer models are timed separately.
5 expenses
Sort out this month's expenditure items, give total expenditures, and compare them with the plan.
6 problems encountered in the work and countermeasures taken
7 Results completed this month
8 next month's work plan
9 Special problems

Project Development Summary Report

1 Introduction
1.1 Purpose: To clarify the purpose of the preparation of the summary report and to indicate the reader object.
1.2 Project background: Explain the source of the project, the entrusted Unit, the Development Unit and the competent department.
1.3 Definition: Lists the definitions of the specialized terms used in the report and the original meaning of the abbreviations.
1.4 References: Lists the author, title, number, date of publication, publication unit or source of the information, which may include: Project task book, Contract or approval, project development plan, requirement specification, summary design specification, detailed design specification, user operation manual, test plan, test analysis report Other materials cited in this report, development standards adopted or development specifications.
2 Development Results
2.1 Products: May include the name of the program that lists the parts, the number of source program lines (including comment lines) or the number of program bytes and program totals, storage format, product document name, etc.
2.2 Main functions and performance
2.3 Hours used: Timing each person's different levels.
2.4 When used: according to the computer model to be timed separately.
2.5 Progress: Give a comparison between the schedule and the actual progress.
2.6 Fees
3 Reviews
3.1 Productivity evaluation: such as the average number of source lines per person produced per month, document word count, etc.
3.2 Technical Program Evaluation
3.3 Product Quality evaluation
4 Experience and lessons learned

Software Maintenance Manuals

1 Introduction
1.1 Purpose of preparation: to clarify the purpose of the manual and to indicate the reader object.
1.2 Project background: Describe the project's authors, developers, users and use sites.
1.3 Definition: Lists the definitions of the specialized terms used in the report and the original meaning of the abbreviations.
1.4 References: Lists the author, title, number, date of publication, publication unit or source of information, and level of secrecy, which may include: User's manual; Other documentation related to this project.
2 System Description
2.1 System use: Describe the functions, inputs and outputs of the system.
2.2 Security and confidentiality: Explain the system security and confidentiality considerations.
2.3 General Description: Describes the overall function of the system, the system, subsystems and operations to make a comprehensive introduction, and chart the way to give the main part of the internal relationship.
2.4 Program Description: Explain the details and characteristics of each program and sub-program in the system.
Description of the 2.4.1 Program 1
Function: Describes the function of the program.
Method: Describes the implementation method.
Input: The input of the description program, the media, the running data record, the type of input data used at the start of the operation and the storage unit, and the entry requirements related to program initialization.
Processing: processing characteristics and purposes, such as: diagrams to illustrate the process of the operation of the logic flow, the main procedures of the transfer conditions, the procedures of the export requirements at the end of the program, and the next program of Communication and connection (operation, control); The output data type and the storage unit used by this program and the Teahouse Processing Section , program run storage, type and storage location.
Output: The output of the program.
Interface: The interface between this program and other parts of the system.
Table: The details and characteristics of the various tables, items inside the description program. The description of each table includes at least: The identifier of the table, the purpose of use, other programs using this table, logical partitioning, such as block or part, excluding table items, basic structure of the table, design arrangements, including control information for the table. The details of the structure, the characteristics of the use and the identification, location, use, type and coding of each table item are indicated.
Unique Operating Characteristics: Description of the operation of the user manual is not mentioned in the nature.
Description of the 2.4.2 program 2
Same as described in Program 1. The instructions for each subsequent program are the same.
3 Operating Environment
3.1 Equipment: Describe the equipment configuration and characteristics of the system itemized.
3.2 Support Software: Lists the supporting software used by the system, including their name and version number.
3.3 Database: Describes the nature and content of each database, including security considerations.
3.3.1 General Features: identifiers, programs that use these databases, static data, dynamic data, storage media for databases, and restrictions on the use of databases by programs.
3.3.2 Structure and detailed description
Describes the structure of the database, including its records and items.
A description of the composition of the record, including the header or control section, the record body.
A field that describes each record structure, including: a tag or label, the character length and number of digits of a field, and the range of allowable values for that field.
Extensions: Describes the rules for recording append fields.
4 Maintenance process
4.1 Convention: To list all the rules and conventions used in the design of the software system, including: procedures, sub-procedures, records, fields and storage areas of the identification or marking of the use of mnemonic rules; the standard of processing of charts, the sequence of connection of cards, the abbreviations used in statements and tokens, the names of symbols appearing in charts, and the technical standards ; a standardized data element and its characteristics.
4.2 Validation Process: The process of verifying the requirements and procedures (including test procedures and data) and the periodic validation of the program after a program segment has been modified.
4.3 Error and Correction method: List the error status and its correction method.
4.4 Dedicated Maintenance process: a special maintenance process that is not mentioned elsewhere in the documentation. such as: maintenance of the software system input and output parts (such as the database) requirements, procedures and validation methods, run the library to maintain the system necessary requirements, procedures and validation methods, for leap years, the change of the century and the need for temporary changes.
4.5 Dedicated Maintenance Program: Lists the backup technology used to maintain the software system and special procedures (such as file recovery procedures, obsolete files out of the program, etc.) directory, and to explain the contents include: Maintenance job input and output requirements, the input of the detailed process and on the hard equipment to establish, run and complete the operation of maintenance work steps.
4.6 Program list and Flowchart: Refer to or provide the appendix to give the program list and flowchart.

Software Problem Report

1 Registration number
By software configuration Management, a unique, sequential number is specified for the report.
2 Date of registration
The date the software Configuration Management department registered the report.
3 Problem Discovery Date
Date and time when the problem was found.
4 Events
At which stage the problem is identified, divided into unit tests, assembly tests, validation tests, and operational maintenance.
5 Status
Dynamic instructions maintained in the software configuration record, status indication: "Software problem report" is being reviewed to determine what action will be taken; "Software Problem report" has been processed by the designated person, the modification has been completed, tested, ready to be handed to the main library, the main library has been updated, The main library modified the re-test along the unfinished, did a re-test, the problem reappears, did a re-test, the changes did not fail, the "Software Problem Report" was closed, left to be closed later.
6 Reporting persons
Fill in the name, address, and phone number of the "Software Problem report" person.
7 What is the problem?
Distinguish between a problem with a program, a problem with a module, a problem with a database, a problem with a file. may also be some combination of them.
8 Modules/Subsystems
The module name that appears. If you do not know which module, you can mark the subsystem name, as far as possible to give details.
9 Revision number
The version of the module where the problem occurred.
10 Tapes
The identifier of the tape that contains the main library of the problematic module.
11 Database
The identifier of the database used when the problem was found.
12 File Number
The number of the file that has the error.
13 Test Cases
The identifier of the test case that was used when the error was found.
14 Hardware
Identification of the computer system used when the error was found.
15 Problem Description/Impact
Detailed description of the problem syndrome. If possible, indicate where the actual problem lies. The impact of the problem on future tests, interface software, and files is also given.
16 Notes
Record supplemental information.

Software Modification Report

1 Registration number
The number specified by the Software Configuration Management Department for the report.
2 Date of registration
The Software Configuration Management Department registers the date of the software modification report.
3 time
The date when the software modification report is ready.
4 Reporting persons
Fill out the author of the report.
5 Subsystem Name
The name of the subsystem affected by the modification.
6 Module Name
The name of the module being modified.
7 Number of "Software Problem report"
The number of the software problem report that is processed or partially processed by the software modification report. If the problem of a "software Problem report" is only partially handled, then the number is appended with p, such as 1234p.
8 Modifications
Includes program modifications, file updates, database modifications, or combinations of them.
9 Modification Description
A detailed description of the modification. If you are updating files or database modifications, also list the identifiers for file update notifications or database modification requests.
10 Approving persons
The approving person has signed and formally approved the amendment.
11 Statement types
The types of statements involved in program modification include: input/Output statement classes, calculation statement classes, logical control statement classes, data processing statement classes (such as data transfer, access statement classes).
12 Program Name
The name of the program, file, or database being modified.
13 Old revised edition
The current version/revision identification.
14 New revised edition
Revised version/revision of the logo.
15 Database
If a database modification is requested, the identifier for the database is given.
16 Database Modification Report
Database modification request number.
17 Files
If a file is required to be modified, the name of the file is given.
18 File Updates
The number of the file update note.
19 Whether the modification has been tested
Indicate what tests have been made on the modifications, such as units, subsystems, assembly, validation, and run tests, and indicate whether the tests were successful or not.
20 "Software Problem report" gives an accurate description of the issue
Answer ' yes ' or ' no '.
21 Question Notes
Accurately describe the issues to be maintained.
22 Problem Source
Indicate where the problem comes from, such as software Requirement specification, design specification, database, source program, etc.
23 Resources
Estimate of the resources required to complete the modification, that is, the total number of people and the cost of computer time

During the development of the project, 13 documents should be written as required, and the documentation requirements are targeted, accurate, clear, complete, flexible, and traceable.