Requirement Management Workflows

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

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.

Version no:
Date: 12 June 2011
Page 2 of 16

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:

Version no:
Date: 12 June 2011
Page 3 of 16
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.

Version no:
Date: 12 June 2011
Page 4 of 16

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

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.

Version no:
Date: 12 June 2011
Page 5 of 16

Types
Attributes
clarity, stability
risk, size, benefit
actual, planned
1.1.4
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
Attributes
custodian
status
Views
Standards Compliance Matrix

Requirement Matrix (REQM) (deliverable)
Architecture Principles Traceability Catalogue
Process Flow

Version no:
Date: 12 June 2011
Page 6 of 16
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

Version no:
Date: 12 June 2011
Page 7 of 16

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.
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:
The Requirements Management processes are:

Version no:
Date: 12 June 2011
Page 8 of 16

Management
processes
1.2.1
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

Version no:
Date: 12 June 2011
Page 9 of 16
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.

Version no:
Date: 12 June 2011
Page 10 of 16

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

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

Version no:
Date: 12 June 2011
Page 11 of 16

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

1.2.5
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

Version no:
Date: 12 June 2011
Page 12 of 16

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.

Version no:
Date: 12 June 2011
Page 13 of 16

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.
Version no:
Date: 12 June 2011
Page 14 of 16

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).

Version no:
Date: 12 June 2011
Page 15 of 16

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.

Version no:
Date: 12 June 2011
Page 16 of 16

Requirement Management Workflows

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirement Management Workflows

Uploaded by

Copyright:

Available Formats

Requirements Management Plan

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

The Requirements Management processes are:

Manage Change (RM01)

Prioritise / Baseline Requirements (RM02)

Manage Configuration / Estimate & Scope Release (RM03)

Issued by: <name/organisation>

Requirements Management Plan

Compliance / Review Requirements (RM04)

Publish Deliverables (RM05)

Figure 14 Requirements Workflow

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

After requirement implementation has begun its status is changed to

Requirements Management Processes

Issued by: <name/organisation>

Requirements Management Plan

Change Log (CLOG)

2.2.18Obstacle, Change Request

Functional Testability Matrix

Non-Functional Testability Matrix

Figure 16 Manage Change Process (RM01)

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

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

The Custodians produce the Change Impact Worksheet showing their

Issued by: <name/organisation>

Requirements Management Plan

Risk to schedule and technology

An assessment of effort needed to effect the change

Minor - minor impact and resource requirements usually approved by a

Issued by: <name/organisation>

Requirements Management Plan

All System & Environment Types

Prioritise / Baseline Requirements (RM02)

Prioritisation Attribute Matrix

Issued by: <name/organisation>

Requirements Management Plan

risk, size, benefit

Compliance / Review Requirements (RM04)

Functional and non-functional Testability

Contractual compliance with deliverable documents

Requirement Matrix (REQM) (update)

Standards Compliance Matrix

Issued by: <name/organisation>

Requirements Management Plan

Figure 17 Compliance Process (RM04)

The SOLA is similarly responsible for exposing requirements which need

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

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

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

Issued by: <name/organisation>

Requirements Management Plan

requirements, as specified by their qos attribute.

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

Standards compliance is testable.

Artefact requirements are fully compliant with their linked Contractual

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

Publish Deliverables (RM05)

ABB, Artefact, Contractual