FAQs about cmme (2)

Question: What will happen after the demand review is completed?

Answer: The reviewed requirement document (generally referred to as the Requirement Specification) serves as a baseline for engineering and management ).

1. After the requirements specification is approved, the requirement tracking owner should create a [requirement tracking matrix] (RTM ), as an independent document, RTM is used to track and maintain whether customers' requirements are correctly implemented in the design, coding, testing, and other stages. Each requirement is tracked throughout the lifecycle until it is completed.

2. After the requirement specification is reviewed, modified, and verified, the configuration item should be included in the baseline database. This process is called baseline.
After the CMO is baseline-based and included in the baseline database, the "configuration status report" should be released to enable all affected groups or individuals to receive baseline-based requirements.

3. When the demand specification after baseline is changed, CMO needs to re-release the "configuration status report" to assign the change description and post-change requirements to all affected groups and individuals.

 

Question: How to Use【RTM requirement tracking matrix]Tracking requirements?

Answer: RTM -- requirement track matrix, which is used to track the ing process from requirement to design, design to coding, coding to testing. The project team can crop the template format to meet the project requirements.

The simplest way to update a matrix is to update it after the review of the relevant phase.

Requirement tracking matrixCheck and steps to be followed:
1. Check the number of requirements in the browser matrix and the requirements in the requirements document to ensure that all requirements are listed in the matrix. By sorting the requirement numbers, and then checking whether the number of requirements is consistent with the number in the requirement document, you can easily achieve this goal.

2. To ensure that all programs listed in the matrix are necessary in the final software and there is no redundant code, each program, class, and other units must be specified in the matrix.

3. Check the implementation of the requirement by ensuring that there are no blank columns for functional requirements. For other requirements, if the design and program domain are blank, you need to carefully check and verify whether these requirements have a direct impact on the program.

4. Test cases should be designed for each performance requirement. Using matrices, you can easily check whether the test cases are suitable for this performance requirement.

5. Integration and system test cases can be checked with the matrix to ensure that all requirements are included in the system test cases.

 

Question: How to control demand changes?

Answer: 1. When a baseline requirement change is made, the change requestor fills in the demand change application form to evaluate the workload and related modules and then submits the application to CMO for a change;

2. The project manager organizes sccb to review the change request. If the review is approved, the corresponding requirement specifications, related design or coding products will be modified;

3. The modified work products resubmit the CMO update baseline, and the CMO releases the "configuration status report" to ensure that the latest demand change information and related work products are released to the affected personnel.

 

Question: What data are measured in demand management?

Answer:
1. RTM statistics on the number of implementations required, number of unimplemented, and percentage of implementations;

2. Workload spent in the demand management stage;

3. Number of defects and defect density identified during requirement document review;

4. defect density = number of defects found in the review; Total number of pages in the requirement document

5. Total number of change requests processed.

6. rework workload for changes;

 

Question: Why is it peer review?

Answer: Peer Review

Peer reviews aim to detect defects in work products as early as possible and remove them.

At the same time, it can improve the understanding of work products, in order to obtain high-quality products.

Reduce development costs and improve system quality.

 

Question: Which work products in the project need to be reviewed by peers?

Answer: The project has the following related objects and needs to be reviewed by peers:

1. pre-sales: contract, project proposal, and bidding documents;

2. development/implementation: various plans, Requirement Specifications, specifications, design specifications, codes, test cases, test reports, user documents, etc;

3. After-sales: upgrade requirements, design modifications, code modifications, test cases, Version Upgrade instructions, etc;

The work products to be reviewed by peers and the peer review methods adopted in the project are formulated 《Pdsp-software process defined by the ProjectHour

Make a choice. Note: pdsp is started only after the pre-sales Implementation of the project is completed. Therefore, pdsp only defines the stage of "development/implementation ".

Some things need peer review. If the project team adopts an ossp peer review or a four-eye review, please clarify in pdsp

Chu, which is approved by SEPG. If appropriate, the review method adopted by the project team will be included in ossp for further promotion within the company.