requirement management procedure
TRANSCRIPT
Requirement Management ProcedureCreation Date: Created By Version
Revision History
Release Date
Revision Author(s)
Summary of Changes Revision Number
TABLE OF CONTENTS
1.0 SCOPE 03
2.0 Life time of the Requirement management procedure
03
3.0 Requirement Definition Phase
3.1 Channel for accepting requirements.
3.2 Deliverables
03
4.0 Requirement Approval Phase
4.1 Requirement Acceptance Criteria.
4.2 Requirement analysis
4.3 Requirement Understanding Sign-Off
4.4 Deliverables
03
5.0 Requirement Commitment Phase
5.1 Requirement Acceptance Criteria.
5.2 Impact of requirements
5.3 Changed Commitments
5.4 Deliverables
05
6.0 Requirement Designing Phase
6.1 Deliverables
09
7.0 Requirement Implementation Phase
7.1 Deliverables
09
8.0 Requirement Verification Phase
8.1 Deliverables
09
9.0 Requirement Change Management
9.1 Change Request Processing and Approval
9.2 Change Control board
9.3 Change Request Management (CRM) Process Activity Description
9.4 Deliverables
09
10.0 Hierarchy for configuration items
09
Requirement Management:
1. Scope
Requirements management procedure will help to organize manage and document requirements in an efficient manner so it becomes traceable.
2. Life time of the Requirement management procedure
Requirement Management procedure will be performed throughout the life cycle of SDLC (Software development life cycle).
Requirement Status and Responsibility Matrix
SDLC Phases Requirement status
Owner Stakeholders
Definition Define QA Dev, PM, ClientAnalysis Approved QA,DEV ClientProject Planning & Proposal
Committed PM PM
Design Designed Dev ClientCode Implement
edDev QA
Verification Completed QA DevChange Control
Change Request
QA,PM,DEV
QA,PM,DEV
3. Requirement Definition Phase
3.1. Channel for accepting requirements.
Who will be the requirement provider and who will accept the requirements?
Client Document Requirement Requirement Date
Provider Acceptor
Client Documents Provider [name] Acceptor [name] DD/MM/YY
In requirement definition phase requirements will be distributed into
1) Customer Requirements
2) Technical Requirements
3) Project Requirements
All types of requirements and there dependencies will be maintained in test director tool or in traceability matrix priority for each requirement should be maintained.
In parallel to this phase requirement approval phase will be initiated.
Status against each requirement will be marked as defined.
Requirement Defining Phase
Quality Assurance Req_ID Req_Description Sub_ReqID Sub_Desc Relations(Impact)Req01 Create a New Purchase req01sub01 Create Unique Identification Customer Module
Order req01sub02req01sub03
FunctionCreate Unique Identification FunctionCreate Unique Identification Function
(Req02)
3.2. Deliverables
Deliverable Responsibility Location
Traceability matrix with Defined set of requirements
QA Lead[name] VSS [Location]
4. Requirement Approval Phase
4.1. Requirement Acceptance Criteria
Requirements status will be marked approved only if (70%) of the issues
Related to requirements will be marked resolved in Issue management system and Prove of concept will be accepted by client.
4.2. Requirement analysis
In analysis phase Issue management system should be implemented in test director so the requirements become clear, complete, consistent, testable, and traceable.
f
4.3. Requirement Understanding Sign-Off
IDEA Sign-off and requirement sign-off signature from client is carried out in this phase.
Once the requirement sign-off is done status against each requirement will be marked approved in traceability matrix or TD.
Requirement Approval PhaseQA + Dev + Client Issues IDEA ApplicationISU01ISU02
_3455.zip [Location]
4.4. Deliverables
Deliverable Responsibility Location
Traceability matrix with approved set of requirements
QA Lead[name] VSS [Location]
Issue List log QA Lead VSS [Location]
IDEA Sign Off Docuemnt PM VSS [Location]
Requirement Sign-Off PM VSS [Location]
5. Requirement Commitment Phase
5.1. Commitment Acceptance Criteria
Only those requirements will be committed which are approved in requirement approval phase.
Project plans will be developed against the approved requirements. Committed dates will be stored against requirements in TD or traceability matrix template and status against each requirement will be marked committed
5.2. Impact of requirements
Impact of requirements on related stakeholders can easily be analyzed through traceability matrix or TD.
Requirement Commitment Phase Project Manager Project Start Date Project End Date Teams/2/2004 2/4/2004 Team [name]
5.3. Change Commitment.
In case of any change in project plan changed commitments will be maintained Requirement traceability matrix or TD.
Change Project Plans
Requirement ID Reason for change planTeam Changed Start Date
Changed Start Date
Req01 Due to Change request ZYZ 1/1/2005 1/1/2005
5.4. Deliverables
Deliverable Responsibility Location
Traceability matrix with committed set of requirements
PM [name] VSS [Location]
Project plans from different stakeholder with emails
PM [name] VSS [Location]
6. Requirement Designing Phase
High level architecture document, detail design document, UML artifacts or section of the document is mapped against the requirements in requirement traceability templates or in TD.
Status against each requirement will be marked designed in requirement traceability matrix or TD.
6.1 Deliverables
Deliverable Responsibility Location
Traceability matrix with Designed set of requirements
Dev Lead [name] VSS [Location]
UML Artifacts documents Dev Lead VSS [Location]
Detailed Design document Dev Lead VSS [Location]
High Level architecture document
Dev Lead VSS [Location]
Requirement Design stage Development Detail design Documents UML ArtifactsDetailed1.doc Class1
7. Requirement Implementation Phase
Developed source code files or source code files names will be added against the designed requirements in requirement traceability matrix or in TD. In parallel to this activity verification phase will also initiated.
Status against each requirement will be marked Implemented.
7.1. Deliverables
Deliverable Responsibility Location
Traceability matrix with implemented set of requirements
Dev Lead [name] VSS [Location]
Code files Dev Lead VSS [Location]
Requirement Implementation PhaseDevelopment
Requirement Implementation PhaseDevelopment
Details of Addition/Updation
Changed By Date
Testrun.jsp,validate.js Validate Function changed ZYZ 1/1/2005
8. Requirement Verification Phase
Test matrix, test cases will be developed against requirements and defects will be posted against test cases. Test Cases and defects will be stored in requirement traceability matrix or TD .Verification phase will be started in parallel with implementation phase.
Status against each requirement will be marked verified.
In case of Change requirements status of verified requirements will not be changed in traceability matrix
Requirement Verification PhaseQuality Assurance
Test CasesDetails of Addition/Updation
Changed By Date Defects
TC01TC01.1,TCO1.2TC02.TC02.1
Test cases updated due to req1
xyz 1/2/2005
101,110134,139
8.1. Deliverables
Deliverable Responsibility Location
Traceability matrix with verified set of requirements
QA Lead [name] VSS [Location]
Test Matrix QA Lead VSS [Location]
Test Cases QA Lead VSS [Location]
Defects QA Lead VSS [Location]
9. Requirements Change Management
Change requirements will be maintained separately in traceability matrix.
Impacted requirements ID will be maintained in traceability matrix or TD.
Requirement Defining Phase
Quality Assurance
CReq_Description Sub_ReqID Sub_DescImpacted Requirementns
Create a New Purchase Order
ch_req01sub01ch_req01sub02ch_req01sub03
Create Unique Identification FunctionCreate Unique Identification
Customer Module (Req02)
FunctionCreate Unique Identification Function
9.1. Change Request Processing and Approval
A Change Request, Enhancement Request, or Defect is proposed by a stakeholder through change request form.
The CCB reviews impact on artifacts, costs, and schedule.
The CCB reviews impact analysis, prioritizes changes, and approves or rejects the change request.
Responsibility for implementing changes is assigned to appropriate workers.
Changes are incorporated into a build and tested.
The change requests are validated and closed.
9.2. Change Control Board (CCB)
The CCB is a group composed of various technical and managerial stakeholders. The CCB assesses the impact of changes, determines priorities, and approves changes.
Change Control Manager
The change control manager role oversees the change control process. This role is usually played by a Configuration (or Change) Control Board (CCB) and consists of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role.
The change control manager is also responsible for defining the Change Request Management Process, which is documented in the CM Plan.
Project Manager
Responsible for the configuration management plan, one of the components of the overall software development plane. The project manager is also the recipient and use of the status and measurement reports.
Configuration Manager
Responsible for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager.
Stakeholders
Propose change requests.
9.3. Change Request Management (CRM) Process Activity Descriptions
Activity Description Responsibility
Corresponding Requirement Status
Submit CR
Any stakeholder on the project can submit a Change Request (CR). The Change Request is logged into the Change Request Tracking System and is placed into the CCB Review Queue, by setting the Change Request State to Proposed.
Submitter Proposed
Review CR
The function of this activity is to review Proposed Change Requests. An initial review of the contents of the Change Request is done in the CCB Review meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group.
CCB Proposed
Confirm Duplicate or Reject
If a Change Request is suspected of being a Duplicate or Rejected as an invalid request (e.g., operator error, not reproducible, the way it works, etc.), a delegate of the CCB is assigned to confirm the duplicate or rejected Change Request and to gather more information from the submitter, if necessary.
CCB Delegate Proposed
Update CR
If more information is needed (More Info) to evaluate a Change Request, or if a Change Request is rejected at any point in the process (e.g., confirmed as a Duplicate, Rejected, etc.), the submitter is notified and may update the Change Request with new information. The updated Change Request is then re-proposed to the CCB Review Queue for
Submitter Proposed
consideration of the new data.
Assign & Schedule Work
Once a Change Request is Opened, the Project Manager will then assign the work to the appropriate team member – depending on the type of request (e.g., enhancement request, defect, documentation change, test defect, etc.) – and make any needed updates to the project schedule.
Project Manager
Approved
Make Changes
The assigned team member performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These activities will include all normal review and unit test activities as described within the normal development process. The Change Request will then be marked as Resolved.
Assigned Team Member
Incorporated
Verify Changes in Test Build
After the changes are Resolved by the assigned team member (analyst, developer, tester, tech writer, etc.), the changes are placed into a test queue to be assigned to a tester and Verified in a test build of the product.
Tester Incorporated
Verify Changes in Release Build
Once the resolved changes have been Verified in a test build of the product, the Change Request is placed into a release queue to be verified against a release build of the product, produce release notes, etc. and Close the Change Request.
CCB Delegate (System Integrator)
Validated
9.4. Deliverables
Deliverable Responsibility Location
Traceability matrix with change request
QA Lead [name] VSS [Location]
Change Request form QA Lead VSS [Location]
0. Hierarchy for Configuration items
Maturity Framework
