Requirements Management Plan

Internal

Requirements Management Plan1Requirement Workflows11.1Requirements Management Processes21.1.1Manage Change (RM01)21.1.2Prioritise / Baseline Requirements (RM02)41.1.3Manage Configuration / Estimate & Scope Release (RM03)51.1.4Compliance / Review Requirements (RM04)51.1.5Publish Deliverables (RM05)71.2Requirements Definition Processes71.2.1Capture / Gather New or Changed Requirements (RD01)81.2.2Refine / Elaborate Primary Requirements (RD02)101.2.3Structure / Elaborate System Architecture (RD03)101.2.4Validate / Elaborate Test Requirements (RD04)111.2.5Clarify / Discuss Requirements (RD05)111.3Roles and Responsibilities111.3.1Business Analyst (BUSA)121.3.2Custodian (CUSTO)131.3.3Project Manager (PM)131.3.4Program Management Office (PMO)131.3.5Requirements Working Group (RWG)131.3.6Solution Architect (SOLA)141.3.7Test Architect (TESA)14Requirement WorkflowsRequirements Definition processesThe 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 processesThe Requirements Management processes are:Manage Change (RM01)Prioritise / Baseline Requirements (RM02)Manage Configuration / Estimate & Scope Release (RM03)Compliance / Review Requirements (RM04)Publish Deliverables (RM05)

Figure 14 Requirements WorkflowStatusProcess

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.

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

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

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

IncorporatedAfter requirement implementation has begun its status is changed to Incorporated. Finally completed and tested requirements have their status flagged as Verified.

Requirements Management ProcessesManage 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.

DocumentsChange Log (CLOG)Issue Log (ILOG)

Types 2.2.18Obstacle, Change Request

Attributesimpact

ViewsFunctional Testability MatrixNon-Functional Testability MatrixFunctional Traceability Catalogue

Process Flow

Figure 16 Manage Change Process (RM01)

StepAction

Issue RCNA 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 RequestThe 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 ChecklistThe 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 ImpactThe Custodians assesses the impact on their requirements in terms of the analysis checklist, and the impact in each workstream.

Produce Impact WorksheetThe Custodians produce the Change Impact Worksheet showing their assessment of impact including details of the requirements affected, and an assessment of:Risk to schedule and technologyAn assessment of effort needed to effect the change

Review and Authorise ChangeThe RWG will review the worksheet and act as the authority responsible for authorising the change.

Update RequirementOnce 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 StatusThe PM will then update the status attribute for all changed requirements to ProposedChanged 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 StakeholderThe 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 ObstacleChange Request

ValuesListStandard - 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 pre-approved 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.Types All System & Environment TypesAll Management TypesAll Architecture TypesAll Testing Types

ValuesListSchedule-HighSchedule-MediumSchedule-LowTechnology-HighTechnology-MediumTechnology-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

Attributesrisk, size clarity, stabilitypriority

ViewsPrioritisation 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.Types All System & Environment Types, All Architecture Types, All Testing Types

Attributesclarity, stabilityrisk, size, benefitactual, planned

Compliance / Review Requirements (RM04)

The Compliance process checks for full compliance with the following:Architecture traceabilityFunctional and non-functional TestabilityStandards complianceContractual compliance with deliverable documentsThe 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. DocumentsRequirement 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

Attributescustodianstatus

ViewsStandards Compliance MatrixRequirement Matrix (REQM) (deliverable)Architecture Principles Traceability CatalogueFunctional Testability MatrixNon-Functional Testability Matrix

Process Flow

Figure 17 Compliance Process (RM04)

StepAction

Convene ReviewThe 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 workshopsand maintaining information about requirements compliance.

Initiate Architecture ReviewThe 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 TraceabilityThe SOLA must ensure that technology principles and design decisions are traceable to the design and architecture model elements.

Review Functional TraceabilityThe 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 TestabilityThe TESA is responsible for ensuring that all functional requirements have a corresponding test artefact. The TESA review should check that: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.

Review Non-Functional TestabilityThe TESA must also ensure that non-functional requirements are verifiable:Test Cases must exist for all non-functional Supplementary or Expectation requirements, as specified by their qos attribute.All test cases trace to at least one Functional or non-functional requirement.

Assess Standards ComplianceThe 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 ComplianceThe 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 OwnerThe 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 ComplianceThe RWG must ensure that document deliverables are ready for compliance with contractual requirements for milestone deliverables. Artefact requirements are fully compliant with their linked Contractual requirementsAll Artefact requirements are linked to external documents and have a status of Incorporated or Verified

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

Attributesdoctype, phase, status

Requirements Definition ProcessesRequirements Definition processesThe 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 Management processesThe Requirements Management processes are: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 top-level 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 DocumentsPrincipal 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 Document, Stakeholder = organisation, Concern, Standard or TermBusiness Driver, Business PrincipleContractual, Artefact

Attributesidentifier, created, modified, owner, referenceorganisation

ViewsStakeholder Map Matrix

Process Flow

Figure 15 Capture Process (RD01)

StepAction

Setup FrameworkAs 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 typeDefines acceptability levels for requirements clarity and stabilitySets 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 RequirementsThe PMO requirements engineer imports requirements from primary requirement documents. into the IRQA repository

Define StakeholdersThe BUSA creates and links Stakeholder requirements and Documentsthe 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 & StandardsThe BUSA sets up the top-level relationship structure between requirements in the Source and Motivation packages.

Create ViewsThe 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 & PrinciplesThe BUSA types captured requirements and decomposes or derives additional new requirements as needed to clarify Concern requirements with Business Driver and Business Principle requirements.

Review ClarityThe 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 ContractualThe PMO imports Contractual requirements from the Subcontract documents into the IRQA repository.

Capture Deliverables & ArtefactsThe BUSA adds Contractual requirements and defines the document deliverables required for each milestone.

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

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

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.DocumentsService Line Process Descriptions (SLPD)Volumetrics (VOLM)Project Glossary (PGLOS) (update)

Types Business Driver, Business PrincipleGoal = kpi, BUC

Attributesclarity, stabilitykpi

ViewsStakeholder 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 environment.DocumentsApplication Capabilities (ACAP)Application Capability Matrix (ACM)Volumetrics (VOLM) (update)FM Application Technical Assessment Criteria (ATAC) (update)FM Application Technical Assessment Report (ATAR) (update)

Types Goal, BUC Application Capability, IntegrationExpectation, Infrastructure, Supplementary = qosTechnology Principle, Design Decision

Attributescapability, continuum, phase, doctype, stdtypekpi, qos

ViewsFunctional Traceability CatalogueArchitecture Principles Traceability Catalogue

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

Attributeskpi, qosvalidatemethod

ViewsFunctional Testability MatrixNon-Functional Testability Matrix

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). DocumentsChange Log (CLOG) (update)

Types Clarification = querytype, All Types = owner

Attributesquerytype, owner

Roles and ResponsibilitiesProcess overviewThe main roles and their associations to requirements processes are 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.BUSA Business Analyst CUSTO Custodian (for each Requirement Type) PM Project ManagerPMO Program Management OfficeRWG Requirements Working GroupSOLA Solution ArchitectTESA 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.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.

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.

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.

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.

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; andAuthorising 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 workshopsand 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.

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

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: Page 15 of 15Version no: 1.0lDate: 12 June 2011

Issued by: Page 15 of 15Version no: Date: 12 June 2011