International Defense Security & Technology Your trusted Source for News, Research and Analysis
Related Articles
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 the Department to meet critical acquisition timelines. Systems Analysis of weapon system requirements projected by services may contribute immensely in reducing time and cost overruns by techniques such as feasibility, cost-effectiveness, and risk analyses.
The goal of requirements analysis is to determine the needs that make up a system to satisfy an overall need from the customer. It examines, evaluates, and translates needs into a set of functional and performance requirements that are the basis for the Functional Analysis and Allocation.
Lack of proper requirements led to failure of Acquisition programs
The U.S. Army’s history is replete with spectacular acquisition program failures. An incalculable number of meetings, symposia, working groups, and studies have been dedicated to “righting the wrongs” in Army acquisition. The Army’s lack of an evidence-based requirements system is a consistent cause of failure in Army acquisition programs.
The Army’s most significant acquisition program failure is the Future Combat System (FCS). With a planned cost of almost $200 billion, the FCS is still the most financially ambitious program ever attempted by the Army. The FCS failed for many reasons but shortcomings with requirements were cited as central to the program’s failure. One of the many requirements failure-related lessons learned from the analysis was that “insufficient analysis and mismanagement of expectations can lead to unrealistically ambitious requirements.”
Unrealistic QRs leads to long delays in acquisition and cost overruns.
Indian Army is often criticized for laying down unrealistic General Staff Qualitative Requirements (GSQRs) that leads to long delays in acquisition and cost overruns. 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.
It ends up creating a never-ending circle of Requests for Proposals, Weapons trials rounds, bid cancellation and re-issue of Requests for Proposals further delaying their procurements.
Once Indian Defence Minister Manohar Parrikar 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 henceforth once staff requirement has been defined.
Analysts and retired and service officers agree that the IA is possibly the worst in this regard and the Indian Navy (IN) the most practical and realistic in drawing up its QRs and indigenising its requirements. Out of 43 ships and submarines on order for the IN, for example, 41 are currently being built locally; approvals for another 44 varied platforms to be imminently constructed indigenously had already been granted. The Indian Air Force (IAF), for its part, falls somewhere in between fancifulness and practicality with regard to its acquisition QRs. Reinforcing this viewpoint, the Defence Parliamentary Committee had declared in early 2012 that as many as 41 of the army’s tenders for diverse equipment in recent years had been withdrawn or terminated principally due to over-ambitious QRs.
However, the Military justifies its strict and changing requirements based on the requirement of state of art systems to tackle future likely and dangerous scenarios as well as rapidly changing threat scenarios.
Capability gaps drive the requirements that drive a material solution.
The US 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 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 Capability Development Document (CDD); and at Step 3, System-Specific Requirements uses the CPD.
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 material 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.
The ICD only describes the capability needed or a capability gap. 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. However, if a materiel solution is approved by the MDA, then an analysis of alternatives (AoA) might be required.
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.
Capability Development Document (CDD)
The CDD is developed during MSA 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.
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. 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.
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.
Need to improve the Quality of requirements
There is a 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 material 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 material 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 material 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 material 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 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.
Requirements Development
Requirements Management is the process of documenting, analyzing, tracing, prioritizing and controlling changes to requirements. It’s a continuous process and is conducted throughout a systems life cycle and confirmed at each technical review. The purpose is to assure that the requirements continue to meet the needs and expectations of its customers and stakeholders
Step 1: Gather & Develop Requirements
The first step is to gather, analyze and develop requirements from the Concept of Operations (CONOPS), stakeholder needs, objectives, and other external requirements. Once requirements are documented, they are prioritized, de-conflicted, and validated with the stakeholders.
Step 2: Write and Document Requirements
The second step focuses on writing down the functional and performance requirements into the appropriate requirements documents; Initial Capabilities Document (ICD), Capability Development Document (CDD), Capability Production Document (CPD), System Requirements Document (SRD). Requirements must be documented in order to establish a requirements baseline to start building a system and manage any changes.
Step 3: Check Completeness
The third step is to check that a complete set of requirements have been developed and documented that defines all system functions that are needed to satisfy the stakeholder needs with their associated performance, environmental, and other non-functional requirements. Requirement Tracing is a big tool in this step.
Reuirement Tracing
DoD Requirements Management provides traceability back to user-defined capabilities documented in the Initial Capabilities Document (ICD), Capability Development Document (CDD) and Capability Production Document (CPD). A good requirements management system should allow for traceability from the lowest level component in the Weapons System Specification (WSS) all the way back to the ICD. Relational databases are a good tool in doing this. The Program Manager (PM) and Chief Systems Engineer should institute a Requirements Management process to do the following:
Maintain the traceability of all requirements from capabilities needs through design and test,
Document all changes to those requirements, and
Record the rationale for those changes
One of the tools that can be used is the requirements traceability matrix (RTM). The RTM provides a way to ensure traceability of all requirements for the specific product or system. This traceability allows the ability to trace each requirement to a measurable factor that can be tested. This allows for validation and verification of each requirement and capability
Step 4: Analyze, Refine, and Decompose Requirements
Requirements Analysis is the first major step in the Systems Engineering Process. This step examines each requirement to see if it meets the characteristics of a good requirement. Each requirement is then decomposed into a more refined set of requirements that are allocated to sub-systems and documented in the Weapons System Specification (WSS). Newly derived requirements are expected to emerge from this process, which continues until all requirements are defined and analyzed.
Step 5: Verify and Validate Requirements
In step five each requirement must be verified and validated to ensure that these are the correct requirements. This ensures that the requirements meet the overall objective of the system and all stakeholder needs. Verification and Validation should be done continuously throughout the development of requirements at every level and as part of baseline activities and reviewed during the System Requirements Reviews (SRR).
Difference Between Validate and Verify:
Validate: Confirms that a requirement meets the intent of the stakeholder
Verify: Confirms that the requirements can meet the intended objective of what it meant for.
Step 6: Manage Requirements
In step six the requirements have been accepted and a baseline is established by the stakeholders. Any changes to the requirements are controlled using a Configuration Management process.
US DOD moving to Digital Engineering based on Model-Based Systems Engineering (MBSE) for requirements management
MBSE is the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through development and later life cycle phases. Model-Based Systems Engineering (MBSE) is a systems engineering methodology that focuses on creating and exploiting domain models as the primary means of information exchange between engineers, rather than on document-based information exchange. With traditional approach of Document-Based Systems Engineering (DBSE), project and design information is stored in documents and must be manually maintained and transferred between domains The traditional DBSE approach is labour-intensive and consists mostly of manual analysis, review and inspection.
MBSE with SysML offers the generic element type requirement, as well as subclasses: business requirement, usability requirement, functional requirement, performance requirement, interface requirement, physical requirement, and design constraint.
A model-based systems engineering (MBSE) approach can address the consistency and knowledge problems. A specification that is altered in one subsystem will be updated across the whole system. Traceability can be enhanced by connecting a subsystem design or activity to requirements. Subsystems will understand better which requirements they need to meet, and management will know how the requirements are met. With the model, interactions between the subsystems can become clearer, and have an easy to access repository of hardware specifications. A member of one subsystem will be able to find out what material the structure is made of without having to read through many documents.
Requirement management in MBSE
The model is represented through four main areas: requirements, behavior, structures, and parametrics. Although various types of requirements can be represented in the model, here are three main types:
Business requirements: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities or problems that pertain to the organization.
User requirements: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. User requirements are often situated midway between high-level business requirements and more detailed solution requirements.
System requirements: Usually detailed statements of capabilities, behavior, and information that the solution will need including detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. The system requirements consist of functional, performance, interface, physical requirements, design constraints, and environmental. Non-functional requirements often called quality attributes or “ilities,” such as security, usability, testability, and modifiability
Capturing and Modelling Requirements
Systems Modeling Language (SysML), is commonly used for system modeling. SysML has strict syntax and rules for relationships and connections between elements, which helps to avoid ambiguity.
MBSE with SysML offers the generic element type requirement, as well as subclasses: business requirement, usability requirement, functional requirement, performance requirement, interface requirement, physical requirement, and design constraint.
First, the requirements are put into the model. These are already in a worksheet format that includes id#, requirement, source, verification and testing documentation. This is a straightforward transfer of information from the document to model. In the MBSE tool, adding rationales is incorporated in nearly all aspects of the model. The benefit of adding the rationales is added details about where the requirement is developed from aside from the source requirement.
The mapping of the main requirement types to SysML is straightforward:
- business requirement –> SysML business requirement
- user requirement –> SysML generic requirement with user requirement stereotype
- system functional requirement –> SysML generic requirement with system requirement stereotype or SysML functional requirement subclass
- system non-functional requirements –> SysML design constraint, usability requirement, performance requirement, interface requirement, physical requirement
Capabilities and Functions: Next, the high-level capabilities and functions of the system are created, which was not in any updated documentation. A use case diagram is created and functions added that each satellite or system will have to perform.
So the first step was to create a state diagram that included all states, and why, or when, the system will move from one state to another. Each state is then linked to an activity diagram that walks through the general activities performed during that state.
The next major step is to start adding the physical hardware into the model, by first making a block definition diagram with the different subsystems on each satellite. Each subsystem block opens up to another block definition diagram containing the hardware for the particular subsystem.
A benefit of the model is incorporating the mass and power budgets through parametric diagrams. Every piece of hardware will include mass, power, dimensions, and another information that may be useful. On the parametric diagrams, those values will be used to create the budgets. Now, any property changes in the system are updated in the parametric diagrams.
Finally, the part of the model where it could substantially help with understanding among team members is modeling the interactions between subsystems. These interface diagrams would represent the interface control document and data flow diagram already documented
To develop a well-organized requirements model, SysML recommends the use of packages, which are are folder-like structures that contain requirements in a hierarchical manner. These packages can have their own internal structure that offers some relief from the complexity of the requirements. The added complexity of structures that are too deep inhibit model navigation. In most cases, three layers should be sufficient. If more layers are needed, it may be a good idea to redesign the package structure and make it wider and flatter.
Requirements Traceability and Relationships
One of the most important aspects of requirements modeling is traceability to sources, to steps in the engineering process, and to elements of the system architecture. A requirement diagram enables the systems engineer to tell a story for each requirement. The diagram maps the provenance of the requirement. The diagram reveals
in which version of the system requirements document (SRD) they were published to stakeholders
whether other requirements were derived from them
whether they refine any use cases
whether they have associated test cases to be verified
which parts of the solution architecture they satisfy
References and resources also include:
http://idrw.org/indian-army-design-bureau-will-it-work/
http://www.dtic.mil/dtic/tr/fulltext/u2/a585669.pdf
https://insights.sei.cmu.edu/blog/requirements-in-model-based-systems-engineering-mbse/
