Search…Backwards

https://www.darpa.mil/DDM_Gallery/DARPA_I2O_OfficeGraphic_Web_D006_619x316.jpg
Image Credit: DARPA

Posted: February 10, 2016 | By: Eric Treadwell

What is Dynamic Tailoring?

Dynamic Tailoring is a method of preparing the content of a standardization document for the user of that document. The use of Dynamic Tailoring is an interactive process whereby the user describes to the standardization document (spec) the project at hand and the spec replies with only the applicable paragraphs. Notice that this definition focuses on the user’s interaction with the spec.

Dynamic Tailoring does not change the content. It does not necessarily change the organization of the document. Dynamic Tailoring simply makes the information more accessible to the user. Users do not care about every single line; they only want to know what applies to their particular case. To help the user, the spec author/SME (or current Responsible Engineering Officer (REO)) must think through the way users interact with their document. The REO then performs the search…backwards, to prepare the document for Dynamic Tailoring. If the REO is not also the SME then a good deal of coordination is required.

The first task for the REO/SME preparing for Dynamic Tailoring is to perform a requirements analysis. The first step in this task is to identify the “core” requirements (those that always apply due to physics or laws). The second step is to identify “conditional” requirements. Next is to identify the conditions wherein “conditional” requirements apply. Lastly, separate and identify “procedural” requirements (as opposed to physical requirements). Why separate procedural limits? Frequently, procedural limits are based on risk acceptance or best practice, things like speed limits. With a good enough reason you can do things differently or perhaps change or waive the restriction. Physical limits, like stall speed or structural strength, are immutable. Understanding the difference will help when the user comes for requirements relief.

Requirements Analysis

  1. Core Requirements
  2. Conditional Requirements
  3. Applicable Conditions
  4. Procedural Requirements
  5. Applicable Procedures

Another word on requirements: The user does not care what types of requirements are written. The user only cares about compliance. Think hard about the conditions chosen. The conditions which will form the basis of the sorting routine are key to the user’s successful interaction with the spec. In the example of MIL-STD-1791, the owning organization categorized at least 95 different types of cargo before abandoning the system. There is also a slowly changing roster of aircraft, with varying requirements, that one might try to organize the standard around. Rather than focus on either of these shifting categories, the author of 1791 took an interface approach to arrive at twenty-nine cargo characteristics and eight procedures. There may be an unlimited number of possibilities for cargo, but there are comparatively few ways that cargo can interact with an aircraft (see Figure 2). Keep in mind that while the examples in this article are physical items of cargo, the item or items governed by a spec may be physical items or a process and Dynamic Tailoring will still be applicable.

Once the requirements have been analyzed, task two correlates them. Conditions are correlated with conditional requirements, and procedures are correlated with procedural requirements. Three lists are then generated: the list of conditions and procedures, a correlation list for conditions/procedures and requirements, and the list of core requirements. Finally, those three lists are combined to produce the Dynamic Tailoring list. Thus Dynamic Tailoring is complete and the document is prepared for the user.

To use Dynamic Tailoring: first, the user identifies which conditions their project matches; second, the user identifies which covered procedures are being used; lastly, the user consults the Dynamic Tailoring list to identify the core requirements and applicable conditional and procedural requirements. Specification compliance verification may then proceed with a known, agreed-upon subset of applicable requirements. The lists may be considered agreed-upon (contractually, regulatory, etc.) because in the document the SME publishes the lists as a required part of the specification.

This process is simple to automate using current computer technology. In a manual (“user’s guide”) implementation, the user is presented with the three lists (they may be formatted as tables, etc.). In an electronic implementation the user interface is based off of the list of conditions and procedures and the computer program returns the core requirements along with any results that correlate to the selected conditions or procedures. In Figure 2, the “Loading Method” and “Special Consideration” columns both represent the conditions identified for MIL-STD-1791A.

The process may also be extended to include multiple, related documents. To stay with the transportation theme: MIL-STD-1366, “Transportability Criteria,” references MIL-STD-1791, along with MIL-STD-209, MIL-STD-129, MIL-STD-810, and MIL-STD-461, all of which may be required for an item being transported by various Department of Defense assets. In order to link all the documents together for Dynamic Tailoring, all that is required is a wider effort.

Want to find out more about this topic?

Request a FREE Technical Inquiry!