Standardized Documents used in software development

Standardized Documents used in software development
Standardized document writing

During project development, 13 types of documents should be prepared as required, which should be targeted, accurate, clear, complete, flexible, and traceable.

◇
Feasibility Analysis Report: Describe the technical, economic, and social feasibility of the implementation of the software development project, and comment on various possible implementation plans available to reasonably achieve the development objectives, describe and demonstrate the reasons for the selected implementation scheme.

◇ Project Development Plan: formulate a specific plan for the software project implementation plan, it should include the person in charge of each part of the work, the development progress, the development budget, the required hardware and software resources.

◇
Software Requirement Specification (software specification): describes the functions, performance, user interface, and operating environment of the developed software in detail. It is written under the conditions that both users and developers have a common understanding of the software requirements and reach an agreement. It is also the basis for the implementation of development work. This manual should provide data logic and data collection requirements to prepare for the production and maintenance of system data files.

◇
Summary Design Manual: This manual is the work result of the actual phase of the summary, it should explain the function allocation, module division,ProgramThe overall structure, input and output, interface design, operation design, data structure design, and error handling design provide the basis for detailed design.

◇ Detailed design description: describes how each module is implemented, including implementationAlgorithmAnd logical processes.
◇
User Operation Manual: This Manual describes in detail the functions, performance, and user interface of the software, so that you can get a detailed understanding of how to use the software, provide the operator with relevant knowledge about the various running conditions of the software, especially the detailed operation methods.

◇
Test plan: to complete integration test and acceptance test, an implementation plan should be formulated for how to organize the test. The plan should include the testing content, progress, conditions, personnel, selection principles of test cases, and allowable deviation range of test results.

◇ Test Analysis Report: after the test is completed, a description of the execution of the test plan should be submitted, the test results should be analyzed, and the test conclusions and opinions should be put forward.
◇
Monthly Development Progress Report: This monthly report is a monthly project progress report submitted by software personnel to the management department, the report should include the comparison of the progress plan and actual implementation, the results of the phase, the problems encountered and solutions, and the plans for the next month.

◇
Project Development Summary Report: after the software project is developed, it should be compared with the project implementation plan to summarize the actual implementation status, such as progress, results, resource utilization, costs and manpower invested. In addition, it is also necessary to evaluate the development work and summarize the experiences and lessons learned.

◇ Software maintenance manual: mainly includes software system description, program module description, operating environment, support software description, maintenance process description, easy to maintain software.
◇
Software Issue Report: indicates the registration of software problems, such as the date, discoverer, status, module of the problem, and provides the preparation documents for software changes.
◇
Software Modification Report: after the software product is put into operation, it is found that it needs to be corrected, changed, and other problems. The existing problems, modification considerations, and the impact of the changes should be described in detail, submit for approval.

Feasibility Analysis Report

1 Introduction
1.1 Purpose: To clarify the purpose of preparing a feasibility study report and propose readers.
1.2 Project Background: it should include

● Name of the software to be developed
● Project Task initiators, developers, users, and software implementation units
● Relationship between the project and other software or systems.

1.3 definition: lists the definitions of specialized terms used in the document and the original acronyms.
1.4
Reference: lists the author, title, number, publication date, publisher, or source of the relevant information, including
● Approved plans and tasks, contracts or approvals from higher authorities
●
Project-related published documents
● The software standards or specifications used for the materials referenced in the document
2 prerequisites for the feasibility study
2.1
Requirements: List and describe the basic requirements for software development, as shown in
● Functions
● Performance
● Input/output
● Basic data process and processing process

● Security and confidentiality requirements
● Other software-related systems
● Completion date
2.2 Goals: may include
●
Manpower and equipment cost savings
● Improved processing speed
● Control accuracy or productivity improvement
● Management Information Service Improvement
● Improvement of the decision-making system

● Personnel Efficiency Improvement
2.3 Conditions, assumptions, and restrictions: may include
● We recommend that you develop the shortest life of software.
●
Period for comparison of apparently selected Solutions
● Funding sources and restrictions
● Legal and policy restrictions
● Hardware, software, operating environment, and development environment conditions and restrictions

● Available information and resources
● It is recommended that the latest time for software development to be put into use
2.4 feasibility study methods
2.5 main factors determining feasibility

3. Analysis of existing systems
3.1 process and data process
3.2 workload
3.3
Expenses: such as manpower, equipment, space, support services, materials, etc.
3.4 personnel: list the professional and technical categories and quantity of required personnel
3.5 Devices
3.6
Limitations: describes 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 over existing systems
4.3 process and data process
4.4 potential impact of the adoption of the recommendation system
● Impact on devices
●
Impact on existing software
● Impact on users
● Impact on system operation
● Impact on the Development Environment
● Impact on expenditures

4.5 technical feasibility evaluation: including
● Whether or not the functional purpose has been met under restrictions
● Use existing technologies to determine whether the functional objectives are met
●
Requirements on the number and quality of developers, and whether the requirements can be met
● Whether the development can be completed within the specified period
5. Economic Feasibility Analysis of the proposed system
5.1 expenditure

5.2 benefits
5.3 earnings/investment ratio
5.4 investment recovery period
5.5 sensitivity analysis: it refers to some key factors, such:
●
System Lifecycle
● System workload
● Processing speed requirements
● Analysis of the Impact of device and software configuration changes on expenditures and Benefits
6
Social factor Feasibility Analysis
6.1 legal factors: for example
● Contractual liability
● Patent Infringement
● Copyright Infringement
6.2
User Feasibility: as shown in Figure
● Administrative management of user organizations
● Work System
● Can the personnel quality meet the requirements?
7. Other options

Clarify other options one by one, and emphasize the reasons for unrecommendation.
8. Conclusion
● Start to organize development
●
Development is available only after several conditions are met
● Some modifications to the development target are required.
● Not allowed or not required
● Others

Project development plan

1 Introduction
1.1 Purpose: To clarify the purpose of preparing a feasibility study report and propose readers
1.2 Project Background: it should include

● The project entrusting unit, Development Unit, and competent department;
● Relationship between the software system and other systems.
1.3
Definition: lists the definitions of specialized terms used in the document and the original acronyms.
1.4 references: may include:
● Approved plans and tasks, contracts or approvals from higher authorities

● Documents Reference Materials and specifications
● List the author, title, number, publication date, publisher or source of the materials;
2 Project Overview
2.1
Work content: briefly describe the main work of the project and introduce the functions and performance of the developed software. If no feasibility study report is prepared, a detailed introduction should be provided in this section;
2.2 conditions and restrictions:
Clarify the conditions to be met for project completion, the conditions already met by the development organization, and the conditions still to be created. If necessary, the work undertaken by the user and the sub-contract, the deadline for completion, and other conditions and restrictions shall also be stated.
2.3 Products

2.3.1 procedures: lists the names, languages, and storage formats of the programs to be delivered.
2.3.2 documents: List documents to be delivered.
2.4
Operating Environment: hardware environment and software environment should be included.
2.5 service: clarifies the services that a development organization can provide to users. Such as personnel training, installation, warranty, maintenance, and other operation support.
2.6
Acceptance Criteria
3. Implementation Plan
3.1 task breakdown: the division of tasks and the owner of each task.
3.2 Progress: shows the start time and completion time of a project completed by phase.

3.3 budget
3.4 key issues: describe key issues that may affect the project, such as equipment conditions, technical difficulties or other risk factors, and describe countermeasures.
4. personnel organization and division of labor

5 delivery term
6 main topic plan points
Such as test plan, quality assurance plan, configuration management plan, personnel training plan, and system installation plan.

Software Requirement Specification

1 Introduction
1.1 Purpose: to clarify the purpose of writing a requirement manual and specify the target audience.
1.2 Project Background: it should include
●
The entrusting unit, happy unit and competent department of the project;
● Relationship between the software system and other systems.
1.3 definition: lists the definitions of specialized terms used in the document and the acronyms.

1.4 references: may include
● Approved plans and tasks, contracts or approvals from higher authorities
● Documents Reference Materials and specifications
●
List the author, title, number, publication date, publisher, or source of the materials.
2 task Overview
2.1 goals
2.2 Runtime Environment
2.3 conditions and restrictions

3. Data Description
3.1 Statement data
3.2 dynamic data: Includes input data and output data.
3.3 database Description: name and type of the database to be used.

3.4 Data Dictionary
3.5 data collection
4. Functional Requirements
4.1 function division
4.2 Function Description
5. Performance Requirements
5.1
Data Accuracy
5.2 time features: such as response time, update processing time, data conversion and transmission time, and running time.
5.3
Adaptability: the ability to adapt to changes in operation modes, runtime environments, interfaces with other software, and development plans.
6. operation requirements
6.1
User Interface: such as screen format, report format, menu format, input and output time.
6.2 hardware interface
6.3 Software Interface
6.4 troubleshooting
7. Other requirements

Such as usability, security and confidentiality, maintainability, and portability.

Summary Design Specification

1 Introduction
1.1 Purpose: to clarify the purpose of preparing the summary Design Manual and specify the target audience.
1.2 Project Background: it should include

● Project entrusting, development, and competent departments
● Relationship between the software system and other systems.
1.3
Definition: list the definitions of specialized terms used in this document and the willingness to write them.
1.4 references:
●
List the author, title, number, publication date, publisher, or source of the materials.

● Approved project plans and tasks, contracts or approvals from higher authorities; Project Development Plan; Requirement Specification; Test Plan (first draft); user operation manual
●
Documents Reference Materials, standards or specifications used.
2 task Overview
2.1 goals
2.2 requirement Overview
2.3 conditions and restrictions
3. Overall Design

3.2 overall structure and external design of modules
3.3 function allocation: shows the relationship between functions and program structure.
4. Interface Design
4.1
External interface: includes the user interface, software interface, and hardware interface.
4.2 internal interfaces: interfaces between modules.
5. Data Structure Design
6. Logical Structure Design

The uniform cover format of all documents is shown on the next page.
7 Physical Structure Design
8 Relationship between data structures and programs
9 Operation Design
9.1 combination of running modules

9.2 Operation Control
9.3 running time
10 error handling Design
10.1 error output
10.2
Countermeasures for handling errors: such as backup, performance degradation, recovery, and restart.
11 security and confidentiality Design
12 maintenance Design
It indicates the facilities for convenient maintenance, such as the maintenance module.

Detailed Design Instruction

1 Introduction
1.1 Purpose: To clarify the purpose of preparing a detailed design manual and specify the target audience.
1.2
Project Background: The Source and competent department of the project should be included.
1.3 definition: list the definitions and willingness to write the terms used in this document.
1.4 references:
●
List the author, title, number, publication date, publisher, or source of the relevant information

● Approved project plans and tasks, contracts or approvals from higher authorities; Project Development Plan; Requirement Specification statement; summary design statement; Test Plan (first draft); user operation manual
●
Documents Reference Materials and software development standards or specifications.
2 Overall Design
2.1 requirement Overview
2.2 software structure: If a structure diagram of the software system is given.
3
Program description
3.1 The following describes the modules one by one:
● Functions
● Performance
● Input project
● Output project
3.2
Algorithm: The algorithm selected by the module.
3.3 program logic: Detailed description of the module implementation algorithm, can be used: Standard Flow Chart, PDL language, N-S diagram, decision table and other description of the algorithm chart.
3.4
Interface
● Storage Allocation
● Restrictions
3.5 test points: provide the main test requirements for the test module.

User Operation Manual

1 Introduction
1.1 Purpose: To clarify the purpose of writing a manual and specify the target audience.
1.2
Project Background: Describes the source, entrusting unit, Development Unit, and competent department of the project.
1.3 definition: list the definitions of specialized terms used in the manual and the willingness to write words.
1.4 references:

● List the author, title, number, publication date, publisher or data source of the relevant materials
●
Approved plans and tasks, contracts or approvals from higher authorities; Project Development Plan; Requirement Specification; summary Design Specification; Detailed Design Specification; test plan
●
Other materials referenced in the document, software engineering standards or software engineering specifications used.
2 Software Overview
2.1 goals
2.2 features
2.3 Performance

2.4 data accuracy: includes the input, output, and processing data precision.
2.5 time features: such as response time, processing time, and data transmission time.
2.6
Flexibility: the ability of the software to adapt to certain changes in the operation mode and runtime environment.
3. Runtime Environment
Hardware 3.1
●
List the minimum hardware configurations required for running the software system, such as the computer model and primary storage capacity.
● External Storage, media, record format, device model and quantity
● Input and output devices

● The model and quantity of data transmission devices and data conversion devices.
3.2 support software
● Operating system name and version number
●
Name and version number of the language compilation system or assembly system
● Name and version number of the Database Management System
● Other necessary support software
4. Instructions
4.1
Installation and initialization: Provides the storage format, operation commands, feedback, and meanings of the program, test instances that have been installed, and software tools required for installation.
4.2
Input: provides the requirements for input data or parameters.
● Data Background: describes the data source, storage media, occurrence frequency, restrictions, and quality management.
●
Data format: such as length, format reference, label, sequence, separator, vocabulary, omission and repetition, control.
● Enter an example.
4.3 output: describes each output data.

● Data Background: describes the destination, usage frequency, media storage, and quality management of output data.
●
Data format: details the format of each output data, such as the specific format of the header, subject, and tail.
● Example
4.4
Error and recovery: Provides error information and its meaning. Measures to be taken by the user, such as modification, recovery, and restart.
4.5 help query: describes how to operate.
5 running instructions
5.1
Running table: lists all possible running conditions and describes the purpose.
5.2 operation steps: describes the steps in sequence, including:
5.3 Operation Control
5.4
Operation Information: Running purpose, running purpose, operation requirements, startup method, estimated running time, operating Command Format and description, and other items;

5.5 input/output file: Information about creating or updating a file, such as the file name and number, recording media, retaining directories, and file dominance: guidelines for determining the retention or disposal of files, objects for distributing files, and overcoming hardware priority and confidentiality control.

5.6 start or restore process
6 unconventional Processes

Provide necessary information and operation steps for emergency and unconventional operations, such as handling errors, switching to the backup system, and precautions for maintenance personnel.
7 Operation Command list

The formats, functions, and parameter descriptions of all operation commands are listed alphabetically.
8 list of program files (or command files) and data files

The names, identifiers, and descriptions of files are listed one by one in alphabetical order of file names or in the order of functions and modules.
9 user operation examples

Test Plan

1 Introduction
1.1 Purpose: To clarify the purpose of writing a test plan and specify the target audience.
1.2
Project Background: Describes the source, entrusting unit, and competent department of the project.
1.3 definition: list the definitions of specialized terms used in the test plan and the original meaning of acronyms.

1.4 references: lists the author, title, number, publication date, publisher or source of the relevant information, including the plan and task book, contract or approval of the project, and the Project Development Plan; requirement specification; summary Design Specification; Detailed Design Specification; user operation manual; other materials referenced in this test plan, use

Software development standards or specifications.
2 task Overview
2.1 goals
2.2 Runtime Environment
2.3 requirement Overview
2.4 conditions and restrictions

3 plan
3.1 Test Plan: describes the test methods and principles for selecting test cases.
3.2
Test items: lists the content, name, purpose, and progress of each Assembly Test and validation test.
3.3 test preparation
3.4 testing institution and personnel: name, owner and responsibilities of the testing institution.

4. Test Project Description
4.1 explain the test items one by one in sequence
4.1.1 test project name and 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 operations
4.3
Allowable Deviation: the range between the measured result and the expected result is given.
4.4 progress
4.5 conditions: Special requirements for resources for the item test, such as equipment, software, and personnel.

4.6 Test materials: information required for the test.
5 Rating
5.1 Scope: describes the scope and limitations of the completed tests.
5.2
Guidelines: Describes the criteria for commenting on test results.

Test Analysis Report

1 Introduction
1.1 Purpose: to clarify the purpose of writing a test analysis report and specify the target audience.
1.2
Project Background: Describes the source, entrusting unit, and competent department of the project.
1.3 definition: lists the definitions of specialized terms used in the test analysis report and the original meaning of acronyms.

1.4 references: lists the author, title, number, publication date, publisher or source of the relevant information, including the plan and task book, contract or approval of the project, and the Project Development Plan; requirement specification; summary Design Specification; Detailed Design Specification; user operation manual; test plan; other materials referenced in the test analysis report, adopted software engineering standards or engineering specifications.

2 test program reception
2.1 institution and personnel: name of the testing institution, the person in charge, and the list of participants.
2.2
Test results: the data of the test results is displayed in sequence, which is different from the expected data. The facts indicated by this test and the problems found in this test.
3 software requirement test conclusion

The conclusion of each requirement test is given in sequence. Including: proven software capabilities; limitations (that is, situations and causes where the item requirements are not fully tested.
4 rating
4.1
Software Capability: demonstrated software capability tested.
4.2 defects and limitations: Describe the Software defects and Deficiencies exposed by the test and the potential impact on software operation.
4.3
Suggestion: make a suggestion to make up for the above defects.
4.4 Test conclusion: whether the application can pass the test.

Monthly Development Progress Report

1. Report TIME AND DEVELOPMENT STAGE
2 project progress
2.1 main activities this month
2.2 comparison of actual progress and Plan

3. Working hours
Time by personnel of different levels.
4.
Timing is based on the computer model used.
5. Expenditure

This month's expenditure items are classified and compared with the plan.
6. Problems and Countermeasures
7. Results completed this month
8
Work plan for next month
9 special questions

Project Development Summary Report

1 Introduction
1.1 Purpose: To clarify the purpose of preparing the summary report and specify the target audience.
1.2
Project Background: Describes the source, entrusting unit, Development Unit, and competent department of the project.
1.3 definition: lists the definitions of specialized terms used in the report and the original meaning of acronyms.

1.4 references: lists the author, title, number, publication date, publisher or source of the relevant information, including the plan and task book, contract or approval of the project, and the Project Development Plan; requirement specification; summary Design Specification; Detailed Design Specification; user operation manual; test plan; Test Analysis Report; other materials referenced in this report, development standards or development specifications used.

2 development results
2.1 product: it can include the program name, the number of lines of the source program (including the comment line), the number of bytes of the Target Program, the total number of programs, the storage form, and the product document name.

2.2 Main functions and performance
2.3 working hours: time is calculated based on different levels of personnel.
2.4 When the machine is used: Timing is based on the computer model used separately.
2.5
Progress: Compare the planned progress with the actual progress.
2.6 cost
3 rating
3.1 Productivity Evaluation: such as the average number of source program lines produced by each person per month and the number of words in the document.

3.2 technical solution evaluation
3.3 Product Quality Evaluation
4. Experience and Lessons Learned

Software maintenance manual

1 Introduction
1.1 Purpose: To clarify the purpose of writing a manual and specify the intended audience.
1.2
Project Background: Describe the project initiator, developer, user, and place of use.
1.3 definition: lists the definitions of specialized terms used in the report and the original meaning of acronyms.
1.4
References: lists the author, title, number, publication date, publisher or source of the relevant information, and confidentiality level, including: user operation manual; other documents related to this project.
2 System Description

2.1 system purpose: describes the functions, inputs, and outputs of the system.
2.2 security and confidentiality: Considerations for system security and confidentiality.
2.3
General description: describes the overall functions of the system, comprehensively introduces the system, subsystems, and operations, and provides internal relations of the main parts of the system in a chart.
2.4
Program Description: describes the details and features of each program and sub-program in the system.
2.4.1 description of procedure 1
● Function: describes the functions of the program.
●
Method: describes the implementation method.
● Input: indicates the input, media, running data records, types and storage units of the input data used at the start of running, and entry requirements related to program initialization.

●
Processing: processing features and objectives, such as using charts to describe the logical process of program operation, main transfer conditions of the program, constraints on the program, and exit requirements at the end of the program; communication and connection with the next program (Operation and Control); the output data types and storage units generated by the program and used by the teahouse Processing Section; the program running storage volume, type, and storage location.

● Output: program output.
● Interface: the interface between this program and other parts of the system.

● Table: Describes the details and features of various tables and items in the program. The description of each table includes at least the table identifier, the purpose of use, other programs using the table, logical division, such as blocks or parts, excluding table items, and the basic structure of the table; design arrangement, including table control information. The structure details of a table, the special properties in use, and the identifiers, locations, uses, types, and codes of each table item.

● Unique operation nature: indicates the operation nature not mentioned in the user operation manual.
2.4.2 Procedure 2

It is the same as the description of program 1. Subsequent descriptions of other programs are the same.
3. Operating Environment
3.1 devices: Describes the device configurations and features of the system one by one.
3.2
Supported software: lists the supported software used by the system, including their names and versions.
3.3 Database: describes the nature and content of each database, including security considerations.

3.3.1 General features: such as identifiers, programs using these databases, static data, and dynamic data; storage media of databases; and database restrictions for programs.
3.3.2 structure and detailed description

● Describe the structure of the database, including the records and items.
● Describes the composition of records, including the first or control segment and record body.
●
It indicates the fields of each record structure, including the tag or label, the character length and digits of the field, and the allowed value range of the field.
● Expansion: This describes the rules for appending fields to records.
4 maintenance process

4.1
Conventions: list all the rules and conventions used in the software system design, including rules for using the program, sub-program, record, field and storage area identifier or label enable; chart processing standards, card connection sequence, abbreviations used in statements and marks, symbol names appearing in charts, software technical standards used, standardized data elements and features.

4.2 verification process: describes the requirements and processes (including test programs and data) for verification after a program segment is modified and the periodic verification process of the program.
4.3
Error and rectification method: lists the error status and its rectification methods.
4.4
Specialized Maintenance process: Describes the specialized maintenance process that is not mentioned elsewhere in the document. For example, requirements, processes, and verification methods for maintaining the input and output parts (such as databases) of the software system; required requirements, processes, and verification methods for running the library to maintain the system; temporary modifications required for leap and century changes.

4.5
Dedicated maintenance programs: List and describe the directories of backup technologies and special programs (such as file recovery programs and obsolete file elimination programs) used to maintain the software system, including: maintain the input and output requirements of a job. Detailed input process and operation steps for establishing, running, and completing maintenance tasks on a hardware device.

4.6 program list and flowchart: reference or provide the appendix to provide the program list and flowchart.

Software Issue Report

1 Registration Number
The Software Configuration Management Department specifies a unique and sequential number for the report.
2 Registration Date

The Software Configuration Management Department registers the report date.
3 Problem Discovery Date
The date and time when the problem was found.
4 Activities

The problems found at which stage are divided into unit testing, assembly testing, validation testing, and operation and maintenance.
5 Status

The Dynamic Indication maintained in the software configuration record indicates that the "software Issue Report" is being reviewed to determine what action will be taken; the "software Issue Report" has been handled by a designated person; the modification has been completed and tested, and is being handed over to the main library; the main library has been updated, the Retest edge of the modification in the main library is not completed; the retest is performed, and the problem is reproduced; the retest is performed, the modification is not faulty, and the "Software problem report" is disabled; The Retest is left to be closed later.

6 reporters
Enter the name, address, and phone number of the "software Issue Report" personnel.
7. What are the issues?

Differentiate between program problems, module problems, database problems, and files. It may also be a combination of them.
8 modules/subsystems

The module name that appears. If you do not know which module it is, you can mark the subsystem name and give details as much as possible.
9. Revision version number
The version of the faulty module.
10 tapes

The identifier of the tape that contains the primary library of the problematic module.
11 Database
The identifier of the database used when a problem is found.
File No. 12

There is a wrong file number.
13 Test Cases
The identifier of the test case used when an error is found.
14 hardware

The identifier of the computer system used when an error is found.
15 Problem description/impact

Detailed description of the problem. If possible, indicate the actual problem. The impact of this problem on future testing, interface software, and files should also be given.
16 note
Add additional information.

Software Modification report

1 Registration Number
The number specified in the report is assigned by the Software Configuration Management Department.
2 Registration Date

The Software Configuration Management Department registers the date of the "software modification report.
3 time
Date on which the "software change report" is prepared.
4 reporters

Enter the author of the report.
5. subsystem name
The name of the subsystem affected by the modification.
6 Module name
The name of the modified module.
7
No. of "Software Issue Report"

Number of "Software Issue Report" processed or partially handled by "software change report. If a "software Issue Report" problem is only partially handled, P, such as 1234 P, is attached to the serial number.
8
Modify
Including program modification, file update, database modification, or their combination.
9 modify description

Detailed description of the modification. For file update or database modification, you must also list the identifier of the file update notification or database modification application.
10 approver

The approver signs and officially approves the modification.
11 Statement type

Types of statements involved in program modification, including: Input/Output statements, calculation statements, logical control statements, and data processing statements (such as data transmission and access statements ).
12 program names

The name of the program, file, or database to be modified.
13 old Revision
The current version/revision ID.
14. New Revision

The updated version/revision ID.
15 Databases
If you apply for database modification, the database identifier is provided.
16 database modification report

Database modification application number.
17 files
If you want to modify the file, the file name is provided.
18 File Updates

The ID of the file update notification.
19. Whether the modification has been tested

Specify the tests that have been performed on the modifications, such as the unit, subsystem, assembly, validation, and Operation tests, and indicate whether the tests are successful or not.
20. Does the "software Issue Report" provide an accurate description of the problem?

The answer is "yes" or "no '.
21. Question comment
Accurately describes the problems to be maintained.
22. Problem Source

Specifies where the problem comes from, such as the software requirement specification, design specification, database, and source program.
23 Resources

Estimate the resources required for modification, that is, the total human hours and computer time overhead.