    |
|
Instructions for Completing a Software Change Request (SCR) Form
The SCR documents all requests for changes to the software products. All information about the change should be fully and accurately documented on the SCR. Attach additional paper if necessary. Please type text or check boxes only in the shaded areas. These shaded areas can be accessed by pressing the TAB key, or placing the cursor on the appropriate area and pressing the left mouse button. The shaded areas marked for text will expand or contract to fit the amount of text that is typed. There is no limit (other than size of page) to the number of words that can be typed in the shaded text areas. The items or sections are to be completed by the individuals listed.
Header Section:
[1] SCR Number: Unique SCR identifier.
[2] CCR Number If the SCR results in a Configuration Change Request (CCR), the CCR identifier is recorded here.
[3] STR Number: If the SCR is the result of a Software Trouble report (STR), the STR identifier is recorded here.
[4] CSCI Name: The CSCI to which the change applies.
[5] Requester’s Name: Individual requesting the change and the date the SCR was submitted.
[6] Action Taken: The decision to defer, implement, or not implement the change.
[7] Action Authorized By/Date: The Project Software Manager signs and dates the form.
[8] Person Implementing Change: Individual assigned to implement the change.
[9] Expected Change Completion Date: Date the SCR is expected to be implemented.
[10] SCB Comments: Any SCB member may explain the decision (or register opposition to the decision) and any special concerns surrounding the change.
Section A ---- (Identification of Changes(s)):
This section is to be completed by the Requester
[1] Software Products: Software products (document and code) that may be affected by the change.
[2] Why is this change being requested?: Additions, deletions, or changes to the software products. List all advantages and possible disadvantages for this change, include implications if change is not made. If applicable, list all options for the change and the advantage/disadvantage of each. If this change is a result of an STR, indicate how the STR will be resolved.
[3] Check the category best describing the reason this change is necessary: Although the reason was documented above, categorizing the change allows for tracking project statistics.
Section B ---- (Impact of Changes(s)):
[1] Analyzed By: Individual responsible for doing the analysis and the expected completion date. The individual analyzing the request enters the date the analysis was completed in the Comp Date field.
[2] SCR Criticality: A criticality level (i.e., "1" through "5") is assigned, as determined by the classifications in the following chart:
EXPLANATION OF CRITICALITY CLASSIFICATION |
CRITICALITY LEVEL |
| Software
system will fail without this change Example: Incorrect hardware (h/w) interface requirements |
1 |
| Important
capability will fail without this change Example: Requirements for some off-nominal situations are incomplete or incorrect. |
2 |
| Non-critical
capability will fail without this change. Example: Code produces incorrect error message in off-nominal node. |
3 |
| Capability
will work, but this authorization will improve or add
features to the capability, or a document will be
significantly improved. Example: Instructions in Users Guide are incomplete. |
4 |
| Capability
will work better with this change (e.g. more efficient,
faster) or a document will be clarified. Example: Use of more efficient algorithm in code. |
5 |
[3] Risk of implementation: A Risk of Implementation is assigned (i.e. "1" Very High through "4" Low). The risk level is determined by the following chart:
RISK |
EXAMPLES EXPLANATION |
ASSIGNED NUMBER |
| VERY HIGH | Change
involves more than five Ada compilation units with
complex code, complex timing or numerous interfaces or Change is to baselined interface requirements and designs. |
1 |
| HIGH | Change
involves two to five Ada compilation units with complex
code, complex timing and many interfaces or Change involves modifying baselined designs. |
2 |
| MODERATE | Change
involves more than two Ada compilation units with a
moderate complexity level or 1 unit with high complexity or Change involves modifying architectural design during detailed design. |
3 |
| LOW | Change
involves one or two Ada compilation units with a low
complexity level or Change involves modifying User’s Guide, Software Version Description, etc. |
4 |
[4] Approximate the time in hours required: Estimated time in hours to implement the code changes, additional testing, and updating the documentation. Total number of hours needed to implement the change.
[5] Approximate the cost required: Estimated cost to implement the code changes, additional testing, and updating the documentation. Total cost to implement the change.
Section C ---- Impact to Existing Products
[1] Number of each type of component to be changed: Number of products (e.g., documents, code units) that are impacted by the change.
[2] Description of changes: Describe the change to each software product.
Section D ---- Impact to Reusable Software
[1] Explain any changes that must be made to software being reused from reuse repositories or other projects.
Section E ---- Verification that Change Complete and Implemented
[1] Completed By/Date: Individual implementing the change signs and dates the form when the change is completed.
[2] Verified By/Verification Date: Verifies that the change was correctly implemented.