Question and Answer List
RSS

We have a locally developed Application which handles routine administrative actions but has somehow been classified as a NSS. I have not contacted the Application owner yet, I wanted to see if JCIDS was required prior to classification of a system as NSS.

Question:

Do all new Information Systems regardless of command level it was developed under or ACAT category, have to go through JCIDS before they can be classified as a NSS?

Answer:

DAU wrote: The Joint Capabilities Integration and Development System (JCIDS) is one mechanism for identifying and documenting user requirements. Others include service related requirements documents not requiring JCIDS staffing, as well as responses to JUONS, and the newly designated Middle Tier of Acquisition. National Security System classification is a separate process and the designation is made by the agency head. Once designated, the DoDI 8330.01 and DoDI 8510.01, as well as the CNSS regulations are applicable and require the compliance with the NR-KPP.

The organization requires new IT wires and cabling for relocatables that are being installed. The current relocatable has IT capabilities, but requires corrections in the installation to meet regulatory guidance. The installation of the new wiring/cabling will include the repair of the incorrectly installed IT wiring. There is a difference of opinion whether this is an O&M, O&M minor construction or an OPA funded project. The project exceeds $250K but less than $1 million.

Question:

Is the installation of new IT cabling to relocatables coupled with the repair of incorrectly installed IT cabling considered an O&M or OPA funded project? Contract is under the installation IDIQ contract and contractor will not provide any telephones, computers, etc, just the wiring for voice and network lines.

Answer:

DAU wrote: The DoD Financial Management Regulation Volume 2A Chapter 1 provides guidance on this issue, beginning on p. 1-20. The work you describe appears to come under D.1.f., which would qualify the IT wires and cabling as Expense items rather than Investment items. This also considers the guidance on p. 1-20 for categorizing expenses as "costs incurred to operate and maintain the organization," vs. investments as "costs that result in the acquisition of, or an addition to, end items." There is business judgment involved in the determination so you should consult with your organization's comptroller/budget official for more authoritative guidance.

Under the "traditional" Defense Acquisition model, certain products (for example, the Life-Cycle Sustainment Plan) are required at specific milestones by policy, or in some cases law.

Question:

Under IT box, what are the equivalent milestones? Should a request for a RDP approval be accompanied by the same products that would be expected at Milestone B with a CDD? Should a Capability Drop (CD) require the same products as a CPD approval at Milestone C?

Answer:

DAU wrote: Under IT box, what are the equivalent milestones?

The short answer is no. IT Box does not prescribe milestones. The intention behind an IT Box is to have fewer iterations of validating capability requirement documents through the JCIDS process by describing the overall IS program, and delegating validation of detailed follow on requirement and solution oversight to a flag-level organization other than the JROC. This provides IS programs greater flexibility to incorporate evolving technologies and achieve faster responses from requirement validation processes than is typical for other kinds of materiel or non-materiel solutions. (JCIDS Manual p D-31 and D-32)

Should a request for a RDP approval be accompanied by the same products that would be expected at Milestone B with a CDD?The RDP is a first level refinement of one or more capability requirements. The regulatory product requirements can be tailored and should be worked out between the program office and the designated oversight authority. (JCIDS Manual p D-38) Should a Capability Drop (CD) require the same products as a CPD approval at Milestone C? The CD could describe the performance characteristics of a relatively small increment of a capability solution included in a software build necessary for partial deployment of the overall capability solution, typically developed and fielded within a short period of time. The approval of CDs may be delegated to a lower level requirements authority as determined by the delegated oversight authority to ensure timely decision making a capability solution included in a software build necessary for partial deployment of the overall capability solution, typically developed and fielded within a short period of time. The regulatory product requirements can be tailored and should be worked out between the program office and the designated oversight authority. (JCIDS Manual p D-39)DODI 5000.02 ENCLOSURE 1 should be consulted as Incrementally Deployed Software Intensive Programs (Model #3) do not have a Milestone C and consequently are not required to satisfy the Table 2 requirements associated with that milestone. (DODI 5000.02 p.52)

I need to get a copy of ISO 3874 "Freight containers - Handling and securing."

Question:

Is there a govt repository with ISO standards or do we need to purchase our own copies? I need to get a copy of ISO 3874 "Freight containers - Handling and securing." I hate to go through the time and expense to procure if they are already available to the govt.

Answer:

DAU wrote: Currently, no there is not one. However, you have a great idea and DISA and Army have done a blanket purchase agreement with ISO that will establish one soon. There is also an initiative in somewhere at the Federal level to establish a government-wide repository.
Recently, we were told that DISA and the Army have done a blanket purchase for all ISOs. Navy and AF have not. An enterprise ISO license is being looked at across the government but is not in place yet.
We do not have POCs for any of the above at this time. We are working to find POCs and will repost an update to this answer when we do.

DAU wrote: Interfaces have formal Application Program Interfaces (API). Interfaces are the handshake between functions and procedures from one software application to another. Interfaces are managed at the application level. There are internal and external interfaces. Internal interfaces do not require a network connection; external interfaces sometimes require a network connection.

On the other hand ,SFTP is also known as Secure File Transfer Protocol (SFTP). SFTP is at the file level, providing file to file transfer from folder to folder. It is a software application all to itself. SFTP usually requires a network connection (i.e., interconnection) in order to work.

SFTP is not an interface, it is a software application that provides secure file transfer within a computer (folder to folder) or over a network.

Program with projects for the development and continuous application of Innovative IT/IS tools for IC Solutions.
I need help developing (or advising the development of) IS/IT/IC TOOL performance metrics, to include SMART metrics (specifically, measurable, actionable, relevant, timely) and accompanying incentives for inclusion in the program's projects.
Some advisors suggest locating Information System/ Information Technology security requirements; Since the Project Tool is the deliverable, I was expecting Project or tool specific metrics.

Question:

1. Am I overthinking this? 2. is there an IS/IT Metrics standards reference? 3. is there an IS/IT R&D standards reference? 4. Can a selection of DAU classes be designed for our Program Manager's Team?

Answer:

DAU wrote: 1. I don't think so, but do want to address the "Project Tool is the deliverable" aspect of your statement. IS/IT Security requirements including Cybersecurity is an important aspect of IS/IT development and management especially within the IC. That said, if the Project Tool is the deliverable, and that means it merely provides the template for consideration during Research and Development and Management of projects then possibly a yet broader aspect of measurement is warranted; an ala carte menu!

2. Given the background and discussion of the effort I point you to the Practical Software and Systems Measurement (PSM) Process; http://www.psmsc.com/. PSM is compatible with the ISO/IEC 15939 standard, Software Measurement Process. This Government organization (Army at Picatinny Arsenal NJ) is the Subject Matter Experts for Measurement and is involved in the various Standards organizations within the Software/Systems and Measurement Domain. DAU has partnered with them in bringing measurement (PSM) education and support to the warfighter. DAU hosts a Continuous Learning Module based on this process; CLE 060 Practical Software and Systems Measurement; http://icatalog.dau.mil/onlinecatalog/courses.aspx?crs_id=1725

3. There are many standards, the challenge is to find the best ones based on your information needs; further analysis and discussion is required. For example ISO 03.100.40 - Research and development, is one, but may not address the focus of your needs.

4. As noted in response to question 2, DAU hosts a Continuous Learning Module, CLE 060, that provides a good overview and application of the PSM process. Anyone in your Organization, including Government sponsored Contractors, can apply for and complete this online course. Additional learning assets from across IT, Engineering, Science and Technology Management, and Program Management exist that can be leveraged and/or tailored to your organization. This tailoring and potential Consulting level support is provided through our Performance Learning based Mission Assistance program which includes various workshops; see https://www.dau.mil/consulting-services and http://icatalog.dau.mil/onlinecatalog/targeted_training.aspx for more details!

A capability is currently under consideration that is software intensive with commercial off-the shelf (COTS) computer hardware with accessories and peripherals. This capability requires COTS accessories such as Grip Controllers, Virtual Reality Headsets and Gaming Seats with Steering Controls.
JCIDS guidance states all hardware associated with an IS-CDD must be COTS/GOTS. Additional D0DI 5000.02 provides the supporting acquisition model.

Question:

Where may I find a reference or POC that can provide COTS/GOTS hardware restrictions supportive of an IS-CDD?

Answer:

DAU wrote: We do not have a POC other than to refer you to your chain of command. However, the JCIDS Manual, There are four (4) Hardware Restrictions is support of an IS-ICD/CDD: 1-All hardware needed to solution the IS-ICD/CDD must already be developed---GOTS or COTS. 2-Hardware must be targeted for use for system integration or enhancement purposes that directly support IS-ICD/CDD capability requirements. 3-Hardware can be purchased (COTS) for hardware refresh purposes due to obsolescence to support IS-ICD/CDD capability requirements. 4-Hardware may not be purchased to increase quantities of previously fielded equipment, which are not addressed by the approved IT Box. Please refer to page D-31 in the JCIDS Manual: IS-ICDs are appropriate for: (a) The procurement or modification of GOTS/COTS IS products from domestic or international sources, or the development of dual-use technologies. (b) The additional production or modification of previously developed U.S. and/or allied /partner-nation / other US government agency/department IS products. (c) Development, integration, and acquisition of customized application software, including commercial IS capability solutions with integrated, DOD-specific performance characteristics/standards. (d) All hardware associated with an IS-ICD must be COTS/GOTS. Hardware modifications are restricted to those necessary for system integration and enhancements to meet capability requirements specified in the IS-ICD, and hardware refresh due to obsolescence. (e) Approaches where the capability solution involves research, development, and/or acquisition of applications systems software, and the projected life cycle costs exceed $15 million. IS-ICDs with life cycle costs less than $15 million may be submitted for review and validation if validated requirements are needed to support budgetary requests or other purposes. IS-ICDs are NOT appropriate for: (a) Software embedded as a subset of a capability solution developed under other validated capability requirement documents. In this case, the software requirements are validated as part of the capability requirements for the overall capability solution. (b) Software requiring a host platform, such as a manned or unmanned vehicle, which does not yet have validated capability requirement documents. In this case, the software requirements can be included in the capability requirements of the host platform, or as a separate IS-ICD submitted after validation of the host platform capability requirement documents. (c) Increases in quantities of previously fielded IS without modification, which are not addressed by an IT Box. These increased quantities may be addressed by a DCR. Increases in quantity which remain within the scope of a previously validated IT Box, may be accomplished without revalidation. (d) Requirements for DBS capabilities defined and acquired in accordance with references bb and lll. (4) In cases where the potential for use of the IT-Box construct is unclear or in dispute, the Joint Staff Gatekeeper, in consultation with the validation authority as needed, will determine whether an ICD or IS-ICD will be used.

DAU wrote: There are currently no federal or DoD specific standards that define the technology refresh cycle. The update/refresh cycle is determined by the program manager in conjunction with several processes and documents internal the program office. Those include the acquisition strategy, contracting strategy, market research, user requirements, system engineering plan, and test strategy plans.

DAU wrote: Washington Headquarters Services has migrated the DCMO SharePoint to a new version and the Functional Strategies are now at: https://dcmo.sp.pentagon.mil/dcoi/ibf/SitePages/AllFunctionalStrategies.aspx

DODI 5000.02 (current version) removed Enclosure 12, Acquisition of Defense Business Systems (DBS), and referred to DoDI 5000.75, Business Systems Requirements and Acquisition, of 2 Feb 2017 instead. Correspondingly, Table 10 of the DODI 5000.02, CCA Compliance, was revised to delete any references to DBS.
Dodi 5000.75 - quote follows - Implements the statutory requirements of Subtitle III of Title 40, United States Code (U.S.C.) and Section 811 of Public Law 106-398 (referred to in this issuance as the Clinger-Cohen Act (CCA)). The CIO recommends that no reviews beyond those described in this issuance are required for CCA compliance. Section 3.2.d.(1) indicates that the CIO Confirms CCA compliance based on program manager input and supporting artifacts. Table 4, Statutory Requirements, includes that CCA compliance (separate documentation of CCA compliance is not required) for ATP decision points.
I found on the web a Business Capability Acquisition Cycle (BCAC) DAUAA Symposium April 4, 2017 that included a table similar to Dodi 5000.02 Table 10, CCA Compliance, for DBS.
Finally, Dodi 5000.02,Table 10, requires that a mission essential system be loaded into the DoD IT Portfolio Registry. I did not see a similar reference in Dodi 5000.75.

Question:

I may be missing something, but it is unclear to me how to document CCA compliance for DBS given the new policies. It is also unclear if a DBS must be registered in the DoD IT Portfolio Registry.
Any guidance you can provide would be greatly appreciated.

Answer:

DAU wrote: Question 1: How to document CCA Compliance for a DBS given the new policies? DoDI 5000.75 has its own table that will be added to DoDI 5000.75 the next time it is updated. In the meantime, you can find the table at the BCAC CoP: https://www.milsuite.mil/book/docs/DOC-422156 <https://www.milsuite.mil/book/docs/DOC-422156>I have included a copy for you at https://www.dau.mil/aap/Answer%20References/Information%20Technology/BCAC%20CCA%20Table%20v1.docx. Question 2: Must a DBS be registered in the DoD IT Portfolio Registry (DITPR)? Registration in DITPR is still required; it is item 11 on the BCAC CCA Compliance Checklist enclosed. It’s how you get to be a business system in the first place – identifying your systems as “DBS – Yes” in DITPR.So if you’re under the 5000.75, you’ve already completed it and it doesn’t need to be called out as a separate requirement.However, in the case where you are working on a “capability” under the 5000.75 before there is even a system to talk about, in this case… you may not have needed to register in DITPR yet, and you also wouldn’t be at an ATP that requires CCA compliance yet.

We've been having a lively discussion about whether the Power Entry Panel (a panel installed on the exterior of the end item using rivets, sealant, and painted as a part of the overall end item) would be considered a Component of End Item. Per AR 71-37, this could be interpreted as a CoEI, though it would require destructive efforts to remove it from the end item.

Question:

What regulations cover development of the CoEI during technical manual development?

Answer:

DAU wrote:

COEI is governed by AR 71-32, Force Development and Documentation - Consolidated Policies. A COEI belongs as part of a Class VII end item and normally has no separate identity outside of that end item. AR 71-32, para 6-23, states that a COEI could be a separate end item.

The final decision on any issues would be jointly determined between the PM and the MDA.

There is additional information located on the DAU Ask A Professor homepage.Specifically, /aap/pages/search.aspx?q=coei

I am looking for exactly what needs to be captured for Financial Improvement and Audit Readiness (FIAR)/Accountability in the area of software. Specifically DODI 5000.76. I have read it three times and it does not really tell you.

Question:

Where to start and what's to be included?

Answer:

DAU wrote: If you go to: http://www.esd.whs.mil/DD/Search for DD Form 3041, “Accountable Property System of Record (APSR) Requirements Checklist for Internal Use Software (IUS)(March 2017) You get: http://www.esd.whs.mil/Portals/54/Documents/DD/forms/dd/dd3041.pdfThis checklist walks the required aspects of IUS reporting. For further questions, please read the below: Publication of DoDI 5000.76 on Accountability of Internal Use Software DoDI 5000.76 was signed out on March 2, 2017 by AT&L formally setting DoD accountability policy for DoD owned Internal Use Software (IUS). DoDI 5000.76 was developed as apart of a DoD-wide working group to remediate a FY 2016 DoD Statement of Assurance self-reported material weakness for accountability of IUS. The new instruction sets forth the policy, roles, and procedures for establishing accountability for these software assets. A training webinar has been developed to assist Components with understanding and implementing this new instruction. Please submit requests to attend the webinar via our Contact Us <http://www.acq.osd.mil/pepolicy/general/feedback.html> at http://www.acq.osd.mil/pepolicy/general/feedback.html or e-mail us at osd.pentagon.ousd-atl.mbx.p-e-policy@mail.mil <mailto:osd.pentagon.ousd-atl.mbx.p-e-policy@mail.mil>. Subsequent training webinars will be provided on an as needed basis.

I was in a meeting and someone said,"We no longer use the requirement definition package in the IT Box solution. The capability drops are the focus. This enables the approval process to go faster."

Question:

Does the IT Box Solution still include RDP?

Answer:

DAU wrote: The current JCIDS manual still reflects both RDP and CD as examples of documents used for managing follow on efforts (in an agile manner). The IS-ICD or IS-CDD provides sponsors the flexibility to manage IS capability. (see page D-36)
“The following example of documents used for managing follow-on efforts is intended to be illustrative, and is not intended to limit potential flexibilities provided by the IS-ICD or IS-CDD. For the purpose of this example, two document types have been created and illustrated in Figure D-4. the Requirements Definition Package (RDP) and the Capability Drop (CD). Actual names, content, and approval process are at the discretion of the delegated oversight authority.” … JCIDS Manual p D-36The IT Box model calls for fewer iterations of validating capability requirement documents through the JCIDS process by describing the overall IS program, and delegating validation of detailed follow-on requirement and solution oversight to a flag-level organization (see page D-32)

Title - What Appropriation should be used for Hardware Technical Refresh?
Question -
What is the appropriate type of color of money to use? /aap/pages/search.aspx?q=What%20is%20the%20appropriate%20type%20of%20color%20of%20money%20to%20use?
Scenario - Program is refreshing a computer system during operating and support phase.
Posted - 9/20/2010 11:00:00 AM
Subject Area - Business - Financial Management
A picture of an A. The text to the right is the answer.
Based on the information provided by you, the proper response is that it depends on the dollar amount of the IT hardware effort, as well as its intent. With this information you can determine whether operations and maintenance (O&M) or if other procurement should be used. If the unit cost at a system level is greater than or equal to $250K, it is an investment and other procurement should be used. If it is less than that, as well as is centrally managed, O&M funds should be used since it is considered an expense. Additional expense/investment criteria, as it applies to information technology equipment and software, can be found in Volume 2A, Chapter 1, and Volume 2B, Chapter 18, of the regulation beginning at page 1-13 at http://comptroller.defense.gov/fmr/02a/02a_01.pdf.
A commonly reported fiscal violation involves DoD personnel using O&M funds to purchase a computer system when Other Procurement funds are required. Other Procurement funds shall be used whenever a piece of computer equipment becomes an integral part of a computer system or local area network (LAN), unless the total costs of the entire system or LAN is less than the amount designated for use of procurement funds.

Question:

Doesn't conditional case 'c' of the expense/investment criteria overrule the $250K threshold answer provided above when there is no intent to get capability increase?
c. Maintenance, repair, overhaul, and rework of equipment
are funded in the operation and maintenance appropriations. However, maintenance of
equipment used exclusively for research, development, test, and evaluation efforts will be funded by the RDT&E appropriations. Continuous technology refreshment is the intentional,
incremental insertion of newer technology to improve reliability, improve maintainability, reduce
cost, and/or add minor performance enhancement, typically in conjunction with depot or field
level maintenance. The insertion of such technology into end items as part of maintenance is
funded by the operation and maintenance appropriations. However, technology refreshment that significantly changes the performance envelope of the end item is considered a modification and, therefore, an investment (See section on 'Product Improvement' 010212 C. 7.). This definition applies equally to technology insertion by commercial firms as part of contractor logistics support, prime vendor, and similar arrangements and to technology insertion that is performed internally by the Department.

Answer:

DAU wrote: Yes, I would agree with your follow-on question. Conditional Case 'c' of the DOD Financial Management Regulations (DOD 7000.14-R Volume 2A, Chapter 1 dated January 2011/2008; Section 010201.D.3.c; page 1-23) provides the material you cited above.Essentially, continuous technology refresh is considered to be an exception to the guidance earlier in the DOD FMR document related to centralized item management and the $250k threshold.This section makes it clear that typical technology refresh activities (managing obsolescence) are intended to be funded with Operations and Maintenance funding.The challenge will be how your office / component chooses to interpret the following sentence regarding 'significantly changing the performance envelope'. The nature of technology advancement (e.g. Moore's Law, etc) demonstrates that every new technology iteration may also significantly increase capability.It is expected that over the typical 3 -5 year period between technology refresh activities there will be significant gains in technological capability.It may come down to a conversation within your organization between technology refresh (managing obsolescence to continue to meet an existing requirement by improving reliability/maintainability/sustainability) compared to technology insertion (purposefully adding enhanced capability to meet an evolving or new requirement).The 'technology insertion' would likely lend itself more to a 'modernization program' as discussed in DOD FMR Section 010201.D.2.d(pg 1-22) that would be considered an 'investment' if over the $250k threshold. However, I would offer that if the intention of the technology refresh activity is simply to manage obsolescence and enhance reliability/maintainability/sustainability operations and sustainment funding would be appropriate, even if that includes collateral minor performance enhancements.

I'm going to attempt to keep this short...I was pulled in to assist with preparing a tech evaluation for installation of A/V equipment for a courtroom. While reviewing the quotes, I couldn't grasp the connection to soliciting on CHESS. After some research and background on the acq plan, I found out it was going back and forth in the office whether it was for CHESS or open market requirement? (It has been solicited as a service)
I understand that AFARs 5139 requires Army to use CHESS for IT equipment to include audio visual and that a service does not need to be waived, however any software or hardware items must have the SoNA and ITAS waiver even if included in the service. The items on the solicitation referenced the PWS, and the following; install, 5 components, with 2 being optional items the customer may not desire in the end, warranty and training and CMR (some install will be with customer equipment).
Of the 3 desired items and one of the optional equipment, these items create an audio visual infrastructure. The other optional piece are monitors and would fall within CHESS. Install is almost 40% -45h of the quotesI reviewed. I feel that this procurement may have restricted more companies from quotes due to using CHESS, and that the price may decrease with open market quote with a wider broadcast to others within the footprint of the organization and removing the installation crews per diem travel and such. The travel/service portion is approx 40% of the total cost. , I have reviewed the following, FAR/DFARS/AFARS/Court room technology guidance, At 25-1 AND 25-3 as well as the CHESS site and RFPs, federal and state awards pertaining to like or similar scope of work and products and related CARs if available. However, I can't help but think the non suggested (from my opinion) route was taken.

Question:

Are we restricting competition by competing an A/V installation for a courtroom through CHESS? Is this truly a CHESS purchase?
Or is a request for audio visual infrastructure install with supplies embedded allowing it to be a service, without waiver and solicited Full and Open?

Answer:

DAU wrote: The primary purpose of the CHESS contractual vehicle is to provide the Army with continuous competitive contracts that provide economical, value-added, commercial IT products and performance-based commercial IT services. Additionally, the consolidated buy objective is to reduce Army costs and provide standardization to the IT enterprise, including decentralized ordering that provides contracting officers with the option to negotiate the proposed order pricing.While competition is restricted to those contractors under the multiple award contract, there are numerous contractors and the contracting officer must provide each awardee a fair opportunity to be considered for each order exceeding $3,500, unless the requirement meets exceptions as provided in FAR 16.505(b)(2).Further review of the acquisition plan and market research report should reveal documentation and approvals for addressing all the above and clarify the decision to support the course of action taken for this requirement, including any exceptions or waivers, if appropriate. Additional note and consideration should be given to any other discretion the contracting officer may have on how the product/service is obtained and the frequency of obtaining the requirement, keeping with the overall objective for the consolidated buy.It is highly recommended to discuss the concerns with the contracting officer, legal counsel and the contract review office, to ensure compliance or identify whether there is a need to review and update the requirements package or any other aspects of the contractual vehicle.

We at the Coast Guard's, Command, Control & Communications Engineering Center (C3CEN) have a desire to standardize requirement categories. We understand every IT system is different; we're looking for some type of standardization from which to align all of our IT systems requirements.

Question:

Are there requirement titles/categories/sections that IT Requirements Managers should utilize for the sake of standardization when managing (archiving and initiating) IT system requirements?

Answer:

DAU wrote:

NO, there are no standard C4ISR requirements list that is generic to all military Services.

However, based on the fact that the system is a C4ISR system (Coast Guard) and from a DAU Professor's past C4ISR experience, the following categories of IT requirement buckets should be considered at a minimum:

ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the life cycle. ISO/IEC/IEEE 29148:2011 provides additional guidance in the application of requirements engineering and management processes for requirements-related activities in ISO/IEC 12207 and ISO/IEC 15288. Information items applicable to the engineering of requirements and their content are defined. The content of ISO/IEC/IEEE 29148:2011 can be added to the existing set of requirements-related life cycle processes defined by ISO/IEC 12207 or ISO/IEC 15288, or can be used independently.https://standards.ieee.org/findstds/standard/29148-2011.html

SEI REQUIREMENTS ENGINEERING:Requirements engineering emphasizes the use of systematic and repeatable techniques that ensure the completeness, consistency, and relevance of the system requirements.http://www.sei.cmu.edu/productlines/frame_report/req_eng.htm

Defense Acquisition Guidebook (DAG) CH 3–4.1.4 Requirements Management Process The Requirements Management process maintains a current and approved set of requirements over the entire acquisition life cycle. This helps ensure delivery of a capability that meets the intended mission performance, as stipulated by the operational user.https://www.dau.mil/guidebooks/Shared%20Documents%20HTML/Chapter%203%20Systems%20Engineering.aspx#toc119

Intermediate Systems Acquisition, Developing the System, Software Problems. A new joint command and control system is being developed to meet the strategic information needs of all the military services. The Air Force is the lead service, but the Army and Navy have different points of view about what functions the system should perform.

Question:

Which software acquisition best practices would be most relevant in managing this issue as the program office undertakes system development?

Answer:

DAU wrote: The best software acquisition best practice that would be relevant to this situation is to "Agree on a System Architect in charge." With "decision-making leadership" in place, please follow the following best practice guidelines:

Use System-Based Software DesignPractice Essentials
1. All methods used to define system architecture and software design should be documented in the system engineering management plan and software development plan and be frequently and regularly evaluated through audits conducted by an independent program organization.
2. Software engineering needs to participate in the definition of system architectures and should provide an acceptance gate before software requirements are defined.
3. The allocation of system architecture to hardware, software, or operational procedures needs to be the result of a predefined engineering process and be tracked through traceability and frequent quality evaluations.
4. All agreed to system architectures, software requirements, and software design decisions should be placed under CM control when they are approved for program implementation.
5. All architecture and design components need to be approved through an inspection prior to release to CM. This inspection should evaluate the process used to develop the product, the form and structure of the product, the technical integrity, and the adequacy to support future applications of the product to program needs.
6. All system architecture decisions should be based on a predefined engineering process and trade studies conducted to evaluate alternatives.
7. System and software architectures should be developed from the same partitioning perspective to minimize the complexity of requirements allocation/traceability: Information, Objects, Functions, States.
8. Software engineers should participate in system architecture design and design of the client/server network on which the software will execute.
9. The system architecture design should support security, reliability, performance, safety, and interoperability requirements.
10. The system architecture design should support reuse of legacy software and integration of COTS/GOTS software in a way that minimizes modifications and additions to the reuse software.
11. System and software architecture design should give views of static, dynamic, and physical structures.

Static views show components that can exist. They contain no temporal information.

Static views also include threads of collaboration.

Dynamic views show temporal, concurrency, and synchronization behavior. They include interactions in time sequences and sequences of states.

The physical view describes the mapping of the software and databases onto the hardware and reflects its distributed aspect.

12. The system architecture should be modeled and simulated before the start of software architecture design to verify support for security, reliability, performance, and safety requirements.Implementation Guidelines
1. The DEVELOPER should ensure that the system and software architectures are developed and maintained consistent with standards, methodologies, and external interfaces specified in the system and software development plans.
2. Software engineers need to be an integral part of the team performing systems engineering tasks that influence software.
3. Systems engineering requirements trade studies should include efforts to mitigate software risks.
4. System architecture specifications need to be maintained under CM.
5. The system and software architecture and architecture methods need to be consistent with each other.
6. System requirements, including derived requirements, need to be documented and allocated to hardware components and software components.
7. The requirements for each software component in the system architecture and derived requirements need to be allocated among all components and interfaces of the software component in the system architecture.
8. Software engineers will be an integral part of the team performing systems engineering tasks that influence software. Software engineering personnel should be integral team members in all preliminary project phases. This includes concept exploration, feasibility studies and proposal preparation. This is especially important during the negotiations phases when project commitments are being made
9. When an incremental development life cycle model is followed, the system architecture should be developed as part of the first incremental release to minimize the risk of architecture rework causing major ripple-effect rework.
10. The structured methods for system and software architecture design should be selected first, and then automated tools selected that implement the selected methods.
11. CSCI Architectures is consistent, specified in System & Software Development Plans
12. SW Engineers are part of Systems Engineering
13. Use System Engineering trade studies to mitigate risks
14. System & Software architecture consistent
15. System Requirements & Derived Requirements are allocated to HW & SW
16. Software engineers should participate in system architecture design and design of the client/server network on which the software will execute.
17. Automated CASE tools should be used for system and software architecture design. CASE tools automatically find errors in completeness and consistency. A drawing tool is not a design CASE tool.
18. Planning for software activities should begin at the same time as system planning activities. The CM process should be exploited to keep these parallel efforts consistent. This coordinated planning activity should continue throughout the project life. As part of the coordinated planning a software lifecycle that supports the system objective and schedule will be agreed to and documented. Planning should include direct and support activities (e.g. SQA). All plans should be reviewed and agreed to by all participants and impacted parties.
19. Automated CASE tools should be used for system and software architecture design.

My program is in sustainment. I've been assigned the maintenance of this document.

Question:

What is the review cycle for this document? Where would I find the latest template for this document? What guidance, regulations, etc. outlines how to complete this document?

Answer:

DAU wrote: "The requirement for the Counterintelligence is found in several places.The primary location is in DODI 5000.02, Feb 2 2017, for the requirement to coordinate with Component Intelligence and Counterintelligence communities - this is mentioned several times.Regarding counterintelligence, DODI-O 5240.24, 2011 is referenced in the new DODI 5000.02.However, this reference was updated (in red) on Oct 15, 2013.The theme is for the acquisition community to work with Component Counterintelligence organizations - I recommend you check with your Component/Base Counterintelligence organization for specific assistance.

Regarding the review cycle, DODI 5000.02 requires us in Table 2 to have a Technology Targeting Risk Assessment (TTRA) before/at Milestone A. The TTRA is a requirement for all programs; Milestone A is when a CISP would be needed to support a counterintelligence approach for a program.The basics of what are required in a CISP are discussed in DODI 5200.29, CPI and Protection within RDT&E.Specific formatting requirements for the CISP can also be driven by your Component/base Counterintelligence.So bottom line is, plan to get with your Component Counterintelligence organization(s) early and have a coordinated approach for the CISP by Milestone A.