Requirements Management Plan

1 Requirement Workflows
1.1 Requirements Management Processes
1.1.1 Manage Change (RM01)
1.1.2 Prioritise / Baseline Requirements (RM02)
1.1.3 Manage Configuration / Estimate & Scope Release (RM03)
1.1.4 Compliance / Review Requirements (RM04)
1.1.5 Publish Deliverables (RM05)
1.2 Requirements Definition Processes
1.2.1 Capture / Gather New or Changed Requirements (RD01)
1.2.2 Refine / Elaborate Primary Requirements (RD02)
1.2.3 Structure / Elaborate System Architecture (RD03)
1.2.4 Validate / Elaborate Test Requirements (RD04)
1.2.5 Clarify / Discuss Requirements (RD05)
1.3 Roles and Responsibilities
1.3.1 Business Analyst (BUSA)
1.3.2 Custodian (CUSTO)
1.3.3 Project Manager (PM)
1.3.4 Program Management Office (PMO)
1.3.5 Requirements Working Group (RWG)
1.3.6 Solution Architect (SOLA)
1.3.7 Test Architect (TESA)

1 Requirement Workflows
Requirements
Definition
processes

The Requirements Definition processes are:

Capture / Gather New or Changed Requirements (RD01)

Refine / Elaborate Primary Requirements (RD02)

Structure / Elaborate System Architecture (RD03)

Validate / Elaborate Test Requirements (RD04)

Clarify / Discuss Requirements (RD05)

Requirements definition will be completed in batches based on review and

prioritisation. Prioritised requirements are elaborated iteratively as shown
in Figure 14. Changed requirements are also returned to the prioritise step
so that their clarity and compliance can be re-established.
The status attribute controls the process as shown in Figure 14 and as
described in the following steps.
Requirements
Management
processes

The Requirements Management processes are:

Manage Change (RM01)

Prioritise / Baseline Requirements (RM02)

Manage Configuration / Estimate & Scope Release (RM03)

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 1 of 16

Requirements Management Plan

Compliance / Review Requirements (RM04)

Publish Deliverables (RM05)

Figure 14 Requirements Workflow

Status

Process

<start>

At the end of the Capture process all Requirements are reviewed and Proposed
for elaboration if their clarity and stability meets or exceeds set limits.

Proposed

Requirements with a status of Proposed are prioritised based on project needs,

clarity, and stability. The Prioritise process selects requirements in batches and
these are elaborated or elucidated iteratively through the Refine, Structure, and
Validate processes.
The Structure and Validate processes also carry out design and testing
elaboration for these requirements in the modelling and testing environments.

Approved

At the end of elaboration and modelling, the RWG Approves the requirements
which have sufficient clarity and stability. The batch of requirements is then
reviewed for full compliance.

Compliant

At the end of the Compliance process the reviewed requirements have their
status set to Compliant. If the status is Compliant the requirement is baselined
and assigned to a work package (with the actual attribute).

Incorporated

After requirement implementation has begun its status is changed to

Incorporated. Finally completed and tested requirements have their status
flagged as Verified.

1.1
1.1.1

Requirements Management Processes

Manage Change (RM01)

All changes to Approved requirements are formally controlled through the Manage Change process.
The resulting changes to the scope of a release is formally controlled through the Manage
Configuration process.
A requirement can only be derived and traced from a baselined requirement through a RCN
(Requirement Change Note). A Change Request requirement is created and the RCN number is
stored in the reference attribute.
The Configuration Management Plan describes the management of configuration items including
requirements, and the baselining techniques used for creating and managing requirement baselines.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 2 of 16

Requirements Management Plan

Documents

Change Log (CLOG)

Issue Log (ILOG)

Types

2.2.18Obstacle, Change Request

Attributes

Views

Functional Testability Matrix

impact

Non-Functional Testability Matrix

Functional Traceability Catalogue
Process Flow

Figure 16 Manage Change Process (RM01)

Step

Action

Issue RCN

A stakeholder identifies a need for a new or changed requirement and issues a

RCN (Requirement Change Note) providing the identifier for the requirement
which needs to be changed, and the change needed

Create
Change
Request

The PM registers the RCN in the projects Change Log and creates a new
Change Request requirement. If it is a change the PM links the CR to the existing
requirement which needs to be changed.

Issue Impact
Analysis
Checklist

The RWG acting as the CAB forwards an initial report to the relevant Custodians
and Owners. The report identifies the requirement to be changed, and includes
all other requirements that it traces to or from, including any which may need to
be reviewed and removed as a result.

Assess
Impact

The Custodians assesses the impact on their requirements in terms of the

analysis checklist, and the impact in each workstream.

Produce
Impact
Worksheet

The Custodians produce the Change Impact Worksheet showing their

assessment of impact including details of the requirements affected, and an
assessment of:

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 3 of 16

Requirements Management Plan

Risk to schedule and technology

An assessment of effort needed to effect the change

Review and
Authorise
Change

The RWG will review the worksheet and act as the authority responsible for
authorising the change.

Update
Requirement

Once the requirement has been agreed the Custodian must change the
requirement based on the RWG recommendations, and notify all owners of
affected requirements to make any associated changes.

Update Status

The PM will then update the status attribute for all changed requirements to
Proposed
Changed requriements are returned to the prioritise step so that their clarity and
compliance can be re-established as shown in Figure 14.
This ensurest that all changed requirements are compliant before they can be
merged into a baseline at the end of the workflow through the manage
configuration process.

Notify
Stakeholder

The PM updates the Change Log and notifies the stakeholder of the results of
the review and decision.

impact Attribute
A big part of requirement management involves tracking impact from change requests.
The change impact attribute allows data to be collected though a change management process and
in combination with the status attribute helps the team to answer questions about resource and
schedule impact.
Types

Values

Obstacle

Change Request

List

Standard - routine, low impact changes that do not need formal approval.
These are pre-approved changes that are authorized based on Management
Policies. Certain frequent changes fall into this category and can be preapproved so they can be fulfilled faster.

Minor - minor impact and resource requirements usually approved by a

change manager. These changes have low impact on business and do not
consume a lot of resources.

Major - significant changes which need approval from all members of the
Change Advisory Board and the Change Manager.

risk Attribute
The likelihood of negative impact on schedule or technical qualities if this requirement is
implemented.
For example effort overruns, design flaws, high defect numbers, poor quality and poor performance.
For BUC and project management, categorising schedule risks as high, medium, and low is
sufficient.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 4 of 16

Requirements Management Plan

Types

All System & Environment Types

All Management Types
All Architecture Types
All Testing Types

Values

1.1.2

List

Schedule-High

Schedule-Medium

Schedule-Low

Technology-High

Technology-Medium

Technology-Low

Prioritise / Baseline Requirements (RM02)

The Prioritise process is a pre-requisite to the Refine and Structure processes which elaborate a
subset of the captured and gathered requirements based on their priority. The Prioritise process
assesses the relative priority of each requirement.
It first defines the pre-selection criteria based on project needs. e.g., the process may first pre-select
and assemble a set of Goal requirements and all requirements which trace to them.
A priority attribute is then set in based on the following:

clarity and stability for business requirements during the Refine process.

risk and size assessed for system and architecture requirements during the Design process.

The prioritised requirements are then selected as inputs to the elaboration processes (Refine,
Structure, and Validate) which complete requirements processing for this set of requirements, ahead
of the rest.
Types

All System & Environment Types, All Architecture Types, All Testing Types

Attributes

risk, size

clarity, stability

priority

Views
1.1.3

Prioritisation Attribute Matrix

Manage Configuration / Estimate & Scope Release (RM03)

The Manage Configuration process is used to create a requirements baseline and only applies to
reviewed requirements which have a status of Compliant.
The process packages requirements based on planning needs and assigns an iteration or milestone
number to the actual attribute for the selected requirements to be baselined. The process also
updates the benefit attribute which ranks the importance of this requirement to stakeholders and end
users, and the planned attributes which helps plan scope and development precedence.
The process helps initiates a dialogue with the implementation team and communicates the
customers relative benefit for the requirement, while discussing size (effort) and risk to decide on
the requirements which should be included in the release scope for the baseline.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 5 of 16

Requirements Management Plan

Types

All System & Environment Types, All Architecture Types, All Testing Types

Attributes

clarity, stability

risk, size, benefit

actual, planned

1.1.4

Compliance / Review Requirements (RM04)

The Compliance process checks for full compliance with the following:

Architecture traceability

Functional and non-functional Testability

Standards compliance

Contractual compliance with deliverable documents

The Compliance process is initiated by the RWG and used to ensure that Approved requirements for
Architecture, Testing, and Contractual deliverable documents, are compliant and ready for
Incorporation into a baseline. After completion all compliant requirements can be Incorporated
through the Manage Configuration or the Publish process.
Documents

Requirement Matrix (REQM) (update)

FM Application Technical Assessment Criteria (ATAC) (update)
FM Application Technical Assessment Report (ATAR) (update)

Types

All System & Environment Types, All Architecture Types, All Testing Types

Attributes

custodian

status

Views

Standards Compliance Matrix

Requirement Matrix (REQM) (deliverable)
Architecture Principles Traceability Catalogue
Functional Testability Matrix
Non-Functional Testability Matrix

Process Flow

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 6 of 16

Requirements Management Plan

Figure 17 Compliance Process (RM04)

Step

Action

Convene
Review

The process applies to requirements which have been Approved and not yet
Incorporated. The process is executed after the Validate process has been
completed for these requirements, at which point all elaboration should have
been completed for Business, Architecture and Testing requirements.
The RWG is responsible for convening requirements review workshops and
maintaining information about requirements compliance.

Initiate
Architecture
Review

The SOLA is similarly responsible for exposing requirements which need

elicitation and refinement during architecture reviews, and for ensuring full
compliance (all higher-level requirements are fully addressed by one or more
lower-level requirements).

Review
Principles
Traceability

The SOLA must ensure that technology principles and design decisions are
traceable to the design and architecture model elements.

Review
Functional
Traceability

The SOLA must also ensure that all functional requirements have been specified
in the design. Every approved Goal must trace to one or more BUC or to one or
more Infrastructure requirements.

Review
Functional
Testability

The TESA is responsible for ensuring that all functional requirements have a
corresponding test artefact. The TESA review should check that:

Review NonFunctional

Test Cases exist for each BUC, Functional requirements (BUC,

Infrastructure), including non-functional tests for their associated
Supplementary requirement as specified by the qos attribute.

All test cases trace to at least one Functional or non-functional requirement.

The TESA must also ensure that non-functional requirements are verifiable:

Test Cases must exist for all non-functional Supplementary or Expectation

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 7 of 16

Requirements Management Plan

Testability

requirements, as specified by their qos attribute.

Assess
Standards
Compliance

All test cases trace to at least one Functional or non-functional requirement.

The SOLA and TESA must both ensure that every Standard or Term requirement
has been met and verified by one or more Architecture and Testing requirement.
This review must ensure that:

System design is compliant with standards that have been adopted by the
ICT program,

Standards compliance is testable.

Assess Type
Compliance

The RWG calls on requirement custodians and workstream leads to show that
each requirement type is fully compliant. In addition the RCI (Requirement Clarity
Index) for these requirements has to be within set limits.

Nominate
Owner

The custodian is the default owner for all requirements of any particular type.
However the custodian may nominate an owner to address Compliance gaps
and in specific requirements during the governance process

Review
Contractual
Compliance

The RWG must ensure that document deliverables are ready for compliance with
contractual requirements for milestone deliverables.

Update Status

1.1.5

Artefact requirements are fully compliant with their linked Contractual

requirements

All Artefact requirements are linked to external documents and have a status
of Incorporated or Verified

The status is set after requirements compliance is reviewed by the working

group. The process sets the status of all requirements which pass review to
Compliant.

Publish Deliverables (RM05)

The Publish process gathers Artefact and Contractual requirements which have a status of
Incorporated. Each Contractual requirement for a deliverable document is linked to a master
document, and each of its traced Artefact requirements is linked to a catalogue, matrix or diagrams in
a sub-document. The Publish process assembles the master and sub-documents and creates a
deliverable document which can be reviewed and approved through the PMO content publishing
workflow.
Types

ABB, Artefact, Contractual

Attributes

doctype, phase,

status

1.2

Requirements Definition Processes

Requirements
Definition
processes

Requirements

The Requirements Definition processes are:

Capture / Gather New or Changed Requirements (RD01)

Refine / Elaborate Primary Requirements (RD02)

Structure / Elaborate System Architecture (RD03)

Validate / Elaborate Test Requirements (RD04)

Clarify / Discuss Requirements (RD05)

The Requirements Management processes are:

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 8 of 16

Requirements Management Plan

Management
processes

1.2.1

Manage Change (RM01)

Prioritise / Baseline Requirements (RM02)

Manage Configuration / Estimate & Scope Release (RM03)

Compliance / Review Requirements (RM04)

Publish Deliverables (RM05)

Capture / Gather New or Changed Requirements (RD01)

The Capture process imports requirements from primary requirement documents and sets up the toplevel relationship structure between requirements in the Source and Motivation packages.
The process creates and links Stakeholder requirements to the key questions, issues, or concerns
that must be addressed by the requirements framework. The Capture process also adds Contractual
requirements and the document deliverables required for the milestones.
In all steps which create and type new requirements, the BUSA must also set attributes for the
captured requirements as follows

By default the owner is the custodian.

Derived requirements must have their reference attribute set (as defined in the attributes
specification) to distinguish original requirements from derived requirements.

The organisation attribute for Stakeholder requirements

Documents

Principal Facilities Reference Guide (PFRG)

Principal Service Specification (PSS)
ICT Service Specification v2.0 (ICTSS)
ICT Standards and Requirements Framework (ICTSRF)
ICT Services Subcontract (SUBC)

Types

Attributes

Views

Document, Stakeholder = organisation, Concern, Standard or Term

Business Driver, Business Principle

Contractual, Artefact

identifier, created, modified, owner, reference

organisation

Stakeholder Map Matrix

Process Flow

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 9 of 16

Requirements Management Plan

Figure 15 Capture Process (RD01)

Step

Action

Setup
Framework

As part of the process the RWG first sets up the framework for requirement types
which are to be captured. This includes setting up:

A Custodian for each requirement type

Defines acceptability levels for requirements clarity and stability

Sets review checkpoints for architecture, testing and deliverable

requirements.

The requirements clarity thresholds determine when the Capture process can
conclude, based on reaching these levels.
Import
Primary
Requirements

The PMO requirements engineer imports requirements from primary requirement

documents. into the IRQA repository

Define
Stakeholders

The BUSA creates and links Stakeholder requirements and Documents

the key questions, issues, or concerns that must be addressed by the
requirements framework.
The process also sets the organisation attribute for Stakeholder requirements

Capture
Concerns &
Standards

The BUSA sets up the top-level relationship structure between requirements in

the Source and Motivation packages.

Create Views

The PMO creates the necessary requirement views in IRQA based on the initial
structure and attributes created by the BUSA during the capture process. This
step creates the Stakeholder Map Matrix view.

Capture
Drivers &
Principles

The BUSA types captured requirements and decomposes or derives additional

new requirements as needed to clarify Concern requirements with Business
Driver and Business Principle requirements.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 10 of 16

Requirements Management Plan

Review Clarity

The requirements clarity thresholds set earlier by the RWG determines when the
Capture process can conclude, based on reaching these levels. If the clarity
is too low the process must iterate starting with the Drivers and Principles
step, and decompose or refine requirements as needed to improve clarity.

Import
Contractual

The PMO imports Contractual requirements from the Subcontract documents into
the IRQA repository.

Capture
Deliverables
& Artefacts

The BUSA adds Contractual requirements and defines the document

deliverables required for each milestone.

Review clarity

The RWG reviews clarity and coverage and proposes the requirements for
elaboration (status is set to Proposed)

Sync
Environments

The PMO requirements team collaborates with the SOLA and TESA to baseline
and synchronise requirements with the modelling and testing environments.

1.2.2

Refine / Elaborate Primary Requirements (RD02)

The Refine process decomposes prioritised requirements for business drivers and principles, and
creates new requirements which add clarity to the previously captured primary requirements.
It also imports requirements from the Service Line Process Descriptions (SLPD) document, mostly as
Goal and BUC requirements; and it adds for Goal requirements from the Volumetrics (VOLM)
document and sets kpi attributes for these.
The process also decomposes the Contractual requirements created during the Capture process,
and creates Artefact requirements for aligning bottom-up with Goal architecture requirements which
will be created next during the Structure process.
Documents

Service Line Process Descriptions (SLPD)

Volumetrics (VOLM)
Project Glossary (PGLOS) (update)

Types

Attributes

Views
1.2.3

Business Driver, Business Principle

Goal = kpi, BUC

clarity, stability

kpi

Stakeholder Map Matrix

Structure / Elaborate System Architecture (RD03)

As with the refine process, the Structure process also works iteratively on prioritised requirements
and elaborates these into system architecture requirements.
The Structure process imports application capability requirements from stakeholder documents and
abstracts up from these low-level requirements, and links these to previously refined BUC and Goal
requirements. The SOLA creates multiple Integration, Expectation, Infrastructure, Supplementary
requirements for each Goal and BUC requirement, and sets qos attribute for each Supplementary
requirement. Business Drivers and Business Principles are elaborated with Technology Principles
and Design Decisions.
After elaborating the System architecture requirements the PMO synchronises the requirements with
the modelling environment, and the SOLA elaborates the system structure in the modelling
environment with design elements an ABB. Similarly the BUSA and SOLA create documents and
elaborate Artefact requirements with catalogues, matrices and diagrams in the document processing

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 11 of 16

Requirements Management Plan

environment.
Documents

Types

Attributes

Views

Application Capabilities (ACAP)

Application Capability Matrix (ACM)

Volumetrics (VOLM) (update)

FM Application Technical Assessment Criteria (ATAC) (update)

FM Application Technical Assessment Report (ATAR) (update)

Goal, BUC

Application Capability, Integration

Expectation, Infrastructure, Supplementary = qos

Technology Principle, Design Decision

capability, continuum, phase, doctype, stdtype

kpi, qos

Functional Traceability Catalogue

Architecture Principles Traceability Catalogue

1.2.4

Validate / Elaborate Test Requirements (RD04)

The Validate process elaborates business and system requirements with Testing requirements and
creates Scenario, Test Case and Validation requirements. After these are elaborated the PMO
synchronises requirements with the testing environment, and the TESA extends the testing
requirements with test plans and scripts, in accordance with the testing requirements and the kpi,
qos and validatemethod attributes.
Types
Attributes

Views

kpi, qos

validatemethod

Functional Testability Matrix

Non-Functional Testability Matrix

1.2.5

Clarify / Discuss Requirements (RD05)

The Clarify process provides a controlled flow for capturing additional detail into existing
requirements.
A Clarification starts as an assumption or issue relating to a requirement, and once qualified and
agreed with the owner, it will be recorded as additional information in the requirement or in a new
linked requirement. The initial assumption is an unqualified statement about an existing requirement.
It might add detail or interpretation, or imply a completely new requirement.
The Clarify process can only apply to Requirements with a status of Proposed (or later).
Documents

Change Log (CLOG) (update)

Types

Clarification = querytype, All Types = owner

Attributes

1.3

querytype, owner

Roles and Responsibilities

Process

The main roles and their associations to requirements processes are

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 12 of 16

Requirements Management Plan

overview

shown in Figure 13. These roles are the primary ones associated with
each process, and generally are the ones which initiate and control the
outcome of the process.
Each process flow is described in more detail in the following sections so
that everyone understands which responsibilities are unique and which are
shared between two or more roles.

Figure 13 Process and Role overview

Roles

The requirement processes are executed by the following roles.

These are project management and engineering roles all of which have a
stake in requirements definition and management, and system delivery.

1.3.1

BUSA Business Analyst

CUSTO Custodian (for each Requirement Type)

PM Project Manager

PMO Program Management Office

RWG Requirements Working Group

SOLA Solution Architect

TESA Test Architect

Business Analyst (BUSA)

The BUSA is primarily responsible for capturing baseline requirements and structuring refined /
decomposed requirements in accordance with the plan.
The BUSA is also responsible overall for the capture process between documents and the IRQA
environment, and between IRQA and the modelling environment.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 13 of 16

Requirements Management Plan

Responsibilities
Identify project stakeholder roles. Document user class characteristics and decompose
stakeholder roles from user classes. Define traceability between stakeholder requirements, source
documents, and concern areas.
Elicit requirements using interviews, requirements workshops, document analysis, application and
product analysis, service task and workflow analysis, and architecture viewpoints.
Write requirements specifications according to standard templates, simply, clearly, unambiguously,
and concisely.
Decompose high-level business requirements into functional and quality requirements.
Lead requirements reviews and validation, ensuring that requirements are complete, consistent,
concise, traceable, feasible, unambiguous, and verifiable, and that they conform to standards.
1.3.2

Custodian (CUSTO)

The custodian is responsible for ensuring that all requirements of a particular type are fully compliant,
and that their requirement clarity index is within acceptable limits.
Responsibilities
Assign an owner for specific requirements during governance processes.
Ensure that every aspect of higher-level requirements are fully addressed by lower-level
requirements which are linked and owned by the custodian.
Where high level requirements are shared and fulfilled by BT and by another vendor, ensure that
links are created to third party requirements so that full compliance is achieved.
Track status and impact of change requests for the requirements which are owned by the
custodian.
1.3.3

Project Manager (PM)

Manages release deliverables such as baselines, plans, scope statements, milestone definitions etc.
Responsibilities
Monitor and facilitate delivery of requirement baselines for each release via definition and
management processes.
Allocate requirement to a baseline or release during the Prioritise and Configuration processes.
Discuss impact on other requirements during Change process and commit to development.
Monitor and report progress by requirement status within each work package.
1.3.4

Program Management Office (PMO)

Overall responsibility for all requirements management processes, and collaboration.

Responsibilities
Responsible for all changes to requirements which may directly or indirectly affect scope.
Produce structured project reports based on requirement views and metrics.
Plan and schedule requirement reviews for Architecture compliance and Testing compliance.
Monitor and report on requirements clarity progress and regression.
Issued by: <name/organisation>
Version no:
Date: 12 June 2011

Page 14 of 16

Requirements Management Plan

1.3.5

Requirements Working Group (RWG)

The RWG consists of leads or their nominees from each workstream, and the project manager.
The group functions as the requirements Change Advisory Board (CAB) during the Manage Change
process, The RWG authorises and reports on Changes in accordance with the Change Management
responsibilities specified in the contract, with respect to:

Agreeing the initiation of impact assessment work on an identified Change;

Review of the Change log; and

Authorising Change implementation impact assessment completion.

The RWG arbitrates during requirement reviews and its members are collectively responsible for
fostering collaboration and discussion relating to requirements, among project participants and
stakeholders.
Responsibilities
CAB Change Advisory Board
Effective communication and management of all changes owned by PMO
Convene requirements review workshops and maintain information about requirements
compliance.
Help improve collaboration and communication relating to requirements.
Monitor and report on Clarify process metrics.
The working group is responsible for reviewing and updating the requirements management plan.
1.3.6

Solution Architect (SOLA)

The SOLA is primarily responsible for elaborating the system architecture requirements and for
extending requirements into design, including maintaining synchronisation between design and
requirements environments. The SOLA role covers application integration and infrastructure
concerns.
Responsibilities
Evaluate the information gathered from requirement sources, reconcile conflicts, decompose highlevel information into Goal requirements and multiple solution requirements for each Goal;
decompose Business Principles into Technology principles and Design Decisions
Abstract up from low-level application capabilities and service line specifications and link these to
a more general understanding in the captured BUC and Goal requirements.
Define requirements for catalogues, matrices, and diagrams to augment textual representations in
artefacts, in compliance with contractual requirements for deliverable documents; and system
requirements.
Validate requirements obtained via Requirement Views and expose areas for elicitation and
refinement during architecture reviews to ensure full compliance (all higher-level requirements
must be fully addressed by one or more lower-level system architecture requirement).

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 15 of 16

Requirements Management Plan

1.3.7

Test Architect (TESA)

The Test Architect is reasonable for ensuring that test plans are fully compliant with testing
requirements; and ensuring that defects are tracked and monitored in the requirements management
environment from defect identification to resolution.
Responsibilities
Ensure that testing requirements and test plan coverage are adequate to ensure that the
requirements baseline is fit for deployment.
Specify how test requirements will be validated during the Validate process.
Manage issues detected within development, deployment, testing and integration and participate
in the Manage Change process.
Ensure that test plans are compliant with kpi and qos specifications for linked requirements.
Monitor requirements for tested defects and ensure that the testing environment is kept
synchronised with new and changed requirements and attributes.
Incorporate requirement views and metrics into the defect management and reporting process to
track and monitor defects.

Issued by: <name/organisation>

Version no:
Date: 12 June 2011

Page 16 of 16