The first step in creating a MR is to write your requirements down along with a description of the problem. The best place to start is with the MrTemplate. Copy the contents of the MrTemplate into a new Software web wiki page. The format of the MR wiki name is ModificationRequestNCXYY where N is a sequential number (i.e. whatever number is not already claimed), X is the cycle in which the MR is written, and YY is the two-digit year in which the MR is written. Iterate with your assigned software team lead (and other interested parties) until you create a MR which meets everyone's needs.

The first step in creating a MR is to write your requirements down along with a description of the problem. The best place to start is with the MrTemplate. Copy the contents of the MrTemplate into a new Software web wiki page. The format of the MR wiki name is ModificationRequestNCXYY where N is a sequential number (i.e. whatever number is not already claimed), X is the cycle in which the MR is written, and YY is the two-digit year in which the MR is written. The current software cycle can be determined by visiting the Software Wiki Home Page and looking at the Cycle Planning box at the far right-hand side of the screen; there is also a search utility in the Cycle Planning box which lets you determine the next available sequential number. Iterate with your assigned software team lead (and other interested parties) until you create a MR which meets everyone's needs.

See SponsorResponsibilities?.

A sponsor is the person responsible for ensuring that a request that results in a modification to a software product meets the agreed upon requirements.

As part of the MR writing process, the sponsor will be ApprovingMRs.

The first step in creating a MR is to write your requirements down along with a description of the problem. The best place to start is with the MrTemplate. Copy the contents of the MrTemplate into a new Software web wiki page. The format of the MR wiki name is ModificationRequestNCXYY where N is a sequential number (i.e. whatever number is not already claimed), X is the cycle in which the MR is written, and YY is the two-digit year in which the MR is written. Iterate with your assigned software team lead (and other interested parties) until you create a MR which meets everyone's needs.

The first step in creating a MR is to write your requirements down along with a description of the problem. The best place to start is with the MrTemplate. Copy the contents of the MrTemplate into a new Software web wiki page. The format of the MR wiki name is ModificationRequestNCXYY where N is a sequential number (i.e. whatever number is not already claimed), X is the cycle in which the MR is written, and YY is the two-digit year in which the MR is written. Iterate with your assigned software team lead (and other interested parties) until you create a MR which meets everyone's needs.

Modification Requests should be linked to the appropriate item on the Plan of Record. If the request is too complex, break the request into a series of smaller modification requests. This might also require schedule alteration achieved through arbitration with the sponsor. Ask the sponsor to review the Modification Request to the sponsor for approval; this is the first of two required signatures from the sponsor. In order for a sponsor to approve the modification request, he/she must agree that the modification request fully contains the sponsor's original request and if the software engineer delivers exactly what is described in the modification request he/she will be happy. Iterate with the sponsor if the modification request as drafted is not acceptable. Once the modification request is signed, design/implementation/unit testing may begin.

Modification Requests should be linked to the appropriate item on the Plan of Record. If the request is too complex, break the request into a series of smaller modification requests. This might also require schedule alteration achieved through arbitration with the sponsor. Ask the sponsor to review the Modification Request for approval; this is the first of two required signatures from the sponsor. In order for a sponsor to approve the modification request, he/she must agree that the modification request fully contains the sponsor's original request and if the software engineer delivers exactly what is described in the modification request he/she will be happy. Iterate with the sponsor if the modification request as drafted is not acceptable. Once the modification request is signed, design/implementation/unit testing may begin.

%META:TOPICINFO{author="AmyShelton" date="1144963980" format="1.0" version="1.1"}%

Modification Request (MR)

• What is a Modification Request (MR)?
• What is a sponsor?
• What is a checker?
• Template

What is a Modification Request (MR)?

A modification request, or MR, is a detailed description of what is to be modified or added to a particular software system, including a restatement of the requirement (preferably in four sentences or less), a discussion of the solution approach, and an outline of what behavior we need to see in the modified system for our work to be considered a success. The MR enables three things: early agreement, unit and integration testing, and user acceptance testing.

Each request on a Plan of Record which requires the modification of an existing software component or the addition of a new software component must be further refined and documented via a Modification Request. Not all requests require documented Modification Requests and follow the process that continues below (e.g. creation of a project charter). These requests must be handled individually and follow a sponsor/developer process relevant to the given request; all documentation regarding requests that do not produce written Modification Requests should be documented on the wiki and linked to the Plan of Record.

Modification Requests should be linked to the appropriate item on the Plan of Record. If the request is too complex, break the request into a series of smaller modification requests. This might also require schedule alteration achieved through arbitration with the sponsor. Ask the sponsor to review the Modification Request to the sponsor for approval; this is the first of two required signatures from the sponsor. In order for a sponsor to approve the modification request, he/she must agree that the modification request fully contains the sponsor's original request and if the software engineer delivers exactly what is described in the modification request he/she will be happy. Iterate with the sponsor if the modification request as drafted is not acceptable. Once the modification request is signed, design/implementation/unit testing may begin.

The first step in creating a MR is to write your requirements down along with a description of the problem. The best place to start is with the MrTemplate. Copy the contents of the MrTemplate into a new Software web wiki page. The format of the MR wiki name is ModificationRequestNCXYY where N is a sequential number (i.e. whatever number is not already claimed), X is the cycle in which the MR is written, and YY is the two-digit year in which the MR is written. Iterate with your assigned software team lead (and other interested parties) until you create a MR which meets everyone's needs.

What is a sponsor?

See SponsorResponsibilities?.

What is a checker?

A checker is another member of the Software Development Division who reads the written MR and confirms that it is indeed complete and ready for review by the sponsor. Things to look for under deployment include the needs of CLEO, FITS consumers (SDFITS, gfm and the filler), and the config tool.

Template

A Modification Request template is available at MrTemplate.