Critical Parameter Management

New Beta Cockpit Tech Tips Document Is Available

David Cronin — Tue, 05 May 2009 02:09:00 GMT

Hi, I have put a beta release for a Cockpit V5.2 Technical Tips document up on my web site. Please take a look and feel free to comment about what you think. Anything to add? Something missing or unclear? Please let me know.

This was written by my friend Pradeep Mady at Cognition at the request of several Cockpit users. It is a work in progress and we value your feedback. Please forward this email to all Cockpit users.

To get the file you must have a member login at my website. If you don't already have one you can request one on the website at:

Sign Up For Cockpit Member Account

Once you have a login account go to the main home page at:
Cockpit User Web Site Home Page

From there click "Member Area" then on the left side click on "Cockpit Files." You will see it at the top.

Of course, feel free to download, use, and comment on anything in the Member Area or the entire web site. It is a work in progress and I appreciate all feedback to help make it more useful.

Sample System Requirements Document

David Cronin — Fri, 24 Apr 2009 00:46:00 GMT

I have uploaded an example of an automatically generated Systems Requirements document from the Cognition Cockpit software. Cockpit is a native Web 2.0 application that comes standard with dozens of templates for: voice management, requirements management, risk management, test management, critical parameter management, and cost management.

You can view this example document at:

Sample System Requirements Document Template From Cockpit

Example of a Cockpit Generated Risk Plan

David Cronin — Fri, 24 Apr 2009 00:23:00 GMT

I have uploaded an example of an automatically generated system level product risk plan from the Cognition Cockpit software. Cockpit is a native Web 2.0 application that comes standard with dozens of templates for: voice management, requirements management, risk management, test management, critical parameter management, and cost management.

You can view this example document at:

Sample Automatically Generated System Level Product Risk Plan

New Templates on the Cockpit Website

David Cronin — Thu, 16 Apr 2009 19:38:00 GMT

I have put up to new examples of process templates in Cognition Cockpit.

Cockpit comes out of the box with dozens of templates for you to arrange any way you like. Users simple follow the templates and then Cockpit automatically generates compliance documents and deliverables as needed.

You can make additional process templates on your own or Cognition can do it for you to match your specific process steps and deliverable formats

Here is a sample template for system risks / FMEA.

Here is a sample template for system trace (design input / output).

I Am Giving A Systems Engineering Workshop At The IQPC DFSS Conference

David Cronin — Tue, 07 Apr 2009 00:59:00 GMT

My company, Cognition Corporation, will be sponsoring the upcoming IQPC DFSS conference in Chicago June 22-24, 2009.

At this conference I will be giving a workshop (June 22) on using the newest Web 2.0 technology to implement a systems engineering approach into common DFSS / CDOV processes. The workshop will focus on the powerful new tools made available with Web 2.0 to create simple process step templates on the web. Engineers simply follow these templates (which are bookmarks in their browser!) to create and manage everything from voices, requirements, specificaitons, tests, risks, and costs. The templates then automatically generate documents and compliance deliverables such as Market Requirements, Product Requirements, Product Specs, Test Plans, Risk Plans, Cost Management Planse, etc. Anyone who wants to learn about this exciting new technology should sign up for the IQPC DFSS conference and attend the workshop. We also have a lot of fun going out in downtown Chicago for dinner and live blues.

You can see an example of a typical Voice/QFD template on my website.

I have also added a members's section to my Cockpit site where users can sign up and log in to view files, presentations, and other useful Cockpit information. I will be adding to this section regularly and there is a place to add suggestions for what you want to see about Cockpit. I will add whatever you want!

Top 5 Reasons To Use Cognition Cockpit As Your Requirements Management Tool

David Cronin — Thu, 02 Apr 2009 19:27:00 GMT

Many have asked for a sharp, to-the-point, argument for why Cognition Cockpit is the best tool available for Requirements Management. For the solution, I asked a large selection of the newest users of Cockpit and came up with this list of top 5 reasons why you should use Cockpit for managing requirements.

This is a Powerpoint slide show:

Why Use Cockpit For Requirements Management

Reorganization of this site

David Cronin — Mon, 23 Mar 2009 18:22:00 GMT

Well, I am reorganizing this site layout.

http://www.criticalparameters.com now goes to my home page.

http://blog.criticalparmaters.com now goes to this blog page.

I will use the main site to upload information and help for Cognition Cockpit software.

What's Wrong With Your Product Development Process (PDP)?

David Cronin — Thu, 22 Jan 2009 16:29:12 GMT

I recently helped create and sponsor the first annual Marcus Evans Product Development Excellence (PDE) conference held at The Peabody Hotel in Memphis, TN.

Here is part of my workshop presentation. Download, extract, then run the Power Point slide set. The two video clip files are linked in the presentation.

PDE Workshop Slides

What do you need for a Requirements Management Solution?

David Cronin — Thu, 11 Dec 2008 16:39:00 GMT

Some ways to think about what you need for effective requirements management from the entire system level down to the lowest critical parameter.

Cockpit for Requirements Management

Publish at Scribd or explore others:

Browser Configuration for Cognition Cockpit

David Cronin — Tue, 14 Oct 2008 18:27:00 GMT

Some users of Cognition Cockpit have asked how to set up Internet Explorer to optimize Cockpit. I put together this short paper to take you through the steps to configure your browser. It is based on IE 7. If you use IE 6 some of the screens may look different but you can still get to each section to set up the browser. FYI Cockpit will support IE 8 by end of 2008.

Cockpit Browser Settings - Upload a Document to Scribd

Versions and History in Cockpit 5.1

David Cronin — Fri, 03 Oct 2008 14:23:00 GMT

Here is a short document that shows how to get started with creating versions and history for any Cognition Cockpit Version 5.1 project. This should help you get started. Click on the Scribd logo in upper left if you want to download the document.

Cognition Cockpit V51 Versioning - Upload a Document to Scribd

Cognition Cockpit V5.1 October 1, 2008 Cognition Cockpit V5.1 Project and Item Versions/History Right click on your project name on the left side TOC (Table Of Contents) and select Create Master. Give your master version any name or comments you wish. After you enter the name and comments click Finish at the bottom right of the pop up window. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 Go back and right click on the project name again and this time select Create Working Version. This will make a copy of the first master version that you can then make changes and add/edit data in the project. Type in a name and comments (optional) for this working version of your project. Click Finish when you are done typing. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 After that is done, click on the project name again (to make sure you are on the home page of the main project) and then click on the History section of the project. You will see that it shows two items: your Master Version and your Working Version. Now click on one of your documents and then click on its History section. You will see there is now one version for this document. Let’s look at an example of something you might do. Go to your Documents section in the TOC on the left and create a new document. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 Name the document anything you like. For format, choose Standard (I can explain the other formats if you want to do a web session to learn how to make specific types of formats for voices, requirements, specifications, tests/v&v, etc.) Right click on your new document and click Accept for Approval (since you are by default the project administrator you have this privilege. If you were not the administrator you might only have the command to Submit for Approval and © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 someone else on the project would be notified of this and they would have to Accept it for Approval.) You will see that the system enters the current date for this approval. You can enter a comment if you like and then click Finish. Right click on your document and select New Heading. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 Select the option for Simple Text (I can explain how the other choices working in a web session.) Name your section anything you want. For the format select Standard Section (again, I can go over all the choices in a web session or in training.) Then click Done to see you newly created section under the document. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 Right click on your document again (not the new section but the main document) and select Accept for Approval. Add a comment if you wish and click Finish. Click on your document in the TOC then click on its History section. You will see the system has locked in the approval you made. You can then click back on Home (to the left of the History section) to see the home page of the document. Right click on you document and select New Heading to add another section. Select Simple Text then give it a name and select the Standard choice again. Click on the document in the TOC and then click on its History section. You will see the updated version to the original baseline. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 Over on the right side under Action click Differences. This will bring up a window on the right that show all changes made to your baseline (in other words, whatever you have done with your recent approval that is a difference from the original.) The process is that whenever you make a change to something that you want to store in history you must select the Accept for Approval command. This takes a “snapshot” of the item and puts it into the project history. You can show differences between any versions as you progress in your work. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 To see overall changes at the project level go and right click on your project name in the TOC and select Create Master. Call it something like “my second master version.” After you do that, click on the project and then click on its History section. You will now see the project version history. Click on Differences where I show to display the differences (changes) the current version has compared to your original master version. You will see a window come up on the right again with your changes for the entire project. Here is what mine looks like. © 2008 Cognition Corporation Cognition Cockpit V5.1 October 1, 2008 The Cockpit is showing Items Added, Item Deleted, and Items Changed between the two versions. If you followed along with me in your own project you would only see the Item added section. The other sections in my picture are from some other things I had done to my example project for some other work. Note in the Project History section you can also select Use This Version to “go back” and display or use another version of your project I hope this helps you get a better understanding of versions. We can do a web session and go into it in more detail with you at any time. Of course our formal training (two days) covers all of this in a more structured environment. © 2008 Cognition Corporation

Schematic View of Requirements Management

David Cronin — Fri, 03 Oct 2008 13:35:00 GMT

Requirements Management is a lot more than simply attaching a bunch of text based documents to a project. Here is a schematic representation of what Requirements Management must be if you are to practice effective Systems Engineering. Click on the Scribd logo in upper left if you want to download the document.

World of Requirement - Upload a Document to Scribd

Quick Overview of Cognition Cockpit For Managing Your PDP

David Cronin — Fri, 03 Oct 2008 13:25:00 GMT

Here is a very brief overview of Cognition Cockpit software as it is used to manage and track your PDP. Click on the Scribd logo in upper left if you want to download the document.

Cognition Cockpit Overview - Upload a Document to Scribd

Mitigate the Major Risks in your Product Development Process

David Cronin — Tue, 05 Aug 2008 17:56:00 GMT

These are some of the key questions in any product development process. Using a simple text based requirements management system* will help get you started but will not give you answers to all these questions. You need a truly active requirements management system such as Cognition Cockpit. Such a tool will take the guesswork out of decision making. A good decision, in the absence of knowledge, is simply a lucky decision.

Use an Active Requirements Management System Like Cognition Cockpit
to Avoid the Most Harmful Causes of Program Failure

If you can mitigate these risks then you can also answer the key product performance questions early enough in the product development process to make informed, cost effective decisions. You can't simply have one group "doing" risk, another group "doing" cost, and maybe here and there some analytical work and Voice Of the Customer research. It all needs to happen at the same time and the results of each process need to interact with the other processes. It is only through this interactive approach to product development that the key performance questions will be satisfactorily answered. The Cognition Cockpitis a tool that will do this for you.

* I have been keeping my own informal count of how many companies have a formal requirements management system. Formal to me means having a clear process and set of tools, even if those tools are internally created such as linked spreadsheets and documents. Over one half the companies I work with do NOT have a formal requirements management system, never mind a modern active system using numerical targets and variation.

CPM Overview

David Cronin — Tue, 05 Aug 2008 17:46:00 GMT

Here is a CPM poster showing a good introduction to what Critical Parameter Management can do for product development.

CPM Overview

Balancing Cost and Performance During Design

David Cronin — Wed, 11 Jun 2008 01:37:00 GMT

Cost Management - The process of cost management is partly encompassed by such topics as Cost As an Independent Variable (CAIV), Design To Cost (DTC), and Total Ownership Cost (TOC) or Total Acquisition Cost (TAC). Each of these can help engineers work towards designing a system at lower cost. In order to manage and interact with costs, the engineer must have timely access to all appropriate cost related information for a system. Most often, engineers (and cost professionals, for that matter) do not have consistent, timely access to cost data and information.
Cost information exists in many formats and locations throughout the corporation. Examples of some common cost sources are listed in Table 1.

The most important function of cost management is to bring together data and information from these various sources so the engineer can trade between multiple estimates per part and keep a history of cost and design choices. This requires a knowledge management system built to handle cost related knowledge tied together with program structures. Structures are a way to organize cost (and later, performance) information. A structure is a collection of uniquely identifiable objects to which cost is attached. This implies a list of part numbers, a Bill Of Materials (BOM), Generation Breakdown (GB, or Work Breakdown Structure (WBS). See Figure 1 for an example of how a structure is “costed”.

Cost information is associated with the appropriate part numbers; this provides a mechanism to switch between various cost estimates for each item. Each time a structure is “costed” can be thought of as a particular cost scenario for the structure. A history is developed whereby each part number has its collection of multiple estimates. These estimates will vary by source (ex. a vendor quote v. a guess based on “similar to” work), date, confidence, and creator. The structure will have multiple cost scenarios depending on which estimates are activated for each part during a roll up event. Scenarios can either be linked to a master WBS structure (updates to the master will update the scenario elements) or independent (no connection: updates to the structure are not passed to the scenario).
The costed structure is a dynamic entity with much information connected to each element. Table 2 shows some of the common attributes associated with each element. The structure is dynamic in that when a change occurs, say an update to a labor rate, the information percolates through the structure and updates appropriate elements.

This behavior is important as it allows the costed structure to be driven, manually or automatically, to compare "what if" concepts and configurations. The structure is rolled up and compared under various algorithms; use the most current estimates per element, estimates made with a certain tool or method, from information entered by a particular user or group, ett. In this way users can rapidly explore various cost and configuration trades and see the immediate impact on the complete costed structure. Costs, and all the other attributes attached to the elements in a structure, are managed through a traceable history that follows a system from bid/propose through development to retirement/disposal.

Critical Parameter (Performance) Management (CPM) - The performance of a system is predicted and managed by various processes including Systems Engineering (more specifically, through Technical Performance Management (TPM)) and Critical Parameter Management (CPM). Typically, Systems Engineering manages the higher-level requirements and parameters but does not tier down to the lowest level parameters that affect a system. The process of CPM best accomplishes this tiering, or flow down, of a system to its lowest parameters. Of course, the ultimate benefit of CPM is the ability to flow back up the path from low-level parameters to higher-level requirements.

CPM provides a series of techniques to enable engineers to track the interaction between requirements and the parameters that drive those requirements. Most companies are engaged in some form of CPM whether they use the phrase or not. As Figure 2 shows, CPM is a process that guides users through the steps of defining a system from high level “wants” and “shalls” to low-level critical specifications. In this way, CPM acts as an enabling backbone to the DFSS process by building the connections between Voice of the Customer, System Requirements, Sub Requirements, Parameters, and driving specifications. CPM becomes the tree to which all of the DFSS branches attach. The transfer functions bring the branches to life so the DFSS team can see immediate impacts of design changes.

The higher-level parts of this “tree” are often defined through Systems Engineering. CPM kicks in as the parameters are defined at lower and lower levels. Once this tree is complete, it defines a functional performance path through a system and helps identify which specifications and parameters are critical. By adding transfer functions to the tree, as shown in Figure 3 and Figure 4, the engineer creates a dynamic relationship between requirements and parameters that can be used to travel from the bottom of the tree back to the top. The result is a dynamic relationship between requirements and parameters. This is an extremely powerful process that provides feedback on the sensitivity of each critical parameter to the overall system. Table 3 gives some examples of the types of transfer functions used in CPM.

The relationship works two ways. By traveling down the tree, from the highest-level requirements (maybe even Voice Of the Customer) to the lowest level critical parameters, knowledge of the various system interactions can be traced. When the tree is studied from bottom up, the variations and sensitivities of critical parameters will result in specific, quantitative effects on the higher-level requirements. The CPM tree is “alive” with relationships between various parameters and requirements and helps build true knowledge of the performance and functional behavior of a system.

Balancing Cost and Performance

Defining the Process - As an engineer makes decisions regarding the performance of a system, the appropriate elements in the costed structure are flagged to indicate they need attention. Someone (the engineer themselves, a cost professional, or other designated person) must update the cost on the affected element(s) or define a cost estimating relationship (CER) that will allow automatic updates to cost based on certain performance attributes. This change to cost will flow back to the CPM structure and update the parameter so the engineer can see the cost impact of their performance decision.

The process is bi-directional. When an element or cost in the costed structure changes (maybe a cost reduction initiative is realized and applied to the costed structure) that information flags the appropriate parameters and requirements in the CPM structure. The engineer will see the information and where/how it affects performance targets and estimates. All of this is done either real time (if there are CER’s to calculate cost-performance trades) or near real time (a user must physically change a parameter or calculate a new estimate.) Most companies do not yet have CER’s for all performance and cost interactions. This process of balancing cost and performance during design will help drive the need for these CER’s. Even the near real time method significantly shortens the trade study cycle time.

Trade studies will take less time as the cost professional (or whoever is the user of the costed structure tree for the system) will now see immediately which elements are being altered by engineering throughout the design process. This allows them to work new cost estimates on effected elements with important input from the CPM tree. When the element flags itself as out of date, the cost user will see what caused the condition: a specification change to a critical parameter, tolerance information, functional alteration of the system or its behavior, or whatever caused the change. The cost user can now re-estimate elements while having vital input for the reason for the change. They make the new estimate and it flows back to the CPM tree and the engineer user sees the impact of their design decisions on cost.

Interact with the new Design Trade Space - This new process lets users manipulate the design trade space (shown in Figure 5) rapidly and with better fidelity. By providing rapid feedback between the cost and performance structures we make more time for trade studies and improve the overall fidelity of each estimate and prediction. A brief walkthrough of this interaction follows.

First, the relationship between performance parameters and cost (element) parameters is defined through team interactions, historical data, subject matter expert (SME) input, and best practices/tribal knowledge. This is where the connections are made that will later be followed when information changes. It is a one-time event. Figure 6 shows this in progress.

Once these connections are established, there remains a dynamic, bi-directional relationship between the various elements and parameters (Figure 7.) The two groups, design engineering and professional cost estimating/management, can now continue their once independent work. The difference now is that as each team enters or changes information, the other team will see the impact in their design space.

Figure 8 shows the heart of the process underway. Performance information is created/updated and then, through the dynamic link created at the beginning of the process, flowed to the cost elements for notification of the cost professional. If there are CER’s to define the relationship then automatic cost estimate updates will trigger. More likely, there is no complete set of CER’s today so the cost element flags the change and “asks” to be updated. The update (automatic with CER or manual by cost professional) is completed and flowed (again through the original dynamic link) back to the originating performance parameter. The engineer will see the cost impact of their design choice. Figure 9 shows information flowing back from the cost elements to the performance parameters.

At any point during the process, either side (performance or cost) can query for the change history of important performance and cost decision points. This allows users to explore the “why” behind a change. Figure 10 shows a cost professional’s view of an element. The user asked for the most recent change to an element and is alerted to a cost driver change from the performance tree: in this case, a change to the cutting rate specification requirements for a lawn mower system.

Conclusion - Followers of this cost-performance balancing process will notice a reduction in the time to complete cost-performance-configuration changes. The automated interconnection between critical performance parameters and cost/structure elements means that users will see the information they need right away, and not need to wait for formal reviews or gates. Cost estimating results will improve in fidelity as key cost drivers are flowed through the system faster and more accurately. The cost professional will see the explicit performance characteristics that are being defined by engineering as they happen. Costing and cost management will gain respect as they will have more timely and accurate feedback to engineering. Development teams will not be able to avoid the costing process as they will have that near real time feedback right alongside their performance characteristics for each critical parameter of the system

Check Out Adurasys For Business Process Management and Lean Sigma

David Cronin — Sat, 07 Jun 2008 01:59:00 GMT

Several of my customers have used Adurasys www.hownot2comesecond.com and told me they were quite pleased with their services, particularly in business process modeling and lean sigma. They are a UK company based in England and have been building a good reputation for fast, professional, and affordable results.

Their site talks a lot about lean ("Extreme Lean") and sales training but the area I have heard about them is business process management. This means helping you to identify or create your business process model and then map it using web software so you can keep and modify your processes after they finish working with your company. The interesting thing about business process management is that is it very similar to what I do a lot of for product development and critical parameter management. Instead of following a BOM tree or functional path approach they are modeling the process for such services as banking/finance, insurance, healthcare, and utilities service. Each process step has goals or target (I would call them System Requirements!) Each of the goals then has multiple drivers or conditions (I would call them critical parameters or sub requirements!) Adurasys will create your model with your team and help you identify your key goals, conditions, process states, and critical drivers. They will then create maps or analysis (I would call them transfer functions!) to predict the behavior of your process in advance; before the process is up and running.

It seems to me what they are doing is just what I do for product development. What exactly is that? Well, I am still kicking around names along with everyone else at my company but here is the generic title:

"A Systems Engineering approach to modeling the PDP including an all in one approach to voice management, requirements management, critical parameter management, cost management, and risk management."

How's that for a title? Or the acronym? SEAMPDPVMRMCPMCMRM

I think we need to keep working...

I might just call it "Next Generation Requirements Management" because that is essentially what it is . Everything is about requirements and how you identify, analyze, report, and optimize them. In the case of Adurasys they do the same thing but for process driven systems as opposed to product driven systems.

If you are trying to model your process or just improve your current model by adding predictive algorithms to key deliverables and event, then you should by all means check them out. I don't know if they work in US or only Europe but there is an easy way to find out!

Product Development Systems & Solutions, Inc. (PDSS)

David Cronin — Fri, 30 May 2008 17:32:00 GMT

PDSS is the source for advice on Product Development and Six Sigma. Wait, let me restate that:

PDSS is THE source for advice on Product Development and Six Sigma. Home of Skip Creveling who wrote the book on DFSS, Critical Parameter Management, Risk Management, and Stage Gate Development, PDSS is the first place you should go for assistance with defining or improving your Product Development Process.

When I say Skip wrote the book I mean Skip wrote the book. Several, in fact, and all of them are worth reading. You can get his books through his website at www.pdssinc.com.

Skip was the key mentor to my company during its early days of Six Sigma, DFSS, and Critical Parameter Management. We learned much of what we know today from him and his amazing staff. They will come in and take you start to finish from a clean slate or critique what you currently have and help you adjust/add/modernize where needed. Where they really shine is after you new or improved process is complete. They don't just go away and wish you luck using your new process. They stick with your teams for as long as it takes to guide them step by step as on the job advisors. Their attention to detail and vast experience really sets them apart in the industry. From their website:

PRODUCT DEVELOPMENT SYSTEMS & SOLUTIONS INC. (PDSS) is a professional services firm dedicated to assisting companies that design and manufacture complex products. We help our clients accelerate their organic growth and achieve sustainable competitive advantage through functional excellence in product development and product line management.

We are experts in Critical Parameter Management and Design for Six Sigma. See founder Clyde “Skip” Creveling’s book, “Design for Six Sigma in Technology and Product Development” (C.M. Creveling et al, Prentice-Hall PTR), Part III, entitled Introduction to the Use of Critical Parameter Management in DFSS. We also develop risk management scorecards based on critical parametrics for design reviews and risk management reviews."

Use them.

New Software For Tolerance Analysis And Optimization

David Cronin — Fri, 30 May 2008 14:32:00 GMT

There is a new player in the tolerance analysis and optimization market that is worth a look. Enventive is a tool that will help you identify and optimize critical parameters in mechanical subsystems. The reason I like it is that you create your initial models BEFORE you get into the detailed CAD modeling phase. By modeling your subsystems earlier in the product development process you can identify problem areas and make changes when it is less costly in time and money.

Typical tolerance and kinematic packages link to CAD packages to interrogate models post design. Any problems found at that stage will be more costly than if they were identified before the detailed design was created. The Enventive tool is designed specifically for up front, pre detailed design work.

Most companies have a "cocked hat" or some sort of symbol to highlight critical dimensions or other critical items in a design. The problem is when you ask someone WHY a particular constraint is labeled with the critical symbol you often get conflicting answers or no good answer at all. We want to be able to know exactly which, if any, constraints need special attention and what the reason we have for assigning this special care (and added cost.) Enventive helps you do just that. From their website:

"Customers estimate that 80-95% of their problems are 2D. Because Enventive is 2D, and 2D tolerance models are at least an order of magnitude easier to build and understand, users can build Enventive models much faster and easier. A principal engineer at a major appliance manufacturer, comparing Enventive with competitors stated, “With Enventive, engineers can achieve 80% of the tasks with 20% of the effort and time.”

Enventive's models are comprehensive, working representations of a part, not just sketches of geometric objects. With its cohesive geometric modeling, assemblies, equation solving, backsolving, and optimization, users describe Enventive as "the best-ever conceptual design tool." A familiar Windows interface, seamlessly integrated Excel, and availability of ANSI standard GD&T callouts make Enventive exceptionally easy to learn and use.

The key to effective optimization is the ability to rapidly explore alternatives—a task at which Enventive excels.

Changing dimension schemes is fast and easy and doesn’t require model rework. Parameter values can be changed directly from the tolerance analysis report, and re-analysis is automatic. Both parameter and tolerance optimization can be driven directly from the tolerance analysis report. Enventive’s ability to rapidly explore alternatives is hundreds of times faster than that of competitive tools.

Enventive is the only mechanical engineering tool that provides optimization of both parameters and tolerances directly from a tolerance analysis report. Using the Excel solver add-in, users may simultaneously optimize up to 200 parameters with up to 500 constraints on the values of those parameters.

For example, you could optimize the parameters of a spring (wire diameter, spring diameter, number of turns, and free length) to produce a specific force-deflection relationship, with minimal variation, simultaneously with a constraint that specifies the shear stress must be less than the endurance limit."

This is just the sort of approach you want to take in order to understand your requirements, critical parameters, and interactions at the earliest possible stage in your PDP. Add to that Enventive's built in capability for team based collaborative modeling and you have a systems engineering tool that could be a very powerful addition to your arsenal. They are certainly worth a look. www.enventive.com

A Day In The Life Of A Requirement

David Cronin — Thu, 29 May 2008 18:59:00 GMT

When we hear the phrase Requirements Management a picture forms in our mind of a process and deliverables. Requirements Management has been around for many years and has changed little: until now.

It used to be okay to have a system that managed requirements (what has that meant, a bunch or text documents strung together with a change history?), another for risk, one for cost, something else again for voice management, and on and on. Each of these processes and their related tools became and an isolated solution. My friend Tom Judd from Motorola likes to call it "building technological islands of isolation." That is a wonderful and accurate phrase for what happens when we think of Requirements Management with the old school, limited vision that has been offered by vendors for many years. Most tools available for Requirements Management have been around for many, many years and were built on antiquated technologies and outdated concepts with little vision towards future needs.

A requirement needs to know a lot about itself in order to determine its overall satisfaction. And only by having satisfied requirements will we have satisfied or maybe even delighted customers. Here is a diagram of the major areas of concern for a typical requirement.

See how many parts of your PDP effect and are effected by requirements?

Every Requirement in a system needs to be part of the definition of the entire system. If you use one tool for costing and another for FMEA, how easy will it be to see the effects of various mitigation strategies on system cost? It will be extraordinarily difficult to get any sort of visibility into the various pieces that make up the definition of a requirement and how it fits within the entire system. Trying to integrate various tools from each vendor can be a lesson in futility, not to mention cost prohibitive.

Ross Perot ran for President in 1992. His running mate, Vice Admiral James Stockdale, made history when during a debate he began with the line, and I paraphrase, "Who am I and why am I here?" That line got him a lot of laughter and ridicule but it is just the sort of line that every component in your system, every requirement, needs to ask. When you interrogate a requirement it should be able to tell you its name, rank, and serial number. It also needs to tell much, much more. How well is it meeting its target? Is it over budget? Behind schedule? What potentially dangerous risks are associated with it? Are there any initiatives currently underway by the development team to address hot spots? How exactly did this requirement come into existence? Can it trace back directly to a Voice Of the Customer? How about its critical parameters? Is there something driving this requirement that is particularly sensitive?

A requirement is so much more than a textual description of a goal with a textual description of a test attached to it. Only by recognizing this and creating a total, holistic approach to product development and requirements management will we take the radical leap into the next generation of product development.