Requirements development is paramount to successful acquisition outcomes. Properly developed requirements enhance competition, ensure sound business strategies, provide the basis for realistic Government estimates, mitigate requirements creep, and help enable the Department meet critical acquisition timelines.
The formulation of the GSQR is one of the initial processes of any new capital procurement. It broadly lays down the reason why the equipment is required, its physical and operational details, as well as the maintainability and quality requirements.
Indian Army is often criticized for laying down unrealistic General Staff Qualitative Requirements (GSQRs) that leads to long delays in acquisition and cost overruns. It ends up creating a never ending circle of Request for Proposals, Weapons trials rounds, bid cancellation and re-issue of Request for Proposals further delaying their procurements.
Defence Minister Manohar Parrikar once had said that GSQRs of Army seems like right out of” Marvel comic Movies “, clearly hinting that technologies requested in Indigenous weapons systems sometimes purely are absurd and not realistic in nature. He also while talking on the sideline of India today conclave 2015 said that he was not happy with Armed forces repeatedly changing requirements in the weapons systems currently been developed by various Public sector units, he also said that he has ensured that no more last minutes changes will be entertained hence forth once staff requirement has been defined .
However, Military justifies its strict and changing requirements based on requirement of state of art systems to tackle future likely and dangerous scenarios as well as rapidly chnaging threat scenarios. Recently The Indian Navy rejected the Naval variant of the Tejas light combat aircraft (LCA) developed by DRDO. The major reason arises from the Navy’s strict specification of its second indigenous aircraft carrier (IAC2) based on future operational environment when China is expected to deploy two carrier strike groups in the Indian Ocean reportedly of 80,000-ton vessels class capable of carrying 60 aircraft.
Systems Analysis of weapon system requirements projected by services may contribute immensely in reducing time and cost over runs by techniques such as feasibility, cost effectiveness, and risk analyses.
Significance of the GSQR
The GSQR is akin to preliminary specification of the desired product. Not only does it reflect upon the type of product that will be procured at the end of the complete procurement cycle but also all the subsequent actions in the procurement process; may it be incorporation of the technical parameters in the Request for Proposal (RFP), field, environmental, technical and maintainability evaluation of the equipment fielded by the vendors and even the response by good defence manufacturing companies to the RFP are dependent on it.
The common practice followed by the Services Headquarters in preparation of this document is based on ascertaining the requirement from the field army, identifying vendors and seeking physical, operational and technical information through Requests for Information (RFI). The comments of stakeholders like complete cross-section of end users, the Directorate General of Electronics and Mechanical Engineering (DGEME), the Directorate General of Quality Assurance (DGQA), the Defence Research and Development Organisation (DRDO), and the Army Centre for Electromagnetics (ACE) are then sought and incorporated before obtaining approval of the final document from the General Staff Equipment Policy Committee (GSEPC). The user/nominated directorate may call the potential vendors for formal interaction before preparing a final draft, if it so desires.
GSQR that is not well formulated would necessitate a fresh start in order to address voids/lacunae discovered into it. This further considerably stalls the procurement process of the equipment for which the GSQR was formulated. The common voids are overstating a technical parameter which may lead to reduction in vendor base, or not specifying a technical parameter which may lead to ambiguities at the time of trial, etc.
In US DOD Capability gaps drive the requirements that drive a materiel solution.
The Army’s process has evolved over the years; however, the basic concept of identifying system capabilities has always been a three-step procedure. First, it begins with the identification of a broad need or capability gap. Second, non-materiel or materiel solutions are recommended, and every suggested proposal undergoes evaluation to determine whether it fulfills the need or capability. Third, a course of action is selected and refined with key performance parameters (KPPs).
The DoD evolved RGS into JCIDS. The change from RGS to JCIDS provided the DoD with the means to emphasize and structure the RGP to begin looking at programs from a Joint perspective for all of the different Services. Consequently, the evolution of RGS to JCIDS resulted in the modification of the requirements documents that facilitated materiel solutions.
The primary goal of JCIDS is to provide the Joint Force with the necessary capabilities required to operate in full-spectrum operations. JCIDS has three founding principles:
- Description of needs by capabilities instead of systems,
- Emphasis on needs at the joint level instead of at the level of separated branches [of Service], and
- One single general or flag officer to manage the separate DoD functional portfolios.
Each of these basic Army steps has an associated requirements document based on the time frame of the specific RGP (JCIDS) that is being followed. At Step 1, Very Broad Needs uses the ICD; at Step 2, Performance Objectives uses the CDD; and at Step 3, System-Specific Requirements uses the CPD.
U.S. Army Training and Doctrine Command
U.S. Army Training and Doctrine Command have a role within the process of developing requirements documents. TRADOC examines the possibility for non-materiel solutions, materiel solutions, or some combination of both to satisfy a specified capability gap. Their decision is based on DOTmLPF-P. In this regard, TRADOC examines a capability gap in terms of functional area, the relevant range of military operations, desired effects, time, DOTMLPF, and policy implications and constraints (HQDA, 2009).
The analysis requires the development KPPs. These are the essential attributes to achieve the desired capability. The attributes are expressed in terms and values of thresholds and objectives. The values are the required minimum and desired maximum capability for an attribute’s stated performance within a given performance specification. This creates a small range of flexibility in capability that the program manager can use as trade space between performance and cost. Additionally, KPPs are identified in the CDD/CPD directly traceable to attributes identified within the ICD. All of the analysis, such as the capabilities based assessment, from TRADOC is captured in the ICD.
Initial Capability Document (ICD)
The initial requirements document in the Army’s RGP is the ICD. It is a non-system-specific document that states an operational capability need(s). By this, it is not directed for a specific desired system. The ICD identifies a capability in broad operational terms. This document is required at the decision point prior to moving into the materiel solution analysis phase.
The purpose of the ICD is to document the possible non-materiel or materiel solution or a mixture of both to satisfy an identified capability gap.
In CJCSI 3170.01C (CJCS, 2003), the ICD was defined as follows: Documents the need for a materiel approach to a specific capability gap derived from an initial analysis of materiel approaches executed by the operational user and, as required, an independent analysis of materiel alternatives. It defines the capability gap in terms of the functional area, the relevant range of military operations, desired effects and time. The ICD summarizes the results of the DOTMLPF analysis and describes why non-materiel changes alone have been judged inadequate in fully providing the capability.
The ICD only describes the capability needed or a capability gap. However, if a materiel solution is approved by the MDA, then an analysis of alternatives (AoA) might be required.
Capability Development Document
The CDD is developed during MS A and is required prior to the MDA’s decision for approval for moving into MS B. The ICD develops and guides the CDD. A CDD is not submitted until the AoA is complete, unless there is an approved justification regarding why an AoA is not required. The CDD is the document that allows the sponsor(s) to further refine the required capabilities.
These capabilities are expressed as performance attributes that contain threshold and objective values (HQDA, 2009). The sponsor enhances the capability required by defining the KPPs, key system attribute (KSA), or other descriptors. CDDs must be updated with any changes to the KPPs.
Additionally, the KPPs contained in the CDD are taken verbatim into the acquisition program baseline (APB) and are validated by the JROC
As per the JCIDS Manual, the CDD format discusses the operating environment of the system, Analysis Summary and CONOPS Summary. It includes Threat Summary that Summarize the projected threat environment and the specific threat capabilities to be countered to ensure the capability gap can be mitigated. It includes Spectrum Requirements. Weapon Safety Assurance i.e. for munitions capable of being handled, transported, used, or stored by any Service in joint warfighting environments.
It should describe, at an appropriate level of detail, the key logistics criteria, such as system reliability, maintainability, transportability, and supportability that will help minimize the system’s logistics footprint, enhance mobility, and reduce the total ownership cost. It should describe how the systems will be moved either to or within the theater, and identify any lift constraints. For intelligence, surveillance, and reconnaissance (ISR) platforms, issues relating to information security and protection standards
Anti-tamper, embedded instrumentation, electronic attack (EA), and wartime reserve mode (WARM) requirements. Human Systems Integration (HSI) considerations that have a major impact on system effectiveness and suitability. Natural environmental factors (climatic design type, terrain, meteorological and oceanographic factors, impacts and effects).
Weather, oceanographic and astro-geophysical support needs throughout the program’s expected life cycle, including data accuracy and forecast needs.
Capability Production Document (CPD)
The CPD can also be an amended version of the CDD, which is useful since these documents have a similar format (HQDA, 2009). “The CPD addresses the production elements specific to a single increment of an acquisition program resulting from an approved CDD or mature existing technology”. A key difference between the CDD and the CPD is the use of performance attributes. The CPD transforms the performance specification threshold and objective values into production threshold and objective values (HQDA, 2009). Another difference between the two documents is that a CPD is required for any acquisition program to enter into production, whereas the CDD is needed for an acquisition program that still needs to develop mature technology before proceeding into production.
Need to improve the Quality of requirements
There is requirement to improve the quality of requirements writing. It is critical to continually improve the efficiency of JCIDS capabilities documents in order to better guide the process of creating a materiel solution. BBP 2.0 outlines the importance of clearly defined requirements for all stakeholders.
CPT Nathaniel P. Costa, and MAJ Anh H. Ha, USA in their report “The Army Materiel Requirements Documents: Qualitative Analysis of Efficiency and Effectiveness,” give many recommendations.
Poorly written capabilities documents often lead to requirements creep. Better quality and more understandable capabilities documents can anticipate and prevent requirements creep. Anticipation may prevent future ECPs. This could result in cost avoidance. Also, no ECP means there is no need to change the system design or conduct re-engineering to achieve an added performance/capability. This helps preserve the acquisition schedule.
Requirements often employ very technical information. An example of this is the following: the warfighter asks for an M4 rifle requirement, instead of asking for the capability of a weapon that does not weigh more than 12 lbs, has an effective range of 500 meters, and is integrated with optics.
The requirements should focus on a perceived capability and not the identification of a specific materiel solution. Capability gaps must be identified in a way that allows the acquisition workforce to work within identified constraints to fill these gaps.
For example DoD must seek out the capability to effectively destroy a bunker versus demanding a requirement of a 120-mm mortar shot from a tube that meets the expectations. If a bunker can be taken out with another materiel solution that possesses greater effectiveness than a 120-mm mortar, and is more efficient and effective within the parameters of the acquisition process, then this is the right solution to fill the capability gap.
The “trade-offs” should be used as a tool when refining the requirements of a materiel solution. The balance between survivability and maneuverability is an example of a requirements trade-off. Survivability usually requires additional weight and takes away from maneuverability. Thus neither threshold nor objective values would be met for either requirement. The CBTDEV’s willingness to make trade-offs is the solution.
The priority that identifies survivability over maneuverability is half the solution. The other half comes into play with a trade-off between objective and threshold values. A trade-off can be established to decrease the expected threshold value of maneuverability in order to reach the threshold value of survivability for the solution. This collaboration on trade-offs between stakeholders is essential in defining requirements. Stakeholders must always remember that every organization has the best interests of the warfighter in mind. Working on realistic and reasonable trade-offs allows everyone to build stronger relationships and enhance the government requirement network.
One of the tools that can be used is requirements traceability matrix (RTM). The RTM provides a way to ensure traceability of all requirements for the specific product or system (Ofni Systems, n.d.). This traceability allows the ability to trace each requirement to a measureable factor that can be tested (Ofni Systems, n.d.). This allows for validation and verification of each requirement and capability