RCI (Requirements Clarity Index)

What is RCI ? :

RCI Stands for "Requirements Clarity Index " , this is a document /Spread sheet or even something can be implemented in a system to reflect level of clarity each stakeholder has on the project's requirements. Having proper requirements in place and the 100% clear understand what client needs is vital for successful project delivery 

Note : I have discussed proper requirements management for IT projects under one of  my other articles 

How CMMI Applies for IT Project Management  "CMMI Level 2 : Requirements Management in Detail " 

Please refer the above article for more on requirements management processes 

What are the advantages of RCI

• This is a systematic way to determine the clarity of the new requirements 
• This gives responsibility for each stakeholder to determine their understanding on the requirements
• Requirements gaps could be identify easily and way before the Design / development starts , (Understanding the requirement gaps at the beginning is absolutely critical rather getting that information at the end ,which makes it very expensive and troublesome ) 

How to create RCI

I would prefer to have separate RCI for each DSRS (Detailed Software Requirements Specifications),and getting all required stakeholders to provide their understanding

As shown in the above sample template ,  Overall RCI is designed for entire DSRS . You can observe that there are modules mentioned and for each module there is an individual RCI calculated against each relevant stakeholder. Numbers mentioned in each section is the Index number (RCI). Value of RCI number reflects the level of understanding of particular stakeholder has on that module. By considering RCI of all the modules  we can calculate the overall RCI for entire DSRS (it will be the average of all the modules) 

Below shows the meaning of each index number , 

Software Design and Development  should not start until all the indexes are value 4 , which depicts that requirements well understood 

Test case Design and Development should not start until all the indexes are value 4 , which depicts that requirements well understood 

RTM (Requirement Traceability Matrix)

What is a Traceability Matrix?

The focus of any testing engagement is and should be maximum test coverage
By coverage, it simply means that we need to test everything there is to be tested.
The aim of any testing project should be 100% test coverage

RTM Prerequisites

• We need to know exactly what is it that needs to be tracked or traced
• Test cases based on some input documents – Business requirements document, Functional Specifications document and Technical design document (optional) etc...

Common Artifacts Used for Requirements and System Design

• BRD – Business Requirement Document
• BR Log – Business Requirement Log
• DSRS – Detailed Software Requirement Specification
• DSTD – Detailed Technical Design Document 
• CTD – Change Tracking Document 
• CR Log – Change Request Log 

Create RTM

• Test Case Design / Test Case writing 
• Tracking test cases to the requirement documents through a table with reference numbers for each requirement
• Each test case is linked to a particular agreed requirement ,validated assumption ,constraint or dependency

Sample Traceability Matrix

How CMMI Applies for IT Project Management

I would like to start this article with giving a very brief explanation and introduction to CMMI

Detailed discussion will be covered in individual articles for each sub item for a particular CMMI level .In this article i will discuss the CMMI level 2 , "Requirements Management"

What is CMMI ?

In General the “Capability Maturity Model Integration”, or CMMI, is a process model that provides a clear definition of what an organization should do to promote behaviors that lead to improved performance and to achieve products / services quality objectives

CMMI Maturity Levels and Process Areas for IT Projects 

CMMI Level 2 :

• Requirements Management 
• Project Planning 
• Project Monitoring and Control 
• Measurement and Analysis 
• Configuration Management 
• Process and Product Quality Assurance 

CMMI Level 3 : 

• Integrated Project Management 
• Risk Management 
• Decision Analysis and Resolution 
• Requirements Development 
• Technical Solution 
• Product Integration 
• Verification 
• Validation 

CMMI Level 4 : 

• Quantitative Project Management 

CMMI Level 5 :

• Causal Analysis and Resolution 
• Organizational Innovation and Deployment 

CMMI Level 2 : Requirements Management in Detail

Requirements Management 

Develop an understanding with the requirements providers :

• Identifying Stakeholders responsible for providing requirements 
• Requirements Management Plan should contain the acceptance criteria and the objectives of the requirements 
• In addition ,Requirement Management Plan should contain 
• Who will gather, document, review and sign off the requirements 
• How or the approach we should take to achieve it
• What techniques will be used to gather requirements, gain understanding or clarifications and review of the artifacts

Obtaining commitment to the requirements  from Stakeholders :

• Making sure impact analysis of the requirements has been done, getting commitment to the requirements from the team (this can be obtained through leads most of the time)
• All the impact details must be documented and if any actions to be taken on those , action items and time lines should be determined
• Changes to the estimates, plans,schedules, milestones & delivery dates must be evaluated , relevant artifacts must be updated and all the stakeholders must be aware of it 

Manage Requirements Changes

• Document all requirements and requirement changes that are given to or generated by the project
• Maintain the requirements change history with the rationale for the changes; this can be achieved by using Change Request Log 
• Impact analysis of the CRs raised should be done and it should be documented 
• Requirements artifacts, Q&A Forms and Logs, Business Requirements Log, CR Log and/or Change Request forms are filled with details and made available to the team 

Bidirectional Traceability of Requirements :

• Requirements Traceability Matrix (RTM) will be reflecting the current status of the entire system in scope
• Requirements mapping is done in the Requirements Traceability Matrix
• Requirements are mapped to the relevant architecture and design components, database elements, source code components and test cases done

Note :  I have provided a brief explanation on RTM in a separate article  

Identify Inconsistencies Between Project Work and Requirements 

• Project plans and work products are reviewed in the context of the requirements and the CRs to identify the inconsistencies, if any
• Reasons for the inconsistencies, if any, are identified and documented in Minutes of meeting, Design documents, Requirement Specifications, Project Plan and other relevant artifacts
• Changes to be made to estimates, plans, schedules and work products must be identified
• Corrective actions to implement the above changes are documented and managed