Tag: technology readiness levels

When a system is modified, does its TRL change?

When a system is modified, does its TRL change? ArgonDigital - enterprise automation experts

I was recently asked the question. “When a project begins with a existing device that has a TRL of 9, with the goal to develop a miniaturized version of the device, is the TRL of miniaturized version of the device still 9?  Your point of view will be very helpful.” The short answer is “no”. […]

Technology Readiness Assessments Guide – GAO

Technology Readiness Assessments Guide – GAO ArgonDigital - enterprise automation experts

I am excited to see that the Government Accountability Office (GAO) just released a draft of a new document: “Technology Readiness Assessment Guide” (TRA Guide).  As the title suggests, the focus of the TRA Guide is on assessing the technical readiness of technologies critical to the success of a project.  In this blog, I start […]

Technology Readiness Levels applied to Medical Device Development

Technology Readiness Levels applied to Medical Device Development ArgonDigital - enterprise automation experts

In our previous blog “Using Technology Readiness Levels to Manage Risk” we introduced the concept of Technology Readiness Levels (TRLs).  In that article, the basic descriptions for TRLs as used by NASA and the Department of Defense (DOD) were presented.  We also mentioned that TRLs descriptions have have been developed for all types of products: […]

Using Technology Readiness Levels to Manage Risk

Using Technology Readiness Levels to Manage Risk ArgonDigital - enterprise automation experts

In a previous blog “Are the Requirements Attainable?”, we mentioned that one reason requirements may be not be attainable was because the ability to meet a given requirement was based on an immature technology. Engineers, scientists, and marketing personnel often tend to be overly optimistic as to their ability to meet performance requirements that go […]

How to Communicate “Threshold” vs. “Objective” Requirements.

How to Communicate “Threshold” vs. “Objective” Requirements. ArgonDigital - enterprise automation experts

We were recently asked the following question: “For a system that has both “threshold” and “objective” requirements, what is the best way to delineate them? Our initial thought was to use “should”, but then we don’t want to get them confused with non-verifiable design goals.” The answer depends a lot on how you are define […]

How to Handle Implementation in Customer Requirements

How to Handle Implementation in Customer Requirements ArgonDigital - enterprise automation experts

I was asked the following question from a friend of mine: “I see a propensity to copy requirements from the Customer Specification to various levels of the requirement hierarchy in order to link between a Customer requirement written as implementation in their specification to where it is allocated to in HW/SW.  Is there any guidance […]

Requirement Metrics on the Stability and Risks of Requirements

Requirement Metrics on the Stability and Risks of Requirements ArgonDigital - enterprise automation experts

On our Ask the Experts page, the following question was asked: “One subject that has been on the back of my mind is to find out how to provide a key metric to management about the stability of requirements. By this I mean like a risk factor (or something similar) that will help the program […]

Controlling and Managing Change

Controlling and Managing Change ArgonDigital - enterprise automation experts

Controlling and managing change is one of the most important tasks for both the Project Manager and Systems Engineer.  Failing to do so often results in massive cost overruns, schedule slips, and failed projects. In the previous blog “Why do my requirements keep changing?”, we talked about why requirements change.  In this blog we discuss […]

Are the Requirements Attainable?

Are the Requirements Attainable? ArgonDigital - enterprise automation experts

Attainability is a requirements development issue that is commonplace on many projects.   Defining requirements without adequately assessing attainability places projects at risk of significant cost overruns, schedule delays, and performance shortfalls. Mandatory characteristics for any requirement is that it is Needed, Verifiable, and Attainable.  I call these the NVA characteristics.  In previous blogs “Do we […]