Requirement Management Procedure

Creation Date:
Created By
Version

Revision History

Release Revision Summary of Changes Revision Number

Author(s)
Date
 TABLE OF CONTENTS

1.0 SCOPE 03

2.0 Life time of the Requirement management procedure 03

3.0 Requirement Definition Phase 03

3.1 Channel for accepting requirements.

3.2 Deliverables

4.0 Requirement Approval Phase 03

4.1 Requirement Acceptance Criteria.

4.2 Requirement analysis

4.3 Requirement Understanding Sign-Off

4.4 Deliverables

5.0 Requirement Commitment Phase 05

5.1 Requirement Acceptance Criteria.

5.2 Impact of requirements

5.3 Changed Commitments

5.4 Deliverables

6.0 Requirement Designing Phase 09

6.1 Deliverables

7.0 Requirement Implementation Phase 09

7.1 Deliverables

8.0 Requirement Verification Phase 09

8.1 Deliverables

9.0 Requirement Change Management

9.1 Change Request Processing and Approval 09

 9.2 Change Control board

9.3 Change Request Management (CRM) Process Activity Description

9.4 Deliverables

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 Owner Stakeholders

status
Definition Define QA Dev, PM, Client
Analysis Approved QA,DEV Client
Project Committed PM PM
Planning &
Proposal
Design Designed Dev Client
Code Implemented Dev QA
Verification Completed QA Dev
Change Control Change QA,PM,DEV QA,PM,DEV
Request

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 Order req01sub01 Create Unique Identification FunctionCustomer Module (Req02)
req01sub02 Create Unique Identification Function
req01sub03 Create Unique Identification Function

3.2. Deliverables

Deliverable Responsibility Location

Traceability matrix with QA Lead[name] VSS [Location]
Defined set of
requirements

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.

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 Phase

QA + Dev + Client
Issues IDEA Application
ISU01 _3455.zip [Location]
ISU02

4.4. Deliverables

Deliverable Responsibility Location

Traceability matrix with QA Lead[name] VSS [Location]
approved set of
requirements
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 plan Team Changed Start Date Changed Sta
Req01 Due to Change request ZYZ 1/1/2005 1/1/2005

5.4. Deliverables

Deliverable Responsibility Location

Traceability matrix with PM [name] VSS [Location]
committed set of
requirements
Project plans from different PM [name] VSS [Location]
stakeholder with
emails

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 Dev Lead [name] VSS [Location]
Designed set of
requirements
UML Artifacts documents Dev Lead VSS [Location]
Detailed Design document Dev Lead VSS [Location]
High Level architecture Dev Lead VSS [Location]
document

Requirement Design stage

Development

Detail design Documents UML Artifacts

Detailed1.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 Dev Lead [name] VSS [Location]
implemented set of
requirements
Code files Dev Lead VSS [Location]

Requirement Implementation Phase

Development
Requirement Implementation Phase
Development 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 Phase

Quality Assurance

Test Cases Details of Addition/Updation Changed By Date Defects

TC01 Test cases updated due to req1 xyz 1/2/2005 101,110
TC01.1,TCO1.2 134,139
TC02.TC02.1

8.1. Deliverables

Deliverable Responsibility Location

Traceability matrix with QA Lead [name] VSS [Location]
verified set of
requirements
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_Desc Impacted Require
Create a New Purchase ch_req01sub01 Create Unique Identification Function Customer Module (
Order ch_req01sub02 Create Unique Identification Function
ch_req01sub03 Create 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 submitSubmitter Proposed

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.

Review CR The function of this activity is to reviewCCB Proposed

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.

Confirm If a Change Request is suspected of being aCCB Delegate Proposed

Duplicate Duplicate or Rejected as an invalid request
or Reject (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.

Update CR If more information is needed (More Info)Submitter Proposed

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
consideration of the new data.

Assign & Once a Change Request is Opened, theProject Manager Approved

Schedule Project Manager will then assign the work
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.

Make The assigned team member performs theAssigned TeamIncorporated

Changes set of activities defined within theMember
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.

Verify After the changes are Resolved by theTester Incorporated

Changes in assigned team member (analyst,
Test Build 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.

Verify Once the resolved changes have beenCCB DelegateValidated

Changes in Verified in a test build of the product, the(System Integrator)
Release Change Request is placed into a release
Build queue to be verified against a release build
of the product, produce release notes, etc.
and Close the Change Request.

9.4. Deliverables
Deliverable Responsibility Location
Traceability matrix with QA Lead [name] VSS [Location]
change request
Change Request form QA Lead VSS [Location]

0. Hierarchy for Configuration items

Maturity Framework